[ICSE'20] Peiming Liu, Gang Zhao, and Jeff Huang @Texas A&M
Rust, memory safety
Unsafe Rust code may corrupt memory allocated and used only by safe Rust code. This paper tries to prevent this.
XRust is a custom memory allocator + program analysis and instrumentation scheme. It allocates all heap object accessed by unsafe code to an unsafe region (those objects are dubbed "unsafe objects"), objects only accessed by safe code to a safe region, and it instruments instructions that access the unsafe region with checks to catch out-of-unsafe-region accesses. (It also provides a guard page solution to prevent buffer overflow, but guard page is not very strong in general.)
Memory Division
XRust adds unsafe versions of Rust’s default memory allocators, e.g.,
unsafe_alloc() for alloc(), so that there are two memory regions : safe and
unsafe. It uses a pre-allocated bitmap to record the type (safe or unsafe) of
each heap address. The underlying memory allocator ptmalloc2 aligns its heap
segments by 1MB, which means the bitmap is 1 MB–1 bit mapping.
The paper is not clear about what the divided heap exactly looks like.
Object Classification. It uses a data-flow analysis framework (PhASAR) to find all memory allocation sites of unsafe objects. As mentioned above, any object accessed by unsafe instructions are considered an unsafe object.
Memory Access Instrumentation. It uses a pointer-analysis framework (SVF) to identify which instructions access unsafe objects, and it instruments those instructions to report a violation when an unsafe instruction accesses a safe object. For pointers that cannot be resolved by the analysis (i.e., those that may point to either of the two types of memory), XRust uses shadow memory to dynamically record if a pointer points to a safe or unsafe object.
The execution performance overhead is 3.6% on median and 21% on average.
- Targets an important problem.
- The performance mainly depends on the two program analysis frameworks it uses, and since both the frameworks are very conservative, XRust may end up putting many safe objects to the unsafe region and instruments many safe instructions.
- It is not very clear how much security improvement is achieved. Considering Rust is already very safe, a 21% overhead seems unacceptable.
- Pointer analysis is slow. This paper should report compile time overhead.
- Compared to previous related works (memory isolation for Rust), XRust provides much higher coverage of unsafe code.
- Sandcrust @PLOS'17
- FideliusCharm @ACSAC'18
- XRust does not handle directly calling malloc-like functions through FFI. It is not clear how much this would affect the overall security guarantees.
- It only handles the heap.
- It is unclear if the implementation handles all the heap allocation functions.
The paper mentions
BoxandVec::with_capacity. What about others? Does it cover all containers, e.g.,HashMapandBTreeSet?