A Mixed-Methods Study on the Implications of Unsafe Rust for Interoperation, Encapsulation, and Tooling

Through a mixed-methods study of 179 Rust developers, this paper reveals that while unsafe code is primarily used out of necessity and avoided when possible, current tooling limitations regarding foreign function calls and encapsulation create significant challenges, highlighting the urgent need for improved verification tools to ensure soundness in multi-language applications.

The Gist

Imagine you are building a fortress. The Rust programming language is like a master architect who gives you magic blueprints. These blueprints have built-in safety locks: if you try to build a wall where a door should be, or if two workers try to paint the same brick at the same time, the blueprint screams "STOP!" and refuses to let you proceed. This prevents the fortress from collapsing later.

However, sometimes you need to connect your fortress to an old, crumbling castle next door (written in older languages like C or C++). The old castle doesn't have these magic safety locks. To connect the two, you have to use a special, dangerous tool called "Unsafe Rust."

This paper is a report from a team of researchers who went into the field to interview 19 expert builders and survey 160 more. They wanted to understand: How do builders use this dangerous tool? What tools do they have to help them? And how do they make sure they don't accidentally blow up the fortress?

Here is the breakdown of their findings, explained simply:

1. The "Unsafe" Toolbox: Why use it?

Builders don't like using the dangerous tool. They only reach for it when they have no other choice. The researchers found three main reasons builders use "Unsafe":

• Necessity (The "No Way Out" Reason): Sometimes, the old castle next door speaks a language the magic blueprints don't understand. To talk to it, you must use the dangerous tool. (This was the #1 reason).
• Speed (The "Turbo Boost" Reason): Sometimes, the magic blueprints are a bit too cautious, checking every single step. Builders use the dangerous tool to skip those checks and make the fortress run faster.
• Ease (The "Shortcut" Reason): Sometimes, the safe way to do something is so complicated it feels like climbing a mountain. The dangerous way is a simple path. Builders take the shortcut because it's easier, even if it's riskier.

2. The "Foreign" Problem: Talking to the Old Castle

The biggest headache for these builders is Interoperation (connecting the new fortress to the old one).

• The "Pointer" Confusion: In the old castle, workers can point to a brick and say, "I own this." In the new fortress, the magic blueprints say, "Only one person can own a brick at a time." When builders try to connect them, they often get confused about who owns what.
• The "Aliasing" Trap: Imagine two workers holding the same brick. In the old castle, that's fine. In the new fortress, that's a disaster waiting to happen. Builders found it very hard to wrap these old, messy connections inside a neat, safe package.
• The Missing Manual: Often, the old castle doesn't have a manual. Builders have to guess how the old bricks work. If they guess wrong, the whole wall could crumble.

3. The Tools: The "Miri" Robot

The builders have a robot assistant named Miri. Its job is to walk through the construction site and check for mistakes before the building is finished.

• The Good News: Everyone loves Miri. It's the most popular tool because it catches mistakes that other tools miss.
• The Bad News: Miri is slow. It's like a snail trying to inspect a skyscraper. Also, Miri gets confused when the builders try to connect to the old castle (foreign functions). It can't see the mistakes happening in the old castle's part of the project.
• The Result: Many builders tried Miri, got frustrated by how slow it was, and stopped using it. They are left without a reliable way to check if their "Unsafe" connections are safe.

4. The "Encapsulation" Strategy: Hiding the Danger

The builders follow a golden rule: Hide the danger.

• They try to build a "Safe Wall" around the dangerous "Unsafe" parts.
• They write documentation (manuals) saying, "If you touch this, you must do X, Y, and Z, or the building will fall."
• The Problem: Even with the wall and the manual, many builders feel uncertain. They aren't 100% sure their wall is strong enough. They often rely on "gut feeling" or past experience rather than hard proof.
• The Trust Issue: When builders create a "Safe Wall," they trust it. But when they have to connect to the old castle, they often have to trust the old builders' word, which is risky.

5. What Needs to Happen? (The Conclusion)

The researchers concluded that the builders are doing their best, but they are flying blind in some areas.

• We need a faster Miri: We need a robot assistant that is fast enough to check the whole building and smart enough to understand the old castle's language.
• Better Manuals: The "Unsafe" rulebook needs to be clearer. Right now, it's like reading a map written in a language that changes every week.
• Smarter Tools: We need tools that can automatically check if the connection between the new fortress and the old castle is safe, so builders don't have to guess.

In a nutshell: Rust is a fantastic, safe language, but connecting it to the rest of the world is like trying to plug a modern USB-C cable into a 1980s toaster. It works, but it's risky, the adapters are clunky, and the instructions are confusing. The builders want better tools and clearer instructions so they can stop worrying about the building collapsing.

Technical Summary

1. Problem Statement

Rust offers static safety guarantees through its ownership and borrowing model, but real-world systems programming often requires interoperating with legacy code (C/C++) or accessing hardware directly. This necessitates the use of unsafe blocks, which bypass the borrow checker.

• The Core Issue: While the Rust community advocates for minimizing unsafe code and hiding it behind safe interfaces, errors in these "safe encapsulations" are a significant source of bugs and security vulnerabilities.
• The Gap: Existing tools struggle to verify safety across language boundaries (Foreign Function Interfaces or FFI). Developers lack reliable methods to reason about memory safety when interacting with foreign code, and current tooling (like the interpreter Miri) has limitations in performance and feature support (e.g., lack of support for inline assembly or complex FFI).
• Research Goal: To understand how developers reason about memory safety across foreign boundaries, what tools they use, their motivations for using unsafe code, and how they encapsulate it, in order to guide the design of better development tools.

2. Methodology

The authors employed a sequential, exploratory mixed-methods design involving three phases:

1. Semi-Structured Interviews:
   • Participants: 19 developers with at least one year of Rust experience who regularly wrote or edited unsafe code.
   • Recruitment: Snowball sampling via Reddit, Rust forums, and Discord.
   • Process: Interviews focused on motivations, reasoning about memory safety, FFI challenges, and tool usage.
2. Thematic Analysis:
   • The authors conducted inductive coding on interview transcripts to identify themes (e.g., "Necessity," "Ergonomics," "Aliasing violations").
3. Community Survey:
   • Participants: 160 valid respondents (filtered from 368 submissions) who engaged with unsafe code in some capacity.
   • Design: Questions were derived from the interview themes to test generalizability.
   • Demographics: The survey population had significant experience (avg. 14.5 years in software engineering, 4.1 years in Rust) and included industry, open-source, and academic contributors.

3. Key Contributions

• Empirical Data on Unsafe Rust: Provides the largest qualitative and quantitative study to date specifically focused on the motivations and reasoning behind using unsafe code, moving beyond simple code pattern analysis.
• FFI Challenge Identification: Identifies specific technical friction points when bridging Rust with C/C++, particularly regarding aliasing rules, concurrency models, and memory management semantics.
• Tooling Gap Analysis: Highlights the disconnect between the "de facto" tool (Miri) and the practical needs of developers working on large-scale, multilanguage systems.
• Motivation Taxonomy: Categorizes why developers use unsafe code into three distinct drivers: Necessity (no safe alternative), Performance (speed/space), and Ergonomics (ease of implementation).

4. Key Results

RQ1: Interoperation (Reasoning about FFI)

• Prevalence: 70% of survey respondents use unsafe code primarily to call foreign functions (mostly C and C++).
• Aliasing & Memory Conflicts: Developers struggle to encapsulate foreign libraries that use patterns conflicting with Rust's borrow checker.
  • Example: C allows unrestricted integer-to-pointer conversion and "rat's nest" pointer structures, which are difficult to represent in Rust's strict lifetime system.
  • Box vs. Unique: Rust's Box type behaves differently than C++'s unique_ptr regarding pointer invalidation upon movement, causing confusion.
• Information Hiding: Developers often avoid passing complex structs by value across FFI boundaries and prefer raw pointers to avoid "chatty" APIs, though this increases the risk of undefined behavior (UB).

RQ2: Tooling

• Miri Dominance & Limitations: Miri (a Rust interpreter) is the most used tool (61% of respondents) for finding UB. However, 62% of users were deterred from using it again due to:
  • Slow performance (orders of magnitude slower than native).
  • Lack of support for Foreign Function Calls (FFI).
  • Lack of support for inline assembly.
• Binding Generation: Tools like bindgen are often seen as inflexible or producing non-idiomatic code, leading many developers to write bindings by hand, which introduces human error.
• Auditing: While 51% of respondents use automated auditing tools (e.g., cargo-audit), very few (6%) audit their dependencies' use of unsafe code regularly.

RQ3: Motivations

• Necessity (77%): The primary driver. Developers feel there is "no other choice" (e.g., JIT compilers, OS kernels, specific hardware interactions).
• Performance (47%): Used to eliminate runtime checks or optimize memory layout. Notably, many developers do not consistently measure the performance impact before choosing unsafe.
• Ergonomics (18%): Used because it is "easier" or more intuitive than the safe alternative (e.g., using transmute to bypass complex lifetime constraints).

RQ4: Encapsulation

• Best Practices: Most developers attempt to minimize and isolate unsafe code behind safe APIs (88% of respondents).
• Uncertainty: Despite best efforts, many developers are uncertain if their encapsulations are sound in all scenarios.
  • Only 62% of those exposing safe APIs for unsafe code are "mostly" certain their interfaces are sound.
  • Only 6% feel documentation is always adequate.
• Documentation vs. Reality: While 90% document safety requirements for exposed unsafe APIs, 71% rarely add runtime checks to enforce them, relying instead on "trust" and ad-hoc reasoning.

5. Significance and Implications

• Tooling Needs: The study argues that the Rust ecosystem needs new dynamic analysis tools capable of detecting Rust-specific undefined behavior (particularly aliasing violations) across FFI boundaries with performance comparable to native execution.
  • Proposed Solutions: Compile-time instrumentation (like BorrowSanitizer) or enhanced dynamic tools (like Krabcake for Valgrind) that support inline assembly and FFI.
• Static Analysis: There is a need for static analysis tools that can validate FFI bindings and type signatures automatically, reducing the reliance on manual, error-prone binding generation.
• Documentation Gaps: The lack of a formal, comprehensive specification for Rust's semantics (especially regarding unsafe and panic behavior) leaves developers guessing. The authors call for better documentation of "edge cases" and semantic interactions.
• Future Research: Future work should synthesize code analysis (static) with developer behavior (qualitative) to triangulate the true prevalence of unsafe code in unpublished but public crates.

Conclusion: While Rust developers are motivated by safety and generally follow encapsulation best practices, the current tooling landscape is insufficient for verifying safety in multilanguage applications. The reliance on ad-hoc reasoning and the limitations of tools like Miri create a "safety gap" where undefined behavior can slip through, particularly in complex systems involving FFI.