Rust's Foundation Announces a New 'Safety-Critical Rust Consortium'

This week the Rust Foundation jointly announced "the Safety-Critical Rust Consortium" with industry partners including Arm, AdaCore, Lynx Software Technologies, and Toyota's mobility tech subsidiary Woven. Its goal is supporting "responsible use" of Rust "in safety-critical software — systems whose failure can impact human life or cause severe environmental or property harm."

"This is exciting," said Rust creator Graydon Hoare in a statement. "I am truly pleased to see the Rust Foundation and anyone in the safety-critical space coming together on this topic."

From the announcement: "Safety is our foremost priority in vehicle software development. Traditionally, achieving the highest levels of safety has been a complex and lengthy endeavor, requiring the use of specialized tools and processes beyond the programming language," said JF Bastien, Distinguished Engineer at Woven by Toyota. "We are therefore pleased to collaborate with leading experts in the safety industry to integrate new tools such as Rust into our safety-critical systems...." Industries that are particularly concerned with functional safety include transportation (such as automotive, aviation, space), energy, life sciences, and more. Because of their potential impacts, these industries are often regulated, have liability considerations, and are guided by standards... These industries have decades of experience delivering products, learning from iterating based on real-world feedback, and improving processes. An ecosystem of tools and tool vendors have evolved, and best practices have been learned to create a safety culture around tooling.

Rust offers particular advantages in terms of developer ergonomics, productivity and software quality; however, it lacks a deep and established well of safety-processes and collective industry knowledge of safety-critical systems. Without closing this gap, a developer must primarily rely on best practices and normative precautions, which can limit innovation. Rust developers who stray from the well-trod path can find themselves facing an inquiry were an accident to occur. In these circumstances, anything that seems unusual will be investigated for fault.

This risk creates a disincentive to widespread Rust adoption, leaving developers unable to reap all its advantages while potentially facing financial, reputational and moral costs. The gap in safety-critical resources within the Rust programming language ecosystem is also an exciting opportunity. By rapidly incorporating lessons learned from years of careful development and past mistakes in the wider open source ecosystem, Rust can become a valuable component of a safety toolkit adaptable to various safety-critical industries and severity levels.
"Work under the consortium will begin with the creation of a public charter and goals," according to the announcement, with a scope possibly including "the development of guidelines, linters, libraries, static analysis tools, formal methods and language subsets to meet industrial and legal requirements. The group may further shepherd Rust Foundation-funded implementation work, including grants to existing academic teams or FOSS projects... The group will further attempt to coordinate with and expand on existing safety-critical projects and standards including SAE JA1020.
The group will maintain communication with the larger Rust Project, and "The Consortium's deliverables will be developed and licensed in a manner compatible with other Rust Project endeavors."

Safety Industry

[byronivs]

Can we all maybe just not do this?

Re:

[Jeremi]

Can we all maybe just not do this?

Not include any software as part of safety-critical systems?

I suppose that's an option, although it would drastically limit the complexity of the tasks that those systems could perform. Things like SpaceX-style retro-propulsion rocket landings would probably become impossible, for example.

Re:

[codebase7]

They were referring to creating a "Safety" industry who's sole job is to extract a kind of use / compliance tax from the general public. These tend to be geared toward protecting established industries rather than any actual protection of the public. While also hampering / forbidding any attempts at actual innovation that might disturb the market, and that's a best case scenario. Worse case is it becomes a case of institutionalized racketeering. Which may or may not involve real violence against those at th

Re:

[codebase7]

Step 1) Convince others that the public should not know something.

Step 2) When problems arrive due to mass ignorance, modify your product so that it's "easy to use" / "set it and forget it" while doubling down on promoting public ignorance. Make massive amounts of money.

Step 3) When more severe problems arrive due to mass ignorance and the public starts to fear the products and their creators, spread rumors that the competition is acting recklessly and proclaim loudly, that only "proper", "tested", "sec

Functional safety ISOs?

[snikulin]

As far as I know, no functional safety ISO recognizes or recommends Rust (the ISOs and/or TUV recognize and recommend subsets of C and C++, among others).
Without such recognition, no functional safety software engineers will touch Rust.

Re:

[Entrope]

Aviation standards -- formally "guidance" rather than standards, such as RTCA/DO-178, DO-278 and their European equivalents -- are language-agnostic specifically because they've seen these fad languages come and go, usually retaining some vestige of adherents (like Ada does). Did the "functional safety" standard crowd not also take advantage of that experience?

To be clear, there are some add-on guidance documents like DO-331, DO-332 and DO-333 that address techniques that are more common in particular lang

Re:

[ThosLives]

As the other reply said, safety standards don't really care too much about the language. The compiler, however, is considered critical. You'd have to either develop the compiler itself to a safety standard or be able to otherwise prove the safety of the emitted machine code. Note this can't be "proof in theory", this has to be proof in practice.

Sometimes you end up having to resort to inspection of the machine code - which is very tedious and expensive. Which is part of why truly safe things cost quite a

Re:

[Phillip2]

If the practices are "fairly standard", then it is likely that they do. But more specifically the announcement includes ferrous systems and this is the kind of thing they do specifically with Rust. Many of the other companies named have these expertise in other domains and toolchains.

Re:

[gweihir]

Rust fails one very fundamental requirement for safety critical use: It is far too complex.

Re:

[Phillip2]

It's an interesting point. Much of the complexity of Rust is actually in the type and borrowing system. The functional core of the language is much simpler: struct, enums and function. And the standard library is small.

Safety-critical software :o

[Mirnotoriety]

How about designing a safety-critical Memory Management Unit [wisc.edu] MMU that can successfully isolate processes.

Re:

[codebase7]

Will not ever work. The whole point of an MMU is to programmatically declare that some sections of memory can hold instructions while others cannot. I.e. It's a damn whitelist that the running system can edit. No amount of "safety" BS is going to change that. If you want the hardware to reliably enforce limits then the running system cannot be allowed to change the limits in software. Anything less is just a game of hide and seek for hackers, and I think we all know who always wins that game.

Re:

[Mirnotoriety]

> The whole point of an MMU is to programmatically declare that some sections of memory can hold instructions while others cannot.

You are in error. A MMU is designed to ensure process isolation, access control, designate executable and non-executable regions, manage virtual to physical address translation, access permissions, and more.

> No amount of "safety" BS is going to change that ..

Tell that to the avionics industry.

Re: OOM

[ArmoredDragon]

That's already being worked on. Nightly rust currently has a lot of ways of handling that in the std allocators. Stuff tends to stay in nightly for a very long time though -- rust takes a much more measured approach to introducing new language features than e.g. C++.

Re:

[ThosLives]

Most (or at the very least, quite a few) truly high-criticality software standards prohibit dynamic memory allocation in the first place. This way you can formally prove you can't run out of resources. You also then don't have to worry about errors related to freeing (or failing to free) memory.

Re:

[ArmoredDragon]

If you're already doing embedded work then you're already being very careful about dynamic memory allocation, if you're even doing it at all.

Re:

[phantomfive]

It's always an option and it's always the only option (although most people pretend they have infinite memory), because your program is necessarily limited by the amount of RAM in your computer.

In practice, you should take advantage of the feature in many languages to limit the size of your queue/list/strings/arrays, which will help you find problems sooner rather than later, and it's limited anyway. You don't want to wait until a string is 5 gigabytes long before you notice there is a problem.

Re:

[ArmoredDragon]

Yeah even being able to run out of them is inevitably going to be problematic. I think the reason the rust devs didn't make a Result<T, E> out of every allocation is because modern OSes seem to prefer to just start killing stuff when memory usage is high. If we're talking life and death safety then there's probably a lot more checks that you've already done before your application even starts.

Re:

[NoWayNoShapeNoForm]

Perhaps it will simply wait ("sit & spin") until more resources become available then it will consume those resources and go back to the "sit & spin" state?

Re:

[Jeremi]

Perhaps it will simply wait ("sit & spin") until more resources become available then it will consume those resources and go back to the "sit & spin" state?

In my experience, that behavior is usually worse than crashing. At least after a crash, the crashed process's resources can be reclaimed by the OS, and then a fresh new process can be spawned to replace it, and maybe useful work can resume after that. With a process not performing any of its expected tasks, consuming 100% of a core indefinitely, and the system likely at or near memory exhaustion, OTOH, the system is likely to be non-functional and remain that way until someone comes along to manually powe

Re:

[NoWayNoShapeNoForm]

People are complaining about Rust-based programs crashing. So I was suggesting a possible alternative.

In a Rust-crashing world your car dies in the middle of the interesction with a truck speeding at you. You may or may not have time to jump out.

In a Rust-spinning world your car might slowly move out of the intersection and that speeding truck only whacks off the trunk of your car and spinning you around senseless for a few minutes until it all comes to a stop.

Is there an option 3? I hope so ... for the sak

Hmm

[Bomazi]

There are safety-critical languages with a whole ecosystem behind them, like SPARK. It would take an enormous effort to bring Rust to that point, and for what benefit ? I'd rather see existing tools be improved.