From my understanding that means that now Rust can be used for the development of security critical software in automotive.
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?
As the article says:
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...
Aerospace would be DO-178, which is on the roadmap, but will take some effort (a year or two, give or take).
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.
Isn't AdaCore handling the DO-178 side? Or does Ferrocene intend to have an offering here, also?
The joint venture with AdaCore is no longer, so yes, we're doing this seperately.
Please beat them to market... Their notion of advertising "curated language features" as a positive instead of "weird frankencompiler that doesn't match any version, work with any 3rd party crates, and has complete vendor-lock" will sell well to people that already use them, unless they aren't an option.
I didn't think they made any language extensions for rust? Thought it was just for Ada.
Ada does not have any formalized FFI with Rust at this time; just C, COBOL, and Fortran:
http://ada-auth.org/standards/22rm/html/RM-B.html
AdaCore has a Rust toolchain:
I know, thank you, but I'm asking about the "curated" language features gp is criticizing. AdaCore does make Ada language extensions (who else would push the language forward these days?), but I didn't think they had any for rust, which is why I'm asking.
GNAT Pro for Rust offers yearly updates that incorporate selected, recent enhancements from the upstream development. We make sure the result is a stable, tested Rust toolchain that’s ready to be used and supported for years to come.
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.
> That is in effect forking the language.
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.
Ferrous created a language specification.https://github.com/ferrocene/specification
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.
They have explicitly stated that a Rust language specification is a non-goal for Ferrocene:
https://news.ycombinator.com/threads?id=thesuperbigfrog&next...
There's an ongoing discussion about potential adoption into upstream, though.
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.
Doesn't Rust have a Reference manual already? A "spec" just wouldn't be very meaningful given the lack of independent implementations. But to the extent that the reference manual doesn't suffice for documenting the language, that's a defect which could and should be fixed.
The manual isn't directly consumable by formal processes. The compiler design doesn't have to be influenced by a specification, but it does have to be described by one.
The direct competition between Ferrocene and AdaCore should take care of that.
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.
I can imagine no use case where ripping out features from upstream reduces risk vs adding it. I agree it makes no sense to stagnate, but I am familiar with the certified compiler space, and what I have described is exactly what I have witnessed. Compilers that are based on ancient versions of open source compilers, and have code incorporated from various point releases since then to minimize the amount of recertification necessary.
What happens when a new feature holds up the certification process for some reason? There are only two possible options, and they both suck:
1. Stay on the last certified version until everything is certified.
2. Incorporate the parts that can be certified.
The ferrous option appears to be 3. upstream changes that make certification of the new feature easier and then proceed.
If that's still an option, then they haven't reached the point yet where they have to choose.
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.
> AdaCore does make Ada language extensions (who else would push the language forward these days?), but I didn't think they had any for rust, which is why I'm asking.
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.
The medical certifications are mostly about design & risk control, there isn't really (currently) the same set of toolchain certs you see in e.g. aerospace. Some places do use them as a shorthand for "our documentation & testing here is minimal, because we use X certified tools and/or standards" but it isn't required for CFR21 or 13485.
Keeping an eye on this in the aero, uh, space. Very interesting progress, keep up the good work.
SIL is used in my industry (Industrial manufacturing and Refining). It covers more than software though. Mostly system integration - for example things like interlocks and whether a valve will fail open/closed etc.
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.
While it is great that Rust is now also an option, some of those places still stuck in C89 and C++98, are hardly to going upgrade to anything else.
Some times not even the tooling is an excuse, as most chip vendors do at least support C11 and C++14 in most cases.
Disclaimer: I'm one of the founders of Ferrous Systems
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 :).
I see human behavior a more problematic issue to overcome than the toolchains, hence why I mentioned the toolings being more modern than what many are willing to adopt.
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.
To be frank, this seems to be a general comment on rust as a language itself, than ferrocene.
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.
Yes and?
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.
I see human behavior a more problematic issue to overcome than the toolchains, hence why I mentioned the toolings being more modern than what many are willing to adopt.
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.
We need an industry-wide break with the old thing. There have been enough problems caused by crappy unmaintainable spaghetti code full of UB. Now, a new thing (Rust) doesn't mean you'll get better code in every way, but at least in some ways.
Rust can be used for the development of security critical software in automotive.
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.
Oh yes, you are right, in my mother tongue safety and security are the same word. It is still embarrassing, I should have been more careful.
Wait -- I find this fascinating.
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.
Hmm in German you could also say "Betriebssicherheit" (safety) vs. "Angriffssicherheit" (security), or at least that always was the translation that made most sense to me personally.
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.
But they are both "Sicherheit" since in compound words the main word is the last word. You could say "Ist dein Haus sicher?" and mean "is your house secure" if a burglar is targeting your neighbourhood or "is your house safe" if a storm is passing over it. You can distinguish both cases with context or compound words, but it's not generally done.
As native German speaker I would like to second that. It's a very good description.
It's not embarrassing at all! I wouldn't have realised had the person not pointed it out. At least you've learnt something interesting.
From my understanding that means that now Rust can be used for the development of security critical software in automotive.
It has always beenpossibleto 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 theyseemedfine, so, maybe that's enough reason to require tests for my chemical but not parsnips ? Or at least, lets notrequirethe tests before continuing to eat parsnips.
"It has always been possible to do whatever you wanted [..]"
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.
In automotive safety critical systems ISO 26262 is a legally well established, necessary (but not necessarily sufficient) prerequisite for that.
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)
Very true. I'm coming from the supplier side and in the world I know the required ASIL level is a box we have to tick, no realistic way around it. That includes using a certified compiler. Probably that is not universally true but in my bubble for all intents and purposes a certified compiler was a hard requirement. This is in no way a contradiction to what you wrote but underlines why I think a Rust compiler that is not in the way for me ticking the ASIL D box is a big thing.
For somebody not familiar with compilers, rust or ASIL...
What's the difference between the regular rust compiler and Ferrocene that makes it adequate for critical systems?
In a word: documentation and testing. They're not making major modifications to upstream, but they are crossing the Ts and dotting the Is to satisfy the that their compiler meets all the safety requirements set forth in those standards.
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!
I mean, I was thinking more like:
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.
Disclaimer: I'm one of the founders of Ferrous Systems.
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.
Is there a list with supported targets? Do you focus on ARM or are there other targets common in automotive, for example Power Architecture like the NXP MPC series?
Depends on what you mean with „supported“ - the qualification is at the moment for ARMv8-A bare metal (aarch64), seehttps://public-docs.ferrocene.dev/main/qualification/report/..., mostly because that‘s what our initial customer intends to use.
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.
Aaaaaah OK. So it's a bit more like a certified distribution. Sounds similar to how we handled FDA/CE certified versions of Open Source software.
Thanks for the clarification, it's very useful!
What's the merits that allow the certification? Is it technical? Is it bureaucracy and "just" certifications?
What’s thetechnicaldifference 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) soa prioriI wouldn’t expect much technical difference (other than perhaps the Ferrocene fork lagging behind a bit).
Well, I didn't want to dismiss or minimize the importance of bureaucracy and certification, as I myself have been involved in FDA and CE certification.
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.
You are correct, the technical differences are negligible for most intents and purposes.
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...
Certification is super important in many industries like automotive.
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.
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. "Always" covers alotof ground.
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?
Disclaimer: I'm one of the founders of Ferrous Systems
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 spechttps://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.
You weren't joking about the height of the stack of paper in another comment.
No, not at all.
Thanks for explaining that.
I've met some people from ferrous before (during one of their rust courses) and I have to say I was quite impressed with their work.
They went through the qualification without a fork of the compiler. The changes they made are upstream, and all open source.
Any example PR? I am curious about what they look like.
Here is one I know of:https://github.com/rust-lang/rust/pull/90346
Ibelievethis is one as well:https://github.com/rust-lang/rust/pull/113535
The second one was for a demo at an ESA symposium about rust in space, so it‘s not directly related to the certification.
Ah ha! Thanks :)
I mean, it’s definitely indirectly related to the entire certification thingy. After all, we do want to see rust code in space. That what kicked off that whole idea :)
I forgot to add the relevant blog post where Jonathan writes about that changehttps://ferrous-systems.com/blog/rust-for-mission-critical-a...
We wrote a blog post about it which lists some of the things we upstreamedhttps://ferrous-systems.com/blog/how-ferrocene-improves-rust...
Sorry to hijack the comment.
I want to train a few engineers but not enough numbers to justify a team training.
Could you request/discuss internally to update ferrous systems 'scheduled trainings'? I unfortunately only see dates in the past.
Also for budget purposes it would be good to plan dates a bit further into the future. Like setup a 18 month calendar or something similar.
Great work on ISO26262 cert congrats all.
We really don't plan that far out in the future regarding open trainings. So the best option for you is probably to get in touch with us via the website and we're happy to ping you when we schedule new dates.
Ok fair enough, I will reach out via the website. Thank you again.
That's a vert smart move actually: the value their customers are paying for is the certification/paperwork, so upstreaming doesn't cost them anything and it reduces their costs a lot since they don't have yo maintain their fork, which can be an extremely costly endeavor in the long run.
I was expecting it to be locked to quite an old rust, just because of how difficult/slow it is to get this kind of accreditation, but it's 1.68 which is not bad at all (latest stable is 1.73)
Can any of the Ferrocene folks here can talk about what the release cadence for officially qualified Rust toolchains might be?
A lot of the timeline depends on the partner we're working with to achieve qualification. Initial qualification definitely takes longer, but we're having discussions on how we can cut down on the manual part of the certification. We do for example pull in all releases of the compiler, including nightly, and build them using our CI and test sytems. The versions that pass are made available to our customers, so they can follow the release cycle - though these are obviously not qualified and nightly comes with the usual nightly (lack of) stability guarantees.
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 :)
Side question:
Is your pricing in line with the norms in this sector? It seems really cheap to me.
From past experience, other companies in this space typically charge 1-2 orders of magnitude more per seat.
Their products are also usually worse than the free/OSS options that don't come with certification paperwork.
They're a new entry into the space and with something as "groundbreaking" as Rust their idea is probably to push for better/cheaper up until there is enough seats that they can start charging more once people have invested enough to not want(or be able) to change toolchains.
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).
until there is enough seats that they can start charging more once people have invested enough to not want(or be able) to change toolchains
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.
Thank you, we appreciate the compliment :)
I’m happy to outline our general reasoning of how we arrived at the pricing, though I’ll obviously not go into specifics.
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.
It's certainly an unusual pricing style, but people grok it and appreciate it. Also, note that this is for the "quality managed" version - additional support and documents that I sign off for safety (so enter a liability) are more expensive.
But on the other side, there's so many that would buy if it were more accessible.
According to (second-hand) experience with auditors with respect to open source, they were quite open to considering things like CI, good commit messages etc. are useful when evaluating the development process, and even considered them sufficient (with adequate explanation) towards some of the ISO26262 requirements. However, that was for ASIL B only.
That matches our experience. They were super pragmatic. Also, their feedback was tough, but always technically grounded and from the perspective of "is the user always well informed?".
Will you guys provide certified libraries as well? Like an async executor, http client, bluetooth, etc? That would be something even companies outside the target for certification would probably be interested in.
We're being asked about these regularly, but e.g. bluetooth certification is still too prohibitive to just do without a customer.
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.
On this topic (certified libraries) I suspect an interesting evolution might happen: by observing how you guys at Ferrous achieved this milestone while keeping a consistent openness, other actors (companies, consultancies and academic institutions) start seriously thinking about the possibility of contributing with high quality and certified libraries for a lot of scenarios. In other words I’d look at this as a milestone that opens to new and disrupting ideas
Yes, and this does indeed happen. Turns out publishing such a thing makes people get in touch.
What impact does certification have on the safety of the resulting systems?
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 biggest practical impact is probably from having the CI tests running on the certified platforms that were not already tier one for rust.
(disclaimer: also a co-founder of Ferrous Systems)
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.
Aside from having gone through the certification, what are the differences between Ferrocene and upstream rustc?
"Measured in literally tens of lines"
https://news.ycombinator.com/item?id=37771664
for more:https://ferrous-systems.com/blog/qualifying-rust-without-for...
It seems like it would be cool to have a "rustup" variant that used this so it was a smooth setup to get a certified tool chain.
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.
We're working on that! Expect more news around it in the coming months.
If someone from Ferrous sees this, I'd advise putting the price in English punctuation when writing the article in English. It's a needless stumbling block having the comma and period in the wrong place.
He, thanks! Weird how that happened though, as the post _was_ edited by an English speaking person living in Germany :).
This is very exciting, the interop with C really opens the ability to fold this into an existing OS and drivers. Any existing examples of operating system integration, for example working with SafeRTOS [0].
Yes, we built bindings for LynxOS 178 a while ago and demonstrated Rust on QNX at embedded world.
https://www.lynx.com/press-releases/rust-compiler-supporthttps://ferrous-systems.com/blog/how-we-built-our-embedded-w...
Porting Rust to RTOSes is reasonably easy.
“Rust was designed specifically to handle concurrent and parallel programming”
This is a milestone and a landmark achievement. And the reasons for this are not limited to the availability of a qualified and vendor supported toolchain for the use of Rust in Functional Safety concerned embedded designs. The goal has been reached while maintaining openness and shared results, which is an industry first.
I'm very excited about this. Having a vendor supported toolchain means I might be able to bring Rust into where I work. Embedded companies are very conservative and risk adverse. Have a commercial package with LTS and certifications addresses some of the concerns.
Woo-hoo!
As someone that doesn't know anything about safety certifications of software, what do theyactuallydo to make rust certifiable ?
Like what are the requirements and how to they make rust follow them ?
Unimpressed because ofhttps://en.wikipedia.org/wiki/Technischer_%C3%9Cberwachungsv...
Congrats! Ferrocene has been building towards this accomplishment for a while. I definitely appreciate the amount of hard work that went into this. (And as a fellow Rust user, all the improvements and changes that get merged upstream.)
Huge! Congrats to the team.
If I ever see Rust code running in a car, I’m never going to buy it.
This is big news in my opinion.
"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.