Understanding memory and thread safety practices and issues in real-world Rust programs

Qin, Boqin; Chen, Yilun; Yu, Zeming; Song, Linhai; Zhang, Yiying

doi:10.1145/3385412.3386036

Cited by 53 publications

(14 citation statements)

References 33 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…To programmers, this manifests as a large number of false positive errors or warnings about problems that will never arise in practice. Many programmers find Rust hard to learn and to use correctly [1,4,29,22,30]. Rust's version of ownership types [23] bans common idioms such as circular or doublylinked lists, to the point where the difficulty of implementing a data structure often taught at first year has now become an Internet trope [3,26,17,9].…”

Section: Rusty Linksmentioning

confidence: 99%

Rusty Links in Local Chains

Noble¹,

Mackay²,

Wrigstad³

2022

Preprint

View full text Add to dashboard Cite

Rust successfully applies ownership types to control memory allocation. This restricts the programs' topologies to the point where doubly-linked lists cannot be programmed in Safe Rust. We sketch how more flexible "local" ownership could be added to Rust, permitting multiple mutable references to objects, provided each reference is bounded by the object's lifetime. To maintain thread-safety, locally owned objects must remain thread-local; to maintain memory safety, local objects can be deallocated when their owner's lifetime expires.

show abstract

Section: Rusty Linksmentioning

confidence: 99%

Rusty Links in Local Chains

Noble¹,

Mackay²,

Wrigstad³

2022

Preprint

View full text Add to dashboard Cite

show abstract

“…Jung [2016]) and addressing it, in general, requires extremely sophisticated formal reasoning, as explored in the context of the RustBelt project [Jung et al 2018]. Qin et al [2020] perform manual code inspections of 850 selected instances of unsafe Rust, i.e., unsafe blocks or functions, to elicit the motivation for using unsafe code and to explore the memory safety and concurrency errors caused by these instances of unsafe code. They select examples for their study by analysing bug reports and filtering commit messages for keywords indicating memory errors.…”

Section: Related Workmentioning

confidence: 99%

How do programmers use unsafe rust?

Astrauskas

Matheja

Poli

et al. 2020

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

Rust's ownership type system enforces a strict discipline on how memory locations are accessed and shared. This discipline allows the compiler to statically prevent memory errors, data races, inadvertent side effects through aliasing, and other errors that frequently occur in conventional imperative programs. However, the restrictions imposed by Rust's type system make it difficult or impossible to implement certain designs, such as data structures that require aliasing (e.g. doubly-linked lists and shared caches). To work around this limitation, Rust allows code blocks to be declared as unsafe and thereby exempted from certain restrictions of the type system, for instance, to manipulate C-style raw pointers. Ensuring the safety of unsafe code is the responsibility of the programmer. However, an important assumption of the Rust language, which we dub the Rust hypothesis, is that programmers use Rust by following three main principles: use unsafe code sparingly, make it easy to review, and hide it behind a safe abstraction such that client code can be written in safe Rust.Understanding how Rust programmers use unsafe code and, in particular, whether the Rust hypothesis holds is essential for Rust developers and testers, language and library designers, as well as tool developers. This paper studies empirically how unsafe code is used in practice by analysing a large corpus of Rust projects to assess the validity of the Rust hypothesis and to classify the purpose of unsafe code. We identify queries that can be answered by automatically inspecting the program's source code, its intermediate representation MIR, as well as type information provided by the Rust compiler; we complement the results by manual code inspection. Our study supports the Rust hypothesis partially: While most unsafe code is simple and well-encapsulated, unsafe features are used extensively, especially for interoperability with other languages. CCS Concepts: • Software and its engineering → Software libraries and repositories; General programming languages; Software organization and properties; • General and reference → Empirical studies.

show abstract

“…The different JVM crash patterns caused by those usages are analyzed by Huang et al [13]. Recently, two studies analyzed unsafe usages in Rust projects and identified that unsafe is widely used to improve performance or to reuse existing code [3], [14]. Furthermore, work was presented on how to ensure memory safety while using unsafe in Rust [15].…”

Section: Related Workmentioning

confidence: 99%

Uncovering the Hidden Dangers: Finding Unsafe Go Code in the Wild

Lauinger

Baumgärtner

Wickert

et al. 2020

2020 IEEE 19th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom)

View full text Add to dashboard Cite

The Go programming language aims to provide memory and thread safety through measures such as automated memory management with garbage collection and a strict type system. However, it also offers a way of circumventing this safety net through the use of the unsafe package. While there are legitimate use cases for unsafe, developers must exercise caution to avoid introducing vulnerabilities like buffer overflows or memory corruption in general. In this work, we present go-geiger, a novel tool for Go developers to quantify unsafe usages in a project's source code and all of its dependencies. Using go-geiger, we conducted a study on the usage of unsafe in the top 500 most popular open-source Go projects on GitHub, including a manual analysis of 1,400 code samples on how unsafe is used. From the projects using Go's module system, 38% directly contain at least one unsafe usage, and 91% contain at least one unsafe usage in the project itself or one of its transitive dependencies. Based on the usage patterns found, we present possible exploit vectors in different scenarios. Finally, we present go-safer, a novel static analysis tool to identify dangerous and common usage patterns that were previously undetected with existing tools.

show abstract

Understanding memory and thread safety practices and issues in real-world Rust programs

Cited by 53 publications

References 33 publications

Rusty Links in Local Chains

Rusty Links in Local Chains

How do programmers use unsafe rust?

Uncovering the Hidden Dangers: Finding Unsafe Go Code in the Wild

Contact Info

Product

Resources

About