[PDF] Understanding Memory and Thread Safety Practices and Issues in Real

View - Download Understanding Memory and Thread Safety Practices and Issues in Real

Previous PDF

Next PDF

Understanding Memory and Thread Safety Practices

and Issues in Real-World Rust Programs

Boqin Qin

BUPT, Pennsylvania State University

USAYilun Chen

Purdue University

USAZeming Yu

Pennsylvania State University

USA

Linhai Song

Pennsylvania State University

USAYiying Zhang

University of California, San Diego

USA

Abstract

Rust is a young programming language designed for systems software development. It aims to provide safety guarantees like high-level languagesandperformance e?ciency like low-level languages. The core design of Rust is a set of strict safety rules enforced by compile-time checking. To support more low-level controls, Rust allows programmers to bypass these compiler checks to writeunsafecode. It is important to understand what safety issues exist in real Rust programs and how Rust safety mechanisms impact programming practices. We performed the ?rst empirical study of Rust by close, manual inspection of 850 unsafe code usages and 170 bugs in ?ve open-source Rust projects, ?ve questions: how and why do programmers write unsafe code, what memory-safety issues real Rust programs have, and what concurrency bugs Rust programmers make. Our study reveals interesting real-world Rust program behaviors and new issues Rust programmers make. Based on our study results, we propose several directions of building Rust bug detectors and built two static bug detectors, both of which revealed previously unknown bugs. CCS Concepts:•Software and its engineering→Soft- ware safety;Software reliability. ?The work was done when Boqin Qin was a visiting student at Pennsylvania

State University.

†Yilun Chen contributed equally with Boqin Qin in this work. Permission to make digital or hard copies of all or part of this work for made or distributed for pro?t or commercial advantage and that copies bear this notice and the full citation on the ?rst page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior speci?c permission and/or a fee. Request permissions from permissions@acm.org.

PLDI "20, June 15-20, 2020, London, UK

© 2020 Association for Computing Machinery.

ACM ISBN 978-1-4503-7613-6/20/06...$15.00

https://doi.org/10.1145/3385412.3386036

ACM Reference Format:

Boqin Qin, Yilun Chen, Zeming Yu, Linhai Song, and Yiying Zhang.

2020. Understanding Memory and Thread Safety Practices and

Issues in Real-World Rust Programs. InProceedings of the 41st ACM SIGPLAN International Conference on Programming Language Design and Implementation (PLDI "20), June 15-20, 2020, London, UK.ACM, New York, NY, USA,17pages.https://doi.org/10.1145/

3385412.3386036

1 Introduction

Rust [30] is a programming language designed to build ef- ?cientandsafe low-level software [

8,69,73,74]. Its main

idea is to inherit most features in C and C"s good runtime performance but to rule out C"s safety issues with strict compile-time checking. Over the past few years, Rust has gained increasing popularity [46-48], especially in building low-level software like OSes and browsers [55,59,68,71,77]. The core of Rust"s safety mechanisms is the concept of ownership. The most basic ownership rule allows each value to have only oneownerand the value is freed when its owner"slifetimeends. Rust extends this basic rule with a set of rules that still guarantee memory and thread safety. For example, the ownership can beborrowedortransferred, and multiplealiasescan read a value. These safety rules essentially prohibit the combination ofaliasingandmuta- bility. Rust checks these safety rules at compile time, thus languages like C but with much stronger safety guarantees. The above safety rules Rust enforces limit programmers" control over low-level resources and are often overkill when Rust allows programmers to bypass main compiler safety be de?ned as unsafe or a piece of code inside a function can be unsafe. For the latter, the function can be called as a safe function in safe code, which provides a way to encapsulate unsafe code. We call this code patterninterior unsafe. since it bypasses Rust"s compiler safety checks. Adding un- safe code and unsafe encapsulation complicates Rust"s safety semantics. Does unsafe code cause the same safety issues as763

PLDI "20, June 15-20, 2020, London, UKBoqin Qin, Yilun Chen, Zeming Yu, Linhai Song, and Yiying Zhang

traditional unsafe languages? Can there still be safety issues when programmers do not use any "unsafe" label in their code? What happens when unsafe and safe code interact?

Several recent works [

2,13,28,29] formalize and theoret-

ically prove (a subset of) Rust"s safety and interior-unsafe mechanisms. However, it is unclear how Rust"s language safety and unsafe designs a?ect real-world Rust develop- ers and what safety issues real Rust software has. With the wider adoption of Rust in systems software in recent years, it is important to answer these questions and understand real-world Rust program behaviors. In this paper, we conduct the ?rst empirical study of safety practices and safety issues in real-world Rust programs. We examine how safe and unsafe code are used in practice, and how the usages can lead to memory safety issues (i.e., ille- gal memory accesses) and thread safety issues (i.e., thread synchronization issues like deadlock and race conditions). Our study has a particular focus on how Rust"s ownership and lifetime rules impact developers" programming and how the misuse of these rules causes safety issues, since these are

Rust"s unique and key features.

Our study covers ?ve Rust-based systems and applica- tions (two OSes, a browser, a key-value store system, and a blockchain system), ?ve widely-used Rust libraries, and two online vulnerability databases. We analyzed their source code, their GitHub commit logs and publicly reported bugs by ?rst ?ltering them into a small relevant set and then manually inspecting this set. In total, we studied 850 unsafe code usages, 70 memory-safety issues, and 100 thread-safety issues. Our study includes three parts. First, we study how un- safe code is used, changed, and encapsulated. We found that unsafe code is extensively used in all of our studied Rust software and it is usually used for good reasons (e.g., performance, code reuse), although programmers also try to reduce unsafe usages when they can. We further found that programmers use interior unsafe as a good practice to encapsulate unsafe code. However, explicitly and properly checking interior unsafe code can be di?cult. Sometimes safe encapsulation is achieved by providing correct inputs and environments. Second, we study memory-safety issues in real Rust pro- grams by inspecting bugs in our selected applications and li- 12] and RustSec [

66]. We not only analyze these bugs" behaviors

but also understand how the root causes of them are propa- gated to the e?ect of them. We found that all memory-safety bugs involve unsafe code, and (surprisingly) most of them also involve safe code. Mistakes are easy to happen when programmers write safe code without the caution of other related code being unsafe. We also found that the scope of lifetimein Rust is di?cult to reason about, especially when combined with unsafe code, and wrong understanding of lifetimecauses many memory-safety issues. and blocking bugs [80]. Surprisingly, we found that non- blocking bugs can happen in both unsafe and safe code and thatallblocking bugs we studied are in safe code. Although many bug patterns in Rust follow traditional concurrency bug patterns (e.g., double lock, atomicity violation), a lot of the concurrency bugs in Rust are caused by programmers" misunderstanding of Rust"s (complex) lifetime and safety rules. For all the above three aspects, we make insightful sugges- tions to future Rust programmers and language designers. Most of these suggestions can be directly acted on. For ex- ample, based on the understanding of real-world Rust usage patterns, we make recommendations on good programming practices; based on our summary of common buggy code patterns and pitfalls, we make concrete suggestions on the design of future Rust bug detectors and programming tools. With our empirical study results, we conducted an initial bugs in our studied Rust applications. These encouraging (initial) results demonstrate the value of our empirical study. We believe that programmers, researchers, and language designers can use our study results and the concrete, action- able suggestions we made to improve Rust software devel- opment (better programming practices, better bug detection the following contributions. The ?rst empirical study on real-world Rust program behaviors. and 130 unsafe removals. Close inspection of 70 real Rust memory-safety issues and 100 concurrency bugs.

11 insights and 8 suggestions that can help Rust pro-

grammers and the future development of Rust.

Two new Rust bug detectors and recommendations on

how to build more Rust bug detectors. All study results and our bug detectors can be found at

2 Background and Related Work

This section gives some background of Rust, including its history, safety (and unsafe) mechanisms, and its current sup- port of bug detection, and overviews research projects on

Rust related to ours.

2.1 Language Overview and History

Rust is a type-safe language designed to be both e?cient and safe. It was designed for low-level software development where programmers desire low-level control of resources764

Understanding Memory and Thread Safety Practices and Issues in Real-World Rust Programs PLDI "20, June 15-20, 2020, London, UK

Year2012

201420162018

# of changes500 1000
1500
2000
2500
KLOC 200
400
600
800

Year2012

2016
changes KLOC

Figure 1.Rust History.(Each blue

point shows the number of feature changes in one release version. Each red point shows total LOC in one re- lease version.)

Year2012

201420162018

# of bugs2 4 6 8 10

Year2012

2016
Servo Tock

Ethereum

TikV Redox libs

Figure 2.Time of Studied Bugs.

(Each point shows the number of our studied bugs that were patched during a three month period.)Table 1.

Studied Applications and Libraries.(The

total source lines of code, the number of memory safety bugs, blocking bugs, and non-blocking bugs. libraries: maximum values among our studied li- braries. There are 22 bugs collected from the two

CVE databases.)

SoftwareStart TimeStarsCommitsLOCMemBlkNBlk

Servo2012/021457438096271K141318

Tock2015/051343462160K502

Ethereum2015/11556512121145K2344

TiKV2016/0157173897149K143

Redox2016/08114502129199K2023

libraries2010/073106240225K7610 (so that programs run e?ciently) but want to be type-safe and memory-safe. Rust de?nes a set of strict safety rules and uses the compiler to check these rules to statically rule out many potential safety issues. At runtime, Rust behaves like C and could achieve performance that is close to C. Rust is the most loved language in 2019 according to a

Stack Over?ow survey [

49], and it was ranked as the ?fth

fastest growing language on GitHub in 2018 [

45]. Because

of its safety and performance bene?ts, Rust"s adoption in systems software has increased rapidly in recent years [3,16, Rust as an alternative to C/C++ because of its memory-safety features [9,44]. Rust was ?rst released in 2012 and is now at version 1.39.0.

Figure

1shows the number of feature changes and LOC over

the history of Rust. Rust went through heavy changes in the ?rst four years since its release, and it has been stable since Jan 2016 (v1.6.0). With it being stable for more than three and a half years, we believe that Rust is now mature enough for an empirical study like ours. Figure2shows the ?xed date of our analyzed bugs. Among the 170 bugs, 145 of them were ?xed after 2016. Therefore, we believe our study results re?ect the safety issues under stable Rust versions.

1#[derive(Debug)]

2structTest {v:i32}

3fnf0(_t: Test) {}

4fnf1() {

5lett0 = Test{v: 0};

6f0(t0);

7// println!(?{:?}?, t0);

8if true{

9lett1 = Test{v: 1};

10}

11// println!(?{:?}?, t1);

12}13fnf2() {

14let mutt2 = Test{v: 2};

15letr1 = &t2;

16let mutr2 = &mutt2;

17r2.v = 3;

18// println!(?{:?}?, r1);

19} (a) ownership & lifetime (b) borrow Figure 3.Sample code to illustrate Rust"s safety rules.

2.2 Safety Mechanisms

The goal of Rust"ssafetymechanism is to prevent memory and thread safety issues that have plagued C programs. Its design centers around the notion ofownership. At its core, Rust enforces a strict and restrictive rule of ownership: each value has one and only oneownervariable, and when the owner"slifetimeends, the value will bedropped(freed). The lifetime of a variable is the scope where it is valid,i.e., from its creation to the end of the function it is in or to the end of matching parentheses (e.g., the lifetime oft1in Figure3 spans from line 9 to line 10). This strict ownership rule elim- inates memory errors like use-after-free and double-free, since the Rust compiler can statically detect and rejects the use of a value when its owner goes out of scope (e.g., un- commenting line 11 in Figure

3will raise a compile error).

This rule also eliminates synchronization errors like race conditions, since only one thread can own a value at a time. Under Rust"s basic ownership rule, a value has one exclu- sive owner. Rust extends this basic rule with a set of features to support more programming ?exibility while still ensur- ing memory- and thread-safety. These features (as explained below) relax the restriction of having only one owner for the lifetime of a value but stillprohibit having aliasing and mutation at the same time, and Rust statically checks these extended rules at compile time.

Ownership move.

The ownership of a value can bemoved

from onescopeto another, for example, from a caller to a callee and from one thread to another thread. The Rust compiler statically guarantees that an owner variable cannot be accessed after its ownership is moved. As a result, a caller cannot access a value anymore if the value is dropped in the callee function, and a shared value can only be owned by one thread at any time. For example, if line 7 in Figure3is uncommented, the Rust compiler will report an error, since the ownership oft0has already been moved to function f0()at line 6.

Ownership borrowing.

A value"s ownership can also be

borrowedtemporarily to another variable for the lifetime of this variable without moving the ownership. Borrowing is achieved by passing the value by reference to the borrower variable. Rust does not allow borrowing ownership across threads, since a value"s lifetime cannot be statically inferred across threads and there is no way the Rust compiler can Mutable and Shared references.Another extension Rust adds on top of the basic ownership rule is the support of mul- tiple shared read-only references,i.e., immutable references765

PLDI "20, June 15-20, 2020, London, UKBoqin Qin, Yilun Chen, Zeming Yu, Linhai Song, and Yiying Zhang

1structTestCell { value:i32, }

2unsafe impl Sync forTestCell{}

3implTestCell {

4fnset(&self, i:i32) {

5letp = &self.valueas*const i32 as*mut i32;

6unsafe{*p = i};

7} 8}

Figure 4.Sample code for (interior) unsafe.

that allow read-only aliasing. A value"s reference can also bemutable, allowing write access to the value, but there can only be one mutable reference and no immutable references at any single time. After borrowing a value"s ownership throughmutable reference, the temporary owner has the ex- clusive write access to the value. In Figure3, an immutable reference (r1) and a mutable reference (r2) are created at line 15 and line 16, respectively. The Rust compiler does not allow line 18, since it will make the lifetime ofr1end after line 18, makingr1andr2co-exist at line 16 and line 17.

2.3 Unsafe and Interior Unsafe

Rust"s safety rules are strict and its static compiler checking for the rules is conservative. Developers (especially low-level software developers) often need more ?exibility in writing their code, and some desires to manage safety by themselves (see Section

4for real examples). Rust allows programs to by-

pass its safety checking with theunsafefeature, denoted by the keywordunsafe. A function can be marked asunsafe; a piece of code can be marked asunsafe; and atraitcan be marked as unsafe(Rust traits are similar to interfaces in traditional languages like Java). Code regions marked withunsafewill bypass Rust"s compiler checks and be able to perform ?ve types of functionalities: dereferencing and manipulating raw pointers, accessing and modifying mu- table static variables (i.e., global variables), calling unsafe functions, implementing unsafe traits, and accessingunion ?elds. Figure4shows the implementation of a simple struct, which implements the unsafeSynctrait at line 2. The pointer operation at line 6 is in an unsafe code region. Rust allows a function to have unsafe code only internally; such a function can be called by safe code and thus is con- sidered "safe" externally. We call this patterninterior unsafe (e.g., functionset()in Figure4). The design rationale of interior unsafe code is to have the ?exibility and low-level management of unsafe code but to encapsulate the unsafe code in a carefully-controlled inter- face, or at least that is the intention of the interior unsafe design. For example, Rust uses interior-unsafe functions to allow the combination of aliasing and mutation (i.e., bypass- ing Rust"s core safety rules) in a controlled way: the internal unsafe code can mutate values using multiple aliases, but these mutations are encapsulated in a small number of im- mutable APIs that can be called in safe code and pass Rust"s safety checks. Rust calls this featureinterior mutability. Func- tionset()in Figure4is an interior mutability function. Its inputselfis borrowed immutably, but thevalue?eld of selfis changed through pointerp(an alias) at line 6. Many APIs provided by the Rust standard library are interior-unsafe functions, such as

Arc,Rc,Cell,RefCell,

Mutex, andRwLock. Section4.3presents our analysis of inte- rior unsafe usages in the Rust standard library.

2.4 Bug Detection in Rust

Rust runtime detects and triggers a panic on certain types of bugs, such as bu?er over?ow, division by zero and stack over?ow. Rust also provides more bug-detecting features in its debug build mode, including detection of double lock and integer over?ow. These dynamic detection mechanisms Rust provides only capture a small number of issues. Rust uses LLVM [32] as its backend. Many static and dy- namic bug detection techniques [4,40,88,89] designed for C/C++ can also be applied to Rust. However, it is still valu- able to build Rust-speci?c detectors, because Rust"s new language features and libraries can cause new types of bugs as evidenced by our study. Researchers have designed a few bug detection techniques forRust.Rust-clippy[

64]isastaticdetectorformemorybugs

that follow certain simple source-code patterns. It only cov- ers a small amount of buggy patterns. Miri [43] is a dynamic memory-bug detector that interprets and executes Rust"s mid-level intermediate representation (MIR). Junget al.pro- posed an alias model for Rust [27]. Based on this model, they built a dynamic memory-bug detector that uses a stack to dy- namically track all valid references/pointers to each memory location and reports potential unde?ned behavior and mem- ory bugs when references are not used in a properly-nested manner. The two dynamic detectors rely on user-provided inputs that can trigger memory bugs. From our experiments,

Miri also generates many false positives.

These existing Rust bug detection tools all have their own limitations, and none of them targets concurrency bugs. An empirical study on Rust bugs like this work is important. It can help future researchers and practitioners to build more Rust-speci?c detectors. In fact, we have built two detectors based on our ?ndings in this study, both of which reveal previously undiscovered bugs.

2.5 Formalizing and Proving Rust"s Correctness

Several previous works aim to formalize or prove the cor- rectness of Rust programs [

2,13,28,29,61]. RustBelt [28]

2]. After formalizing Rust"s type system in CLP, Rust programs can be generated by solving a constraint satisfaction prob- lem, and the generated programs can then be used to detect bugs in the Rust compiler [13]. K-Rust [29] compares the execution of a Rust program in K-Framework environment766

Understanding Memory and Thread Safety Practices and Issues in Real-World Rust Programs PLDI "20, June 15-20, 2020, London, UK

with the execution on a real machine to identify inconsis- tency between Rust"s speci?cation and the Rust compiler"s implementation. Di?erent from these works, our study aims to understand common mistakes made by real Rust develop- ers, and it can improve the safety of Rust programs from a practical perspective.

2.6 Empirical Studies

In the past, researchers have conducted various empirical studies on di?erent kinds of bugs in di?erent programming languages [7,19,20,24,34,38,39]. As far as we know, we are the ?rst study on real-world mistakes of Rust code. There are only a few empirical studies on Rust"s unsafe code usage similar to what we performed in Section4. How- ever, the scales of these studies are small on both the appli- cations studied and the features studied. One previous study counts the number of Rust libraries that depend on external C/C++ libraries [72]. One study counts the amount of unsafe code incrates.io[50]. Another analyzes several cases where interior unsafe is not well encapsulated [51]. Our work is the ?rst large-scale, systematic empirical study on unsafe in Rust. We study many aspects not covered by previous works.

3 Study Methodology

Although there are books, blogs, and theoretical publications that discuss Rust"s design philosophy, bene?ts, and unique features, it is unclear how real-world Rust programmers use Rust and what pitfalls they make. An empirical study on real-world Rust software like ours is important for several reasons. It can demonstrate how real programmers use Rust and how their behavior changes over time. It can also reveal what mistakes (bugs) real programmers make and how they ?x them. Some of these usage patterns and mistakes could be previously unknown. Even if they are, we can demonstrate through real data how often they happen and dig into deeper reasons why programmers write their code in that way. Our study re?ects all the above values of empirical studies. e?orts inspecting and understanding real Rust code. These e?orts result in this paper, which we hope will fuel future research and practices to improve Rust programming andquotesdbs_dbs5.pdfusesText_10

[PDF] rust kernel

[PDF] rust kernel module

[PDF] rust linux

[PDF] rust os phill

[PDF] rust programming language book github

[PDF] rv rentals in paris texas

[PDF] rv requirements

[PDF] rv seating capacity

[PDF] rvc form e

[PDF] rwandan francs to dollars in 1994

[PDF] rythme cardiaque au repos

[PDF] rythme cardiaque au repos femme

[PDF] rythme cardiaque au repos selon l'age

[PDF] s corp tax return due date

[PDF] s1 form france