当前libarchive-rust中无法解决内存类安全问题

## 关于当前libarchive-rust中无法解决内存类安全问题的分析

C语言中内存类的安全问题主要包含越界、重复释放、内存未释放等场景，根据libarchive的历史漏洞情况分析，存在大量的内存越界的情况。

以CVE-2020-21674为例，社区修复方案如地址所示：https://github.com/libarchive/libarchive/commit/4f085eea879e2be745f4d9bf57e8513ae48157f4

主要的原因是因为文件archive_string.c的函数*archive_string_append_from_wcs*在进行数据扩展拷贝的时候，未考虑可能会超出len * 2的场景，因此未申请足够的内存，从而导致后续在执行wctomb进行内存拷贝是出现越界。修改的代码逻辑如下图：
![输入图片说明](https://foruda.gitee.com/images/1666801737075910291/194ccac6_8446730.png "屏幕截图")

根据现有libarchive-rust现有的实现逻辑，也是重新申请内存，并且通过调用*wcrtomb*进行内存的拷贝，假设该漏洞在原有C代码中没有被修复，是错误的逻辑，会导致转换出来的RUST代码也是一样会存在相同的漏洞，出现内存越界。
![输入图片说明](https://foruda.gitee.com/images/1666801820213343434/80e8261a_8446730.png "屏幕截图")

因此根据现有的例子分析，当前使用C2Rust转换后的代码，直接将指针传入到Rust中直接进行操作，并无法解决内存类的安全问题，未充分利用Rust本身安全的特点。

#### 优化建议

当前重写的所有代码中，大部分的接口参数都是*struct archive_string*类型的指针，建议探索一种封装的方法，将C与Rust间不安全的调用独立封装出来，核心业务逻辑使用safe的方法进行编译，从而减少不安全的代码段。

C->unsafe Rust fn->C

优化为：

C->unsafe Rust fn（适配层）->safe Rust fn（核心逻辑）->unsafe Rust fn（适配层）->C

#### 参考示例

unsafe的代码段建议能够降低到3%以下。（例如https://gitee.com/openeuler/sysmaster中unsafe的代码段小于1%，从实际的效果上看，基本未出现过内存类的问题）

关于C与Rust的指针调用的方式，也内部咨询以及查询了相关资料，可以作为参考：

1、https://dev.to/kgrech/7-ways-to-pass-a-string-between-rust-and-c-4ieb

2、可以参考Rust中现有的对glibc的封装库中的实现。

openEuler/libarchive-rust

内容风险标识

评论 (2)

openEuler/libarchive-rust .gitee-modal { width: 500px !important; }

内容风险标识