Is rust used safely by software developers?

Abstract

Rust, an emerging programming language with explosive growth, provides a robust type system that enables programmers to write memory-safe and data-race free code. To allow access to a machine's hardware and to support low-level performance optimizations, a second language, Unsafe Rust, is embedded in Rust. It contains support for operations that are difficult to statically check, such as C-style pointers for access to arbitrary memory locations and mutable global variables. When a program uses these features, the compiler is unable to statically guarantee the safety properties Rust promotes. In this work, we perform a large-scale empirical study to explore how software developers are using Unsafe Rust in real-world Rust libraries and applications. Our results indicate that software engineers use the keyword unsafe in less than 30% of Rust libraries, but more than half cannot be entirely statically checked by the Rust compiler because of Unsafe Rust hidden somewhere in a library's call chain. We conclude that although the use of the keyword unsafe is limited, the propagation of unsafeness offers a challenge to the claim of Rust as a memory-safe language. Furthermore, we recommend changes to the Rust compiler and to the central Rust repository's interface to help Rust software developers be aware of when their Rust code is unsafe.

How do programmers use unsafe rust?

“…In the meantime, more than 10,000 crates have been added to the repository and, in particular, the percentage of unsafe crates dropped from 29% to 23.6%. This finding differs from Evans et al [2020], who observed that the amount of unsafe code in the most downloaded crates slightly increased over 10 months. One possible explanation for these observations is that the most downloaded crates provide the necessary extensions to the language or standard library (for example, an efficient random number generator) that cannot be implemented in safe code and, therefore, the amount of unsafe in the most popular crates does not change while a significant portion of the newly added crates are application code that does not need to use unsafe.…”

“…Our methodology distinguishes these codebases, concluding that some developers (those of A) aim to apply commonly advocated guidelines, and some do not (those of B). In contrast, the approach of Evans et al [2020] cannot distinguish them: both codebases are possibly unsafe. Furthermore, our study provides an in-depth analysis of the reasons why programmers employ unsafe code, which was not an apparent primary focus of Evans et al [2020] (where this question was explored via a survey rather than by analysing a codebase).…”

“…Closest to our work is a recent study by Evans et al [2020] that performs a quantitative evaluation of unsafe Rust. Since their dataset relies on a 16 months older snapshot of the same repository (crates.io), we can observe a few developments over time: in particular, the percentage of crates containing any unsafe code (a measurement made in both studies) has dropped from 29% to 23.6% (noting though that these comparisons relate figures which were computed by different experimental methods).…”

“…Apart from such basic statistics, the two studies are complementary as they take fundamentally opposite perspectives on the usage of unsafe code: we study (intended) compliance with the Rust hypothesis, i.e., commonly advocated best practices for writing unsafe code; in particular, our work takes into account whether programmers aim to shield their unsafe code behind safe abstractions. By contrast, Evans et al [2020] measure how the unsafe keyword permeates call chains and, thus, how many functions transitively depend on unsafe code; they consider all of these functions as tainted, or, in their terminology, łpossibly unsafež. This notion ignores whether a function (1) depends on unsafe code through a safe abstraction that takes responsibility (by declaring exposed functions as safe) for Rust's guarantees, or (2) is explicitly exposed to unsafe code (by declaring all functions in the call chain as unsafe).…”

If It’s Not Secure, It Should Not Compile: Preventing DOM-Based XSS in Large-Scale Web Development with API Hardening

“…The library augments the type safety of the original C++ type system by introducing additional static constraints powered by new types and a new static analyzer. The Rust programming language infuses memory safety into its type system and makes sure that code with memory bugs does not compile [57]- [59]. In Java, the plugable type system [60] denoted through Java annotations allows software developers to statically enforce additional security properties in the code.…”