"We’ve qualified Ferrocene for use in systems up to ASIL D"

Where D is the highest existing level used for systems that can potentially cause fatal injuries.

From my understanding that means that now Rust can be used for the development of security critical software in automotive.

I used to work in automotive and where I worked software development was dominated by ancient and archaic compilers and toolchains. Even if it wasn't for the advantages that Rust brings to the table the possibility to use a modern toolchain would be revolutionary. At the same time this is the biggest risk for adoption because these legacy systems are deeply ingrained and intertwined with existing processes that often span multiple tiers of suppliers and will be hard to change.

It has always been possible to do whatever you wanted in this respect, Ferrocene means that you don't have to go to more trouble than a competitor who does their software development in a similarly qualified C++ software suite.

Rather than pay some number of people to explain why it's OK that you didn't do the boring normal thing, you can pay Ferrocene for their paperwork which says actually Rust is just one of the boring normal things.

Is "Boring normal thing" good enough? Well, on its own I'd argue it's not even close, but pragmatism rules the day, people writing firmware which is in pretty old cars were knocking it together in C with no rules, and most people didn't die, so, that's our baseline, that was apparently OK, logically a bit of that won't be a disaster... right?

It reminds me of GRAS rules. On the one hand, there's no particular reason to just assume parsnips are OK food while this random thing my chemists just invented is not - after all parsnips may be "natural" but so are all nightshades and some of them are straight up poison (and indeed the rest of Apiaceae, the family parsnips are in, are sometimes poisonous) - however on the other hand a lot of people have eaten parsnips already and they seemed fine, so, maybe that's enough reason to require tests for my chemical but not parsnips ? Or at least, lets not require the tests before continuing to eat parsnips.

That is not quite what I meant. You can always do what you want if you are prepared to accept the consequences.

German law requires the manufacturer of a technical product to take all measures objectively necessary and reasonable in order to avoid danger and harm. In automotive safety critical systems ISO26262 is a legally well established, necessary (but not necessarily sufficient) prerequisite for that.

Car manufacturers spend a ton of money on certified compilers and toolchains for good reasons. One of them is legal compliance.

"From my understanding that means that now Rust can be used for the development of security critical software in automotive."

What I meant here is that I'm not sure if what exists today (including Ferrocene's certified toolchain) is enough to make Rust happen in safety critical automotive applications. I simply do not know enough to make that claim.

That is true, but an ISO 26262 qualified toolchain is neither sufficient nor required to achieve certification. It certainly helps when the auditor looks at your project, but you can also opt for other measures. So you could build ISO 26262 certified software in rust even before the Ferrocene qualification, and you still can build it using stock rustc, but it's more work. Few people will do that and rather opt for a qualified toolchain.

> What I meant here is that I'm not sure if what exists today (including Ferrocene's certified toolchain) is enough to make Rust happen in safety critical automotive applications.

It's one of the foundational pieces, but others are qualified libraries and the entire ecosystem. So the adoption will by necessity still take time. We do have a few exciting things in the pipeline there, but that's news for another day (it's christmas soon, not all presents at once)

Perhaps you are native of a latin language?

In the context of ISO26262, ASIL levels relate to the criticality of _safety_ not security.

My house's security will determine how easily someone can break in.

My house's safety will determine how well it will survive a hurricane.

They are also kind-of the same word(s) in German (Sicherheit / Sicherung).

Do native German speakers draw much distinction between Sicherheit and Sicherung, and to the same degree that we do in English?

If no, I am curious how the differentiation in concepts developed in English developed and whether it is also present in other Germanic languages.

I'd say native speakers of German distinguish it but it depends on the context ... talking about computers, it's typically more about security, while when talking about construction sites, it's typically more about safety.

Some times not even the tooling is an excuse, as most chip vendors do at least support C11 and C++14 in most cases.

To some extend I agree, but from our conversations with OEMs, Tier 1 and Tier 2 suppliers we do see a significant interest in moving to rust, much more than moving to a new C/C++ version.

The reasoning is that moving to a new C/C++ version is an incremental change, but moving to rust signifies a jump to a different tech level (let's set aside whether that's true on a technical level or not, I'm talking about perception). One of the signifiers is that we were able to qualify the rust language as it exists, with no such restrictions such as Misra C etc. So no "reduce use of pointers" etc.

The other things that's helping is regulatory pressure. The CISA, DARPA etc are all advocating strongly in favor of moving to memory safe languages, and for the chunk of the market that used C/C++ before, rust is a pretty good offering there: It binds to C both ways, that means not only can you call C code from rust, but also the other way round - you can build a component in rust and integrate it in your existing firmware. That's a rare capability.

Chipset and ecosystem support are IMO the biggest hurdles at the moment, but with Ferrocene as a qualified compiler, at least that one bar is removed. It's still a long way to go and a lot of work ahead of us :).

Looking forward to regulatory pressure to help improving the situation, not only regarding the adoption of modern safer languages, but also to "just" adopt modern practices and tools while coding in C and C++.

Already changing the mentality from unsafe at any speed, to quality matters, would be a big improvement.

A plus from safer languages that aren't copy-paste compatible with C, is that C style programming is already taken out, so we don't need to spend time creating SonarQube rules and forcing them into teams.

Good luck with the Ferrocene effort.

I absolutely agree. I agree that this is what's holding back adoption of new tooling the most. However, the impression that I get from our conversations is that a new C/C++ is seen as "more of the old thing" while rust is considered a break with the old thing, something new with substantial risk, but also substantial upsides. This perception helps when it comes to considering an adoption.

One would instead start from an observation that rust has been filling a real need/gap in the market which can't be explained merely by human behavior alone, and looks like it's been quite successful at doing that.

That is a challenge, that Ferrocene alongside plenty of other companies, including those that tried to push C++ as a safer C, have to deal with.

There have been safer languages on that domain, like Ada, which for various reasons did not take off as expected, and it wasn't only due to compiler prices.

Dealing with human psicology from folks that aren't even willing to update themselves beyond the toolchains used 30 years ago even though more recent ones are available, it is a challenge, moreso when the newcomers need a full rewrite, instead of updating the compiler version.

I am on the Ferrocene side, just like I enjoy the surviving 7 Ada vendors are still around, PTC, Aicas and microEJ keep selling their Real Time Java, or that Astrobe its Oberon compiler, MIKROE their mikroBasic and mikroPascal compilers.

The more that challege the status quo, the better.

What about other safety critical domains such as aerospace, medical, railways, machinery, process control etc? It seems like each of these has its own bespoke standards, so Ferrous will need to seek certification for these separately?

> Beyond the automotive, Ferrocene can also be used in electronic programmable systems in the industrial sector. Here the focus is on developing products or applications that carry out safety functions. Like the automotive certification, we’ve also gone for the highest level of risk reduction and qualified it at SIL4.

Apparently [1] the SIL standard is used in at least the process control, nuclear, mechanical, and railway industries. Not sure about medical or aerospace.

[1] https://en.wikipedia.org/wiki/Safety_integrity_level#Standar...

Medical is closer: While there are dedicated certifications for medical, they are relatively close to the IEC 61508 industrial standards and so IEC certifications are often used as a stand-in for the equivalent medical certification.

http://ada-auth.org/standards/22rm/html/RM-B.html

AdaCore has a Rust toolchain:

https://www.adacore.com/gnatpro-rust

https://www.adacore.com/gnatpro-rust

Edit: not so worried about the extensions, more worried they will keep re-releasing 1.68 forever with features added only as people clamor for them. And security fixes wedged into old code. That is in effect forking the language.

In any case, the compiler wouldn't be certified if they didn't vet the new features. These companies can't control what gets added to the language, and it might take longer than a year to vet future changes.

Their statement is an upfront, no-bull fyi about how reality works. I highly doubt it's a statement of intent to stagnate. It would kind of defeat the purpose of switching away from a stagnated language and ecosystem.

1. Stay on the last certified version until everything is certified.

2. Incorporate the parts that can be certified.

They're promising yearly updates. I'm asking what happens when a new upstream feature has already gone uncertified for one full year. Either they blow past the deadline and release nothing for over a year, or they ship what's currently available.

There's no third option. Ferrous doesn't have a time machine, and AdaCore is just explicitly saying that they'll give you what they have at least once a year.

It feels like the effectiveness and success of Rust could make that happen.

Different industries have different needs and will want the language to meet their needs.

Rust needs more funding, labor, and organization to create an official language standard to prevent it from fragmenting.

They do say any differences between it and upstream behavior or documentation is a defect in the spec, not upstream. So it isn't authoritative. Unless we all decide it is.

https://news.ycombinator.com/threads?id=thesuperbigfrog&next...

The thing here is: it would be harmful if we, Ferrous Systems, claimed or even be confused with a more general Rust spec. That's a) the privilege of the Rust project and b) problematic if consumers were to understand it that way.

Correct, AdaCore / GNAT has extensions that are not part of the Ada standard:

https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/g...

I don't have a close relationship with AdaCore and do not know what they are planning for their Rust toolchain.

That said, I would be surprised if they do not add features to ensure Rust plays nicely with their other products and give their Rust toolchain competitive advantages in the safety critical space. I do not see any documentation or details on their website yet, but it also looks like their Rust toolchain is not released yet.

In one instance we wanted to use a FLIR camera to measure temperature as part of a control loop - had to provide guarantees about the cameras reliability (i.e. mean time between failure), have redundancy and fallbacks in place etc. In order to satisfy the SIL process.

I obviously can't make any promises here, but we aim to pick two of those rust versions per year and then certify them - how long that takes depends on the feedback we get from the auditor and on their availability. The exact cadence will need a little shakedown - no one has experience in qualifying rust compilers continously :)

Is your pricing in line with the norms in this sector? It seems really cheap to me.

But on the other side, there's so many that would buy if it were more accessible.

Their products are also usually worse than the free/OSS options that don't come with certification paperwork.

At that point they not only have locked in customers, they also have them as references for other customers to justify why new customers should pay more (Existing customers will probably be the ones paying least for the longest).

First of all, our competition is the open source rust compiler. Current Ferrocene is a downstream of rust 1.68 and a drop in replacement, so you can develop your project using the open source rust compiler and at the point where certification is required switch. You obviously won’t get support, but the safety manuals and all the certification documentation is open source. The compiler source is also open source, so you can build from our source.

So our offering is essentially the quality management and handling of all the minutiae required to use a compiler in a corporate environment, including LTS support when required, signed installers, management of known issues, certifications, etc.

We could ask for prices an order of magnitude higher if we kept all the documentation closed, but that would mean our customer base is the people that require certification now. We’d rather have a reasonable price point and charge for the work we save the user - which puts a reasonable upper bound on the per seat price. Also, that ship has sailed - as I said, all accompanying documentation is open, which also keeps us honest.

I can understand how one could have that impression about generic suppliers in the field. However from everything I know about the people at Ferrous Systems, I'd be incredibly surprised if that's a strategy they are pursuing.

That said, I don't code for such environments so I don't know if they prefer to piece their tools together or if there are other reasons to not bother.

They went through the qualification without a fork of the compiler. The changes they made are upstream, and all open source.

I believe this is one as well: https://github.com/rust-lang/rust/pull/113535

What's the difference between the regular rust compiler and Ferrocene that makes it adequate for critical systems?

As far as why use their compiler vs upstream? It's similar to why you might use a managed database vs deploying your own in a $5 droplet; in a big corporate environment, you have no trouble paying for things that would be hard to do yourself, and satisfying regulators is one of those things.

All at a very reasonable price point, too!

What's the merits that allow the certification? Is it technical? Is it bureaucracy and "just" certifications?

I've been on the healthcare business so I've seen how that works when doing FDA or CE certifications.

Ferrocene as a compiler is not inherently more suitable for safety critical applications than stock rustc as distributed by the rust project. It is for all intents and purposes the rust projects compiler, with all the certification paperwork - that's quite a stack of paper if you include all of it, but it doesn't change any of the functionality.

However, on a support/organizational level, there are quite a few differences. We run our own CI for all of our supported targets which allows us to provide different QA levels than the rust project does or even could support.

We do provide higher levels of assurance on some targets compared to upstream. For example, the aarch64-unknown-none target is treated as "tier 2" by the Rust project, meaning they don't run any tests for it. Instead, Ferrocene treats it as fully supported, and we ensure all tests pass on it when we merge any change (contributing back fixes when something breaks).

We can also provide support for targets that are not in the rust projects tree, or even require legal paperwork for access to test hardware etc., to the point that we can provide binary only targets that cannot be made available via the rust project.

On a support level, we also provide support for existing rust version, to the point of long term support for certified versions (2 years by default, more or less infinite with a separate support contract).

There's also minor things that are interesting to organizations: Notification of known issues, signed installers, ...

All of these things do not change the compilers behavior, but can be quite essential for organizations with long term, safety critical projects.

Thanks for the clarification, it's very useful!

We have other targets on the roadmap and can implement/qualify targets on request, so if you‘re interested in a specific target, we‘d be happy to talk.

What’s the technical difference between bureaucracy and technical merit in this context? Two compilers with equal source: (1) is rubber-stamped (audited or whatever by humans) while (2) is not.

This is based on rustc(1) so a priori I wouldn’t expect much technical difference (other than perhaps the Ferrocene fork lagging behind a bit).

However, the certification covers not only the source that was used to build, but rather the entire process to produce the binary for the source, that is our (Ferrous Systems) organization, our processes, the review process to ensure that requirements match the tests, the CI, the quality management, how we handle new issues (for example reporting to customers) … So even if you’d build the Ferrocene compiler from the available Ferrocene source, this would not give you a qualified compiler - because it’s not been built by our standards.

So to a large extend, the qualification does not produce better software, it „just“ documents that a certain quality baseline is fulfilled. But, as part of the qualification process we test the qualified targets to a higher standard than the rust project itself - the aarch64-unknown-none target is a tier 2 target for the rust project, it’s built as part of the compiler release but not tested. It‘s our qualification target so for us it’s tier 1. And indeed, we did discover issues as part of the certification effort, so ticking the boxes to fulfill that baseline did indeed improve the rust compiler. We wrote a little about the things that came out of the certification process in an earlier blog post: https://ferrous-systems.com/blog/how-ferrocene-improves-rust...

Thing is, not familiar with rust and that certification, I didn't know how much "based on rustc" means. So I didn't know of the certification was more like "legal process and support" or something like "formal verification" or the like.

Your customers will do audits and send people to cover their own asses and stay in legal complience. Now a venturing software developer (or teamlead) can go to their bosses and ask them to use this new fangled rust technology for a small test project.

It can be sold as a chance to innovate without compromising on customer requirements/safety. After all it's offically certified to some standard and the responsible manager can check that off their list.

It sounds like it's more a "cover your ass" kind of thing. Is there any part of the certification that involves behavior of the tool?

> I was really hoping that certification involved some kind of testing to insure that the compiler always produces correct code, though I'm not sure that's even possible.

This is not what certification does or even aims to achieve. To boil it down in very few (grossly simplifying) words, certification provides a process framework that ensures that defects found are handled and adressed. No compiler is perfect and none will ever be, but the goal is to document the behavior of the compiler (which we did by boiling down all of the RFCs into the ferrocene language spec https://spec.ferrocene.dev/index.html), ensure that all of these requirements have associated tests and document that association and then document where the compiler misbehaves, as well as ways to detect and avoid that misbehavior.

If misbehavior is found in a future rust version, our task is to identify which of the certified version(s) are affected and notify our customers on how to handle the issue. Handling the issue does not always require a patch to fix it, it can also be handled by providing a suitable tool to detect it (a lint, binary checker, ...) and associated documentation on how to adress it in the customers code.

> Is there any part of the certification that involves behavior of the tool?

The spec, plus the associated safety manual.

0 - https://www.highintegritysystems.com/safertos/

https://www.lynx.com/press-releases/rust-compiler-support https://ferrous-systems.com/blog/how-we-built-our-embedded-w...

Porting Rust to RTOSes is reasonably easy.

Is this one of those standards which involve a lot of questionnaires and box-ticking, but has negligible effect on the bug-free-ness of the resulting software?

The ISO 26262 is certainly an effective standard. The boxes to tick are of the kind "do you have your requirements written down?" ("will someone later know what this thing does?").

So, we do have to tick boxes, but we're free to pick on how to tick boxes :). What TÜV now certified is that our box-ticking process is fine.

I have absolutely no problem with framing this as box-ticking in some way, but that box-ticking has _meaning_. However, on an existing tool, that means you write the spec (spec.ferrocene.dev) and check if everything has a test implemented. Yep, that's an amount of pretty dumb and repetitive work. And pretty often, on widely-used software, for the happy path, you'll find that it's rather bug-free. So, yes, you tick the box, but you now know that this is in order.

In other cases and on less popular platforms, we frequently find issues like e.g. changes in code size between versions (which could hint to a bug). And it's not just super-niche targets, the last version had a size regression on certain arm targets.

Details on some of the fixes over the last years can be found here: https://ferrous-systems.com/blog/how-ferrocene-improves-rust.... We find a lot of things in corners and better ways to improve the Rust compiler.

As we're a downstream to Rust, we're actually incentivised to push changes upstream with preference, so yes, we contribute to the general quality of the Rust compiler (also of older versions) and with that to bug-free-ness of the resulting software.

So, we're over here, ticking boxes, informing parties when one box doesn't tick.

However, I'm also frustrated with "everything is customer funded", so we're looking at ways to make this things happen.

Sorry to be vague.

Like what are the requirements and how to they make rust follow them ?

https://news.ycombinator.com/item?id=37771664

for more: https://ferrous-systems.com/blog/qualifying-rust-without-for...