Characterizing Unsafe Code Encapsulation In Real-world Rust Systems

TL;DR

This paper analyzes how unsafe code is encapsulated in real-world Rust systems, proposing a novel graph-based model to improve safety auditing and identify common issues affecting soundness.

Contribution

It introduces an unsafety isolation graph and structural patterns to model and analyze unsafe code encapsulation in Rust, aiding safety verification.

Findings

Effective characterization of unsafe code encapsulation in Rust projects

Identification of two common issues affecting soundness verification

Proposed approach applicable to real-world Rust systems

Abstract

Interior unsafe is an essential design paradigm advocated by the Rust community in system software development. However, there is little official guidance or few best practices regarding how to encapsulate unsafe code and achieve interior unsafe. The problem is critical because the Rust compiler is incapable of verifying the soundness of a safe function containing unsafe code. Falsely declaring an interior unsafe function as safe may undermine the fundamental memory-safety guarantee of Rust. To address this issue, this paper studies how interior unsafe is achieved in practice, aiming to identify best practices to guide Rust code design concerning unsafe code encapsulation. Specifically, we propose a novel unsafety isolation graph to model the essential usage and encapsulation of unsafe code. Based on the graph, we further propose four major isolation types and nine structural patterns to split a graph into several small self-contained subgraphs. These subgraphs can serve as useful audit units for examining the soundness of unsafe code encapsulation. We applied our approach to four real-world Rust projects. The experimental results demonstrate that our method is effective in characterizing their encapsulation code. Additionally, we identified two common issues in these projects that could complicate soundness verification or incur unsoundness issues.