Is unsafe an Achilles' Heel? A Comprehensive Study of Safety Requirements in Unsafe Rust Programming

TL;DR

This paper presents a comprehensive empirical study of safety requirements in Unsafe Rust, analyzing API documentation, CVEs, and user perceptions to improve safety practices and documentation consistency.

Contribution

It systematically defines safety properties, analyzes unsafe APIs, and evaluates safety documentation and user understanding to enhance Rust security and safety requirement clarity.

Findings

Unsafe API documentation varies in safety requirement descriptions.

A set of 19 safety properties (SP) was defined and applied to 416 APIs.

User survey confirms the importance of systematic safety documentation.

Abstract

Rust is an emerging, strongly-typed programming language focusing on efficiency and memory safety. With increasing projects adopting Rust, knowing how to use Unsafe Rust is crucial for Rust security. We observed that the description of safety requirements needs to be unified in Unsafe Rust programming. Current unsafe API documents in the standard library exhibited variations, including inconsistency and insufficiency. To enhance Rust security, we suggest unsafe API documents to list systematic descriptions of safety requirements for users to follow. In this paper, we conducted the first comprehensive empirical study on safety requirements across unsafe boundaries. We studied unsafe API documents in the standard library and defined 19 safety properties (SP). We then completed the data labeling on 416 unsafe APIs while analyzing their correlation to find interpretable results. To validate the practical usability and SP coverage, we categorized existing Rust CVEs until 2023-07-08 and performed a statistical analysis of std unsafe API usage toward the crates.io ecosystem. In addition, we conducted a user survey to gain insights into four aspects from experienced Rust programmers. We finally received 50 valid responses and confirmed our classification with statistical significance.