Verification of Safety Functions Implemented in Rust - a Symbolic Execution based approach

Lindner, Marcus; Fitinghoff, Nils; Eriksson, Johan; Lindgren, Per

doi:10.1109/indin41052.2019.8972014

Cited by 5 publications

(2 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…An interesting feature is support for automatically deriving "proof drivers" using a technique reminiscent of that for test case generation [22]. KLEE employs symbolic execution and was also extended to support Rust [16,17]. Unlike CRUST this tool considers a larger number of errors, including arithmetic overflow and buffer overruns (ie., not just those related to memory unsafety).…”

Section: Related Workmentioning

confidence: 99%

On the Termination of Borrow Checking in Featherweight Rust

Payet

Pearce

Spoto

2022

Lecture Notes in Computer Science

View full text Add to dashboard Cite

A distinguished feature of the Rust programming language is its ability to deallocate dynamically-allocated data structures as soon as they go out of scope, without relying on a garbage collector. At the same time, Rust lets programmers create references, called borrows, to data structures. A static borrow checker enforces that borrows can only be used in a controlled way, so that automatic deallocation does not introduce dangling references. Featherweight Rust provides a formalisation for a subset of Rust where borrow checking is encoded using flow typing [25]. However, we have identified a source of non-termination within the calculus which arises when typing environments contain cycles between variables. In fact, it turns out that well-typed programs cannot lead to such environments -but this was not immediately obvious from the presentation. This paper defines a simplification of Featherweight Rust, more amenable to formal proofs. Then it develops a sufficient condition that forbids cycles and, hence, guarantees termination. Furthermore, it proves that this condition is, in fact, maintained by Featherweight Rust for welltyped programs.

show abstract

Section: Related Workmentioning

confidence: 99%

On the Termination of Borrow Checking in Featherweight Rust

Payet

Pearce

Spoto

2022

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…This employs a custom C code generator for £ ¢ ¡ rustc and correctly identified bugs arising during development of Rust's standard library. Finally the widely used symbolic execution tool, Klee [27], was also extended for Rust allowing assertions to be checked statically [83,84].…”

Section: Rustmentioning

confidence: 99%

A Lightweight Formalism for Reference Lifetimes and Borrowing in Rust

Pearce

2021

ACM Trans. Program. Lang. Syst.

View full text Add to dashboard Cite

Rust is a relatively new programming language that has gained significant traction since its v1.0 release in 2015. Rust aims to be a systems language that competes with C/C++. A claimed advantage of Rust is a strong focus on memory safety without garbage collection. This is primarily achieved through two concepts, namely, reference lifetimes and borrowing . Both of these are well-known ideas stemming from the literature on region-based memory management and linearity / uniqueness . Rust brings both of these ideas together to form a coherent programming model. Furthermore, Rust has a strong focus on stack-allocated data and, like C/C++ but unlike Java, permits references to local variables. Type checking in Rust can be viewed as a two-phase process: First, a traditional type checker operates in a flow-insensitive fashion; second, a borrow checker enforces an ownership invariant using a flow-sensitive analysis. In this article, we present a lightweight formalism that captures these two phases using a flow-sensitive type system that enforces “ type and borrow safety .” In particular, programs that are type and borrow safe will not attempt to dereference dangling pointers. Our calculus core captures many aspects of Rust, including copy- and move-semantics, mutable borrowing, reborrowing, partial moves, and lifetimes. In particular, it remains sufficiently lightweight to be easily digested and understood and, we argue, still captures the salient aspects of reference lifetimes and borrowing. Furthermore, extensions to the core can easily add more complex features (e.g., control-flow, tuples, method invocation). We provide a soundness proof to verify our key claims of the calculus. We also provide a reference implementation in Java with which we have model checked our calculus using over 500B input programs. We have also fuzz tested the Rust compiler using our calculus against 2B programs and, to date, found one confirmed compiler bug and several other possible issues.

show abstract

Verifying Whiley Programs with Boogie

2022

View full text Add to dashboard Cite

The quest to develop increasingly sophisticated verification systems continues unabated. Tools such as Dafny, Spec#, ESC/Java, SPARK Ada and Whiley attempt to seamlessly integrate specification and verification into a programming language, in a similar way to type checking. A common integration approach is to generate verification conditions that are handed off to an automated theorem prover. This provides a nice separation of concerns and allows different theorem provers to be used interchangeably. However, generating verification conditions is still a difficult undertaking and the use of more “high-level” intermediate verification languages has become commonplace. In particular, Boogie provides a widely used and understood intermediate verification language. A common difficulty is the potential for an impedance mismatch between the source language and the intermediate verification language. In this paper, we explore the use of Boogie as an intermediate verification language for verifying programs in Whiley. This is noteworthy because the Whiley language has (amongst other things) a rich type system with considerable potential for an impedance mismatch. We provide a comprehensive account of translating Whiley to Boogie which demonstrates that it is possible to model most aspects of the Whiley language. Key challenges posed by the Whiley language included: the encoding of Whiley’s expressive type system and support for flow typing and generics; the implicit assumption that expressions in specifications are well defined; the ability to invoke methods from within expressions; the ability to return multiple values from a function or method; the presence of unrestricted lambda functions; and the limited syntax for framing. We demonstrate that the resulting verification tool can verify significantly more programs than the native Whiley verifier which was custom-built for Whiley verification. Furthermore, our work provides evidence that Boogie is (for the most part) sufficiently general to act as an intermediate language for a wide range of source languages.

show abstract

Verification of Safety Functions Implemented in Rust - a Symbolic Execution based approach

Cited by 5 publications

References 9 publications

On the Termination of Borrow Checking in Featherweight Rust

On the Termination of Borrow Checking in Featherweight Rust

A Lightweight Formalism for Reference Lifetimes and Borrowing in Rust

Verifying Whiley Programs with Boogie

Contact Info

Product

Resources

About