- Hubris for deep embedded
- Redox OS for Desktop/Server (https://www.redox-os.org/)
- Tock for embedded (https://www.tockos.org/)
- Xous for trusted devices (https://xobs.io/announcing-xous-the-betrusted-operating-syst...)
I assume there are more.
It has a similar set of usage idioms to Hubris it looks like in terms of trying to setup as much as possible ahead of time to assemble what's kind of an application specific operating system where everything your use case needs is assembled at build-time as a bunch of communicating tasks running on seL4.
We recently added a concise little persistence interface that pulls in TicKV (https://docs.tockos.org/tickv/index.html) from the Tock project you referenced above, and some provisions are being added for some more dynamic task handling based on some asks from an automotive OEM.
Also, sincerest h/t to the Tock folks.
I defiantly think all the embedded Rust and even others will end up sharing lots of code.
I would like to spend some time working Datomic style on a more powerful immutable DB that could run on different KV interfaces. Lots of configuration should more immutable.
So how does a car manufacturer uses Rust and eventually be compliant with AUTOSAR/MISRA certification?
It would be interesting to know if there is some movement in that front.
Do you know where I could find more info? Have I just been looking in the wrong places?
MISRA and AUTOSAR are both consortiums in the automotive ecosystem. They're both industry standards bodies, not regulatory standards bodies (more like Khronos than ISO). The former worries mostly about defining best practices for convention and code style for primarily C and C++. The latter worries about defining a spec and interfaces for a middleware and application framework that's supposed to help automakers have a common portable (between MCUs) mechanism for developing, aggregating, and deploying ECU software. What's been merged from AUTOSAR to MISRA is basically AUTOSAR's codification of C++ subset and best practices into MISRA's version of C++ subset and best practices.
In the automotive world, the certification standard that ultimately matters is ISO 26262. It would be possible to write MISRA compliant code that still didn't qualify under ISO 26262 because of the process by which that code was developed. Likewise, it would be possible to have an AUTOSAR spec implementation that didn't qualify under ISO 26262 for similar reasons. It's also entirely possible to deploy software in cars that is neither MISRA compliant nor running on AUTOSAR. This is because ISO 26262 is 99% about process requirements and only about 1% technology prescription. Additionally, ISO 26262 is a self-certification regime almost everywhere in the world. It's a liability mitigation for when things eventually go wrong, not necessarily a direct regulatory hurdle that must be cleared. Lastly, ISO 26262 provides for the ability to offer evidence in support of deviations taken from the latest version of the standard's prescriptions and/or technology callouts.
Alright, now with all that out of the way...
With respect to seL4 and FerrOS. AUTOSAR Classic is for MCUs. seL4 and thus also FerrOS are not. They're for application processors. That said, it would be trivial to write FerrOS applications that could communicate over the protocols that are commonly defined for AUTOSAR Classic, so that you could have a FerrOS-built ECU interacting with the rest of your AUTOSAR-built ECUs. It would be likewise fairly trivial to create a basic HAL, carve out a slab of resources, and host an AUTOSAR Classic environment on one or more FerrOS tasks. It would just be kind of an odd thing to do given what kinds of things AUTOSAR Classic is used for and not entirely clear what the ultimate value would be. What I could imagine some day would be someone wanting to create an Adaptive AUTOSAR (a different AUTOSAR standard that's for higher-level applications and compute resources like ADAS and IVI) implementation atop something like seL4 via FerrOS (especially in the future when FerrOS supports bundling "applications" that aren't written in Rust).
As that relates to Rust in cars generally. That's a matter of risk tolerance and evidence investment. Rust has no ISO qualified toolchain, though Ferrous Systems has organized a project around a premise of getting Rust's development process, or some curated subset of it, to the point of producing the documentation and evidence of being so qualified. However, until that time it's incumbent on the user of the non-qualified toolchain to provide its certification evidence for the tools and technologies used. So, I expect for the companies who are dabbling in Rust, this is likely what they're planning on doing.
In one side of the fence you have Azure IoT Edge, done in a mix of .NET and Rust.
https://msrc-blog.microsoft.com/2019/09/30/building-the-azur...
On the other side you have the Azure Sphere OS with a marketing story about secure IoT, yet the SDK is C only,
https://docs.microsoft.com/en-us/azure-sphere/app-developmen...
To the point they did a blog post trying to defend their use of C,
https://techcommunity.microsoft.com/t5/internet-of-things-bl...
I do a lot of Rust work, but C still occupies a prominent place in my toolkit.
In fact, this is fairly standard among all of the professionals I know. The idea that companies need to abandon C and only do Rust as soon as possible is more of an idealistic idea on internet communities.
Additionally they could also allow for all GCC languages like Ada and C++, given it is the SDK toolchain, instead of being C only, if the security marketing from Azure Sphere is to be taken seriously.
It's only "schizophrenic" to the degree that you expect an organization of thousands of individuals to behave like a single human mind.
Given your description apparently on US Gov anyone can get away with not following them, no wonder an US company acts accordingly.
This is pretty famously not limited to Microsoft's views on Rust. Probably at any sufficiently large company, though Microsoft is the tech company that gets most discussed about. At a previous employer, there was a division that was gung ho on Go and React, while another was Java and Ember.
Microsoft Security advises 1. managed languages, 2. Rust, 3. C++ with Core Guidelines.
Then comes out this group selling "secure IoT" devices with a C only SDK.
What is interesting about this OS except it is made with Rust? I mean some interesting architecture , new exiting features that are not in Windows/Unix world?
My question is if Redox OS is more similar to other hobby Oses we see here or is something more well thought like Plan9, Fuschia, Singularity ? Is there a link where someone that is not a Rust fanoboy (but maybe an OS fanboy) reviewed/described it in more detail?
Instead of everything being a file, everything is a scheme (basically a URL).
https://doc.redox-os.org/book/ch04-10-everything-is-a-url.ht...
There are some filesystem-like usage patterns built on top of that which are universal, but they're more limited.
Even if it is completely unrelated, it is 'at least' production ready and will be used more than these projects would ever be used in terms of Rust projects.
Are there even any cryptocurrencies that allowed less-safe languages like C in the first place?
In my opinion (as a Rust dev), Rust is weirdly over complicated for what they’re trying to do. Common types scripting languages are basically more than sufficient (and safe)for these applications.
It’s only a matter of time before a crypto project overplays the safety of Rust and them has a huge heist due to a logic bug, which will further contribute to jokes about Rust programmers. Most of the Rust devs I know are wary of Rust crypto projects.
Given the context assuming smart contracts you may have a point. Often consensus will be much slower and a limiting factor in execution. Solana may be a bit different here in their efforts to parallelise independent transactions.
High level provable languages always seemed like a good idea to me for smart contracts. As you say Rust doesn't necessarily seem like the sweetspot for this.
The Ethereum EVM assmebly is wildly unsafe but regularly used for the sake of gas and other things that would be impossible (most hilariously string manipulation). Solidity is unsafe with respect to things like overflow. It doesn't have memory unsafety in the traditional sense. Partly because it is allocate only and you don't have to deal with bounds checking yourself.
There is an implication here that Rust will help make smart contracts "secure", but AFAIK the vulnerabilities in smart contracts have been in their logic, not in their memory/type safety or whathaveyou.