Verify the Rust's Standard Library's 7,500 Unsafe Functions - and Win 'Financial Rewards' (devclass.com) 9
The Rust community has "recognized the unsafety of Rust (if used incorrectly)," according to a blog post by Amazon Web Services.
So now AWS and the Rust Foundation are "crowdsourcing an effort to verify the Rust standard library," according to an article at DevClass.com, "by setting out a series of challenges for devs and offering financial rewards for solutions..." Rust includes ways to bypass its safety guarantees though, with the use of the "unsafe" keyword... 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. [28% of the soundness issues were discovered in 2024.]
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.... A GitHub repository provides a fork of the Rust code and includes a set of challenges, currently 13 of them... 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.
Thanks to Slashdot reader sean-it-all for sharing the news.
So now AWS and the Rust Foundation are "crowdsourcing an effort to verify the Rust standard library," according to an article at DevClass.com, "by setting out a series of challenges for devs and offering financial rewards for solutions..." Rust includes ways to bypass its safety guarantees though, with the use of the "unsafe" keyword... 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. [28% of the soundness issues were discovered in 2024.]
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.... A GitHub repository provides a fork of the Rust code and includes a set of challenges, currently 13 of them... 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.
Thanks to Slashdot reader sean-it-all for sharing the news.
7500 sounds like a lot. (Score:3)
Has an audit been conducted to see which of these functions could be reworked in a 'safe' manner or those which are only present for interoperability with C?
New paradigms and what not...
Bug bounty (Score:3)
Pardon me while I go and write myself a minivan [snbforums.com].
Pay some workers? (Score:3, Insightful)
If Amazon wants to have verify the safety of Rust functions, why don't they do it themselves? Is it to much to ask that businesses actually hire workers to do the work that they want done? I feel like this is rich man begging that the poor contribute to do work for free so that the rich man can afford another private jet.
Re: (Score:3)
Is it to much to ask
In this case, yes. The skills involved are not easily hirable. It's rarified talent: elite programmers that can comprehend "unsafe" and all of it's implications in the Rust language (which are subtle, despite what the prevailing peanut gallery around here thinks,) have a deep understanding of one or more platform (winapi, posix, etc.) APIs that unsafe is frequently used with, deep experience with one or more CPU architecture memory models and synchronization primitives, knowledge of and the ability to ana
Who wrote those 7500 functions? (Score:3, Insightful)
-ffs, stop clowning around with community rules and do the work you claim you have done.
Re: (Score:3)
Security and safety is a process, not a destination. How do you have a five digit id here and know nothing about technology?
Re: (Score:2)
How do you have a five digit ID and don't recognize a pointed comment.
The gist is that Rust is no better than C if you have to worry about programming around unsafe primitives. In fact it's far worse. A perceived guard rail will tend to make programmers act with more disregard for security.
The better paradigm is to use C and program it safely. Take away the pablum and guard rails and safety net and add a little healthy fear and you'll end up with better code.
Perceived safety is more dangerous than known
Re: (Score:2)
It's difficult to take you seriously after you fail to count up to 6. Off-by-one errors are exactly the kind of mistakes C programmers make that are easily caught by Rust and most other languages. Maybe you're not as smart as you think you are.
Re: (Score:3)
These are functions already marked as being unsafe, meaning they already can be misused, and that's ok. Say for example Vec::get_unchecked(), which lets you get a value from a specified index without doing a bounds check. The compiler leaves it up to the programmer to ensure that they aren't doing out of bounds access, and no sane programmer would do this unless there was really some compelling reason to (which is rare, hence in the Rust community any use of unsafe generally carries whiff of code stench wit