UnsafeRust安全化方法

调研结果

主要精读论文如下：

论文	解决问题
Keeping Safe Rust Safe with Galeed ACSAC ’21	利用硬件机制在调用非安全语言FFI时保护安全rust内存
Securing UnSafe Rust Programs with Xrust ICSE 2020	使用类似Sanitizer的方式防止unsafe的rust代码破坏安全rust的内存
Sandcrust: Automatic Sandboxing of Unsafe Components in Rust	基于Unix系统下在调用非安全语言FFI是

通用的思路是隔离unsafe代码能够访问的内存，其中Sandcrust利用Unix下沙盒进程隔离，XRust利用守护页面和指针检查实现，Gallead使用intelMPK和自动生成的外部语言调用RustAPI实现。

Sandcrust: Automatic Sandboxing of Unsafe Components in Rust

背景

rust的FFI的使用破坏了内存安全体系，这是因为FFI必须使用unsafe才能允许的原始指针解引用和不安全函数嗲用，在外部语言运行的过程中rust编译器无法保护可能存在的内存安全问题。

一种常见的FFI调用做法是将FFI调用包装在safe的rust函数中，这样对于主程序而言看起来减少了unsafe操作，但是实际上包装FFI的safe function仍然需要负责相关的数据传递，且可能的对于内存的破坏仍然存在。

主要内容

该文章认为在rust中使用FFI导致不安全因素的主要原因是它们共用了相同的地址空间。为了解决这个问题，该文章提出了一个基于Rust宏的自动化的创建沙箱进程的方法，利用操作系统提供的进程虚拟地址空间能力和Linux的Seccomp BPF对rust主程序和依赖的外部语言编写的库程序进行分离，以实现安全的目标。对于虚拟监视器项目组，该论文可能不太具有参考价值，因为虚拟机监视器如rustShyper整体运行在最底层，不存在一个已有的“操作系统”来管理进程地址空间。

实现方法

研究者设计了一个Rust宏操作应用于FFI的包装函数，该宏对开发者透明，注入调用过程。仅在第一次调用FFI时，宏用fork系统调用创建一个子进程，子进程进入由宏生成的服务循环并等待其余RPC以执行操作。

该论文使用两个Unix管道来发送和接受RPC请求，并提出共享内存方法并没有明显性能优势。对于每个外部函数调用，主进程用管道发送所有参数，子进程接收参数后调用FFI，并将返回时用管道发送回父进程。

总结

该论文提出了基于Unix系统的沙箱结构，只需要向宏中传入用Rust编写的FFI包装函数，即可无感实现地址空间的隔离。但是，该研究提出的方法不适用于类似虚拟机监视器的裸机程序。

Securing UnSafe Rust Programs with XRust

背景

在极少数的unsafe Rust中的非法访问可以破坏所有safe Rust代码的安全性，研究旨在确保safe Rust的数据完整性。

主要内容

该论文首先将Unsafe的Rust进行分类，分为：

原始指针访问内存，用于base64、缓冲区、vec等
未检查的类型转换
手动调整内部状态，如原始指针初始化Vec后手动调整内部状态来设置向量大小

通过分析，作者认为Rust中大多数对象本身是安全的，只需要分区存放不安全的数据即可。同时，作者分析了控制流劫持，认为由于Rust将vtable函数表与数据分别存放，故不安全的堆内存区域中不会包括函数表，进而可以用论文的方式避免控制流劫持攻击。

实现方法

论文中保护安全堆内存的方式是通过数据流分析找到不安全对象，为其分配不安全堆内存空间，在unsafe访问时插入运行时检查或者插入保护页面阻止跨区域访问。

对于一个具体的示例如下：

encoded_size有整数溢出漏洞，会计算出一个小于所需空间的size，进而会写入到buf分配的空间外的内存。该研究会先通过从safe到unsafe的数据流分析发现buf是不安全对象，为其在不安全堆空间分配空间，最后通过在访问时插入运行时检查避免该漏洞。

实现上分为三部分，扩展的堆内存分配api、多区域堆内存分配器、两种运行时保护手段。

堆内存分配api修改：

对于alloc方式分配内存，在Alloc trait中添加unsafe分配入口点
对于box表达式分配内存，添加了一个新的运算符unsafe_box

多区域堆内存分配器扩展：

扩展了ptmalloc2，ptmalloc2是一个多线程内存分配器。为不安全和安全区域分别提供分配区，且不会重用。通过位图记录堆段类型来加速跨区域错误判断（默认情况下每1MB为1段仅需1bit）

运行时保护手段：

插入检查：基于SVF（上下文敏感的指针分析）框架确定所有被不安全代码访问的对象并插入检查。特别地，一旦被标记为不安全，即使在安全区域中的访问也不再安全，需要插入检查。
保护页面：通过在每个堆段上下各插入一个保护页面，当访问到保护页面时会被拒绝。
- 更高效但不是完全的，因为可以跳过保护也直接访问其它区域。对此，文章提到可以结合Intel MPK / ARM memory domains等基于硬件的保护技术来进行优化。

Keeping Safe Rust Safe with Galeed

背景

目前存在大量从传统非安全语言到Rust的移植开发，如火狐浏览器，这使得代码中存在大量跨语言交互。该研究主要处理不安全语言编写的外部代码对于Rust堆内存的非法访问。

主要内容

首先，该研究将内存访问方向分为四种，来源是Rust代码和C++代码（不安全语言代码），目标内存分为Rust分配的安全空间和不安全代码分配的空间。需要关注的是不安全语言代码对于安全内存空间的访问。

对于这种需要关注的访问，研究者进一步划分为意外访问和有意访问。意外访问指的是由于bug等原因导致的访问，研究者通过堆内存隔离机制对这种访问进行阻止。有意访问指的是外部函数需要访问的Rust地址空间，当发生指针传递时可能发生这种访问，研究者通过对每个Rust结构体属性自动化地创建getter和setter来将访问转移到Rust中来，接受Rust语言的保护。

总的来说，保证了只有Rust可以访问Rust内存，不安全语言在任何情况下对Rust堆内存的访问都会被阻止。

实现方法

对于意外访问的隔离，研究者使用了IntelMPK技术。MPK是英特尔提供的基于非特权指令的线程内存隔离。

其将内存分为16组，页表中的位表示页面所属的组。每个core有一个PKRU寄存器可以用来控制core对每组页面的访问权限共16组1位二进制

二位	权限
00	Read and Write
10	Read only
x1	Deny

通过WRPKRU和RDPKRU来写入/读取PKRU，这两条指令不是特权指令，故与其他平台不同。

PKRU由于可以被恶意代码改写，所以不能完全保护内存，如遇任意指令执行漏洞可以通过改写PKRU来完成攻击。但是对于不能执行任意指令的漏斗如Unsafe Rust对Safe Rust的堆内存破坏，可以通过MPK来阻止，只需要在进入unSafeRust前设置PKRU阻止UnsafeRust代码访问即可。

对于有意访问的保护，可以说时在上述保护之外开了个类似后门的东西，利用rust属性宏自动生成对Rust结构体属性的访问方法。并由FFI调用。为了能够实现对开发者尽可能透明，研究者设计了一个LLVM的PASS用于将对于Rust结构体的访问转化为对相应访问方法的调用，即“伪指针”。

开源情况

开源了论文中提到的LLVMpass和属性宏，但是其又引用了自己多年前研究中开源的libmpk库，所有环境均是老Rust版本且修改了Rust的堆内存分配api以调用libmpk分配页面，对于当前版本配置环境复杂且涉及的libmpk开源不是针对裸机应用设计。

从原理来说其实不需要直接引入其libmpk，对于如虚拟机监视器的项目来说如果有MPK之类的硬件保护措施或许可以直接使用以进行保护。

总结

相对而言这篇论文中介绍的方法是最有可行性的方法。其提出了基于MPK的保护方法，在有高性能的同时满足了外部函数调用安全Rust内存的要求，其自动化生成代码的方式也有可以借鉴学习的地方。其硬件保护内存的相关措施和思想或许可以在hypervisor中有所应用。

总结

通过本学期的学习和调研，我的一些可能比较片面的理解如下：

根据学长的历次组会的报告和交流来看，性能对于虚拟机监视器而言比较重要，尽力减少unsafe并做好防御性设计是一种较为合理的解决方案。Device Tree的解析库的调用可以视情况使用硬件提供的内存隔离机制。其他的非硬件安全手段相比而言开销很大。

对于可能的隔离机制，Intel方面可以使用已经提供的MPK，ARM方面可以预备使用Armv8.5-A及Armv9-A将引入的[Memory Tagging Extension (MTE)](https://learn.arm.com/learning-paths/smartphones-and-mobile/mte/mte/#:~:text=The Arm Memory Tagging Extension (MTE) is a,safety issues are the primary source of vulnerabilities.)安全性扩展，其提供了类似Intel的内存隔离能力。