Sealed Rust: A plan to bring Rust to safety critical software domains
ferrous-systems.com
ferrous-systems.com
[1] https://www.autosar.org/fileadmin/user_upload/standards/adap...
That sounds like it would still be necessary to standardize, specify and prove a lot about Rust and its compiler, to exploit those facets of Rusts' behaviour?
Also, please let the community know how we can help. Whether that involves writing code, unit tests, or financial contributions with a Patreon-like system. I really want to see this become a reality and a first class citizen of the Rust ecosystem.
Feel free to reach out at sealed-rust at ferrous-systems.com!
It seems like some Rust developers are particular about the governance of the language and overall ecosystem [1]. This strict subsetting seems like it could be a good opportunity to engage the team. Has that already happened? If not, maybe it would be good to create an RFC and/or working group, even if the effort happens independent from the core rustlang dev. If there's some explicit endorsement, it could include guidance and an easier way to upstream changes.
> Who is this effort aimed towards?
I wonder if "cryptography" is a domain that applies here? Things like enclaves/signed bootloaders are things where mistakes can be very costly.
Cryptography is certainly an interesting target - they certainly could benefit from the specification of the language, despite not being legally required similar to the other domains listed here.
He's also building Rust tooling for finding bugs in this space, see for example miri.
https://play.rust-lang.org/?version=stable&mode=debug&editio...
(click "Tools" -> "Miri")
This will figure out that you do produce an illegal borrow in that unsafe code.
It is an ambitious undertaking, but strikes me more like a way to try to make more money off of Rust.
It is definitely a moonshot since Ada has a 35-year lead here since it has been used for critical systems since the 1980s. Ada 2020 will be out soon and pulls in several of the innovative ideas that Rust pioneered.
I am not saying that it is not possible, I am just skeptical of the reasons for trying to push Rust in the critical systems direction so suddenly.
What Ada has on it are its IDE's, MDD, and testing tools that industry is currently using. With stuff like RV-Match and Astree Analyzer, MISRA-C is probably safer than Rust. Rust needs more tooling to be competitive.
The problem is mostly certification and having a stable spec for the language.
The tooling that is needed is mostly productivity tooling, like better code completion (rust analyzer is now pretty promising after RLS kind of stagnated). And maybe better ways to show code coverage.
The problem for usage in safety critical areas is mostly certification and having a stable spec for the language.
Lacking a strict type system, discriminated unions, if-expressions (they exist in C but are often discouraged because of readability concerns), match expressions, macros that are AST members, procedural macros, guaranteed mutability restrictions with the borrow checker, etc. are things that a coding rule and analyzer can't bring into a language like C. Most importantly no module system to keep yourself somewhat isolated from third party code that you have no control over.
Add to that that you have humans checking each violation whether they think it will cause problems. Humans fixing these. And in a lot of cases humans not fixing these. Then you're actually still left with a lot of code that à stricter compiler like Rust or Ada would have rejected in the first place.
The advantage of Ada and Rust is they're cheaper and faster to get safe code out of. Businesses will like that. I don't know how compiler qualification plays out these days.
Lacking a strict type system, discriminated unions, if-expressions (they exist in C but are often discouraged because of readability concerns), match expressions, macros that are AST members, procedural macros, guaranteed mutability restrictions with the borrow checker, etc. are things that a coding rule and analyzer can't bring into a language like C. Most importantly no module system to keep yourself somewhat isolated from third party code that you have no control over.
Add to that that you have humans checking each violation whether they think it will cause problems. Humans fixing these. And in a lot of cases humans not fixing these. Then you're actually still left with a lot of code that a stricter compiler like Rust or Ada would have rejected in the first place.
Furthermore, there's zero proof that e.g. macros, match or variant types have any impact on code quality. Bringing the module system into this is really grasping at straws.
https://www.adacore.com/books/safe-and-secure-software
SPARK is a subset without pointers that feeds information about the program into solvers that prove absence of common classes of errors like overflows and divide by zero. Inspired by Rust, recent work is adding pointers. Praxis' Correct-by-Construction defaulted on Ada with SPARK saved for most critical stuff, esp safety- or security-enforcing.
Right now, Rust is mainly ahead of Ada on dealing with the pointer safety and better safe concurrency. Ada's Ravenscar aimed for safety but was restrictive. That's my take.
Ada/SPARK wins in almost everything else, it has multiple implementations, proven industrial use since early 80's (first standard was in 1983), IDE tooling, it is a common theme in high security computing conferences, libraries for safety critical domains, and people that know the language.
Naturally it has a price disadvantage for FOSS devs that are allergic to GNAT, given that the remaining Ada compilers are well into the enterprise price range.
I don't see how delaying would help in the long run.
(Full disclosure: I'm MD at Ferrous Systems)
There is nothing wrong with making money off of Rust, and one of the goals of this standardization is to erase doubts that Rust is ready for commercial prime time.
The proposed specification and standardization effort is a enormous undertaking and asking for that effort to be payed for is fair (they even spell out the two funding alternatives).
If you are trying to say that this is a quick cash-grab by Ferrous Systems, you should also consider that their members have been doing a lot of upaid work for a _long_ time for Rust and its community and most of the time without direct monetary benefit.
Agreed. After what Oracle has done with Java, I am hesitant when corporations come bearing gifts.
> If you are trying to say that this is a quick cash-grab by Ferrous Systems, you should also consider that their members have been doing a lot of upaid work for a _long_ time for Rust and its community and most of the time without direct monetary benefit.
I am not making any accusations against Ferrous Systems. I have no reason to believe that they are not well-intentioned.
I am just concerned about what might happen to the Rust community when truckloads of money gets involved. Rust has an incredible community and has made rapid progress. I hope that it continues that way.
Well, either truckloads of money get involved, or the community will fail to grow. I'm sure some people would love to keep the Rust community exactly as they currently enjoy it (for a multitude of different reasons, but I think most of them somewhat selfish), but for Rust to grow, there has to be money involved by the nature of how our economy works.
Either Rust is useful and provides benefit over alternatives, in which case it's also useful and provides benefit for commercial interests, or it isn't.
That isn't to say your concern is entirely unwarranted. It makes sense to be leery about what the money is applied to and how it influences the outcomes, as that isn't in the best interest of the community either.
Ah okay, I can very well understand that concern.
I'm personally not too worried about it, as I feel like Rust already had a bit of a "truckloads of money" moment with the cryptocurrency hype the last 2 years. During that time that sector probably became the biggest one in terms of number of employees working with Rust full-time. I can't say I noticed any significant effects from that in the Rust community. That might in part be due to the fact that your stereotypical Rust developer is very critical of blockchain technology, but I think the Rust community has fared pretty well in that money influx exercise.
I honestly don’t know what to make of that comparison. On one hand, as a sailing fan, I’d love to own a boat competing in the America’s Cup (1), on the other hand I can’t really see why you insult us that way.
On a more serious note: Companies with money will enter (and already have entered) the rust space, but unlike Java which was designed as a proprietary language and never free as open source, the rust language cannot be owned the way oracle owns java. So in that regard I wouldn’t worry. That doesn’t mean that all players will be well intentioned, but the leverage a hostile player can gain is substantially more limited.
(1) The Wannsee certainly would make a great training ground for Team Ferrous!
After Google screwed a deal that could eventually save Sun, and letting it sink afterwards.
Or keeping MaximeVM alive and spending truckloads of money to make it into GraalVM, which also supports the fastest implementation of Ruby?
Maybe it was merging the JIT/AOT compiler from JRockit into GraalVM project and eventually into OpenJDK.
Or even, a infrastructure monitoring system, capable to plug into production systems with very little impact probs.
Yeah Oracle has done a lot of bad stuff to Java.
To be quite honest here: Ferrous is a for-profit endeavor, but my co-founders and most of our employees both have been involved in the rust community for a long time. We’re also sponsoring conferences, speakers, open source projects in the rust space since the beginning, for example rust-analyzer (1)
So yes, we intend to find funding, people working on this need to be paid. People doing the organizational legwork (such as running the company, keeping the office tidy, making sure there’s enough coffee) need to be paid. Standards documents need to be paid. This isn’t something we as a 6-people company can self-fund. But we intend to make as much of this open source as possible. If there’s sufficient funding, all of it.
On the other side, we’ve been at embedded conferences (even before ferrous as a company was a thing), talking to people in the automobile, robotics and aerospace sector and the question of “is this certified/certifiable” has come up quite a few times. There’s definite interest in finding a replacement for C in that space, and that’s where rust could shine. It’s certainly early, but this is not a project that will come to fruition in the short run. It’s something that rust could profit from in a decade.
(1) https://github.com/rust-analyzer/rust-analyzer/blob/master/R...
Despite being entrenched, Ada needs the competition in the critical systems space. Rust is showing great promise as a competitor.
We also respect Ada a ton and fundamentally believe that clients having actual choice improves all products.