AWS will pay devs to verify Rust standard library because of 7,500 unsafe functions and enormity of task

AWS will pay devs to verify Rust standard library because of 7,500 unsafe functions and enormity of task

AWS, in collaboration with the Rust Foundation, is crowdsourcing an effort to verify the Rust standard library, by setting out a series of challenges for devs and offering financial rewards for solutions.

The safety of the Rust programming language is key to its appeal. Recommendations to switch from C and C++ to Rust have come from a wide range of sources, including the US government, Microsoft Azure CTO Mark Russinovich, and Rust is now supported for use in the Linux kernel.

Rust includes ways to bypass its safety guarantees though, with the use of the “unsafe” keyword. The documentation remarks that “If Rust didn’t let you do unsafe operations, you couldn’t do certain task,” such as directly interacting with the operating system, though it adds that “you use unsafe Rust at your own risk,” where risks include null pointer dereferencing, a common source of security issues.

The issue AWS highlights is that even if developers use only safe code, most applications still depend on the Rust standard library. AWS states that there are approximately 7.5K unsafe functions in the Rust Standard Library and notes that 57 “soundness issues” and 20 CVEs (Common Vulnerabilities and Exposures) have been reported in the last three years. The cloud giant also claimed that “the rate of change of the standard libraries is faster and more unsound.” 

Marking a function as unsafe does not mean it is vulnerable, only that Rust does not guarantee its safety. AWS plans to reduce the risk by using tools and techniques for formal verification of key library code, but believes that “a single team would be unable to make significant inroads” for reasons including the lack of a verification mechanism in the Rust ecosystem and what it calls the “unknowns of scalable verification.”

The plan therefore is to turn this over to the community, by posing challenges and rewarding developers for solutions. The Rust Foundation is supporting the effort and is hosting the challenge.

A GitHub repository provides a fork of the Rust code and includes a set of challenges, currently 13 of them. Solutions have to use approved tools (though there is scope to submit a new tool). The rules also state that the solution must not impact the runtime logic of the standard library.

The Rust Foundation says that there is a financial reward tied to each challenge, and that the “challenge rewards committee is responsible for reviewing activity and dispensing rewards.” How much will be paid though is not stated.

Despite the wide admiration for Rust, there is no formal specification for the language, an issue which impacts formal verification efforts.

The current list of challenges is as follows:

  1. Verify core transmuting methods
  2. Verify the memory safery of core intrinsics using raw pointers
  3. Verifying Raw Pointer Arithmetic Operations
  4. Memory safety of BTreeMap’s btree::node module
  5. Verify functions iterating over inductive data type: linked_list
  6. Safety of NonNull
  7. Safety of Methods for Atomic Types and ReentrantLock
  8. Contracts for SmallSort
  9. Safe abstractions for core::time::Duration
  10. Memory safety of String
  11. Safety of Methods for Numeric Primitive Types
  12. Safety of NonZero
  13. Safety of CStr