We looked at this as the basis for CHERIoT RTOS (we were at Microsoft, it was owned by Microsoft) and decided not to because retrofitting security to it was harder than writing something from scratch. It’s absolutely terrifying code. Everything pokes at the internal data structures of everything else. It was also full of memory safety bugs (I think MSRC found 20 in the first day of their audit. Want to bet they missed some?). After looking at the code, I was shocked that MS had paid money for it. I sincerely hope that whoever approved that decision had to spend some quality time on their Connect in the ‘what could you have done better’ section, but I suspect that they were promoted.
I strongly suspect that MS is giving this away because no one internally wants it. It’s probably fine for traditional embedded things, where all inputs are trusted, but for IoT devices it’s going to come with a massive cost for regularly rolling out security updates.
I strongly suspect that MS is giving this away because no one internally wants it.
One would hope not. Such a strategy is short sighted at best. My personal experience suggests that the name association to both Microsoft and Azure is likely to have a long half-life.
:-( Too bad they have this image now. I really liked Eclipse (the IDE) but I never saw much value in all these other projects they have (and I was doing full time Java for a very long time). Except for jetty, I think I never used anything from eclipse.
The author of the Dependency rejection story said this in its comments (highlighting relevant part and hope I’m not misconstruing).
.. programmers spend a lot of time not coding on their core problem and instead researching/adopting/integrating external tools/dependencies. Since that is what the article is about: sealing oneself off to focus creatively on your core problem, using the playful term “dependency rejection…
I think CHERIoT RTOS decision making as you explained really highlights the type of dependencies this pragmatically applies to.
edit: If it wasn’t clear, sounds like a good decision to build from scratch rather than “retrofitting”.
I watched Kunyan Liu’s presentation about CHERIoT at the RISC-V Summit. Fascinating stuff! Finding a bunch of memory bugs on day 1 would definitely be anathema to CHERIoT’s goals, eh?
Kunyan did an amazing job implementing our ISA in Ibex.
It would have been annoying to have those bugs. Most of them wouldn’t have appeared on day 1 though, they only appear when the system is under attack, and so we’d have had dynamic failures, not static ones.
Oh yes by “finding on day one” I was referring to MSRC finding 20 bugs on the first day of their audit but good point, in real-world usage you don’t find that stuff painlessly on day 1, you find it much later, much more painfully…
Yup, the difference for us is that bugs like these would have been deterministic traps, not things that easily led to arbitrary code execution, and the blast radius would have been confined to a specific compartment. That’s predicated on actually being able to compartmentalise things, which you can’t if, for example, the network stack expects to directly manipulate the scheduler’s internal data structures (concrete example from ThreadX). This prevents the network stack from being a separate failure domain. In contrast, we can run the network stack with a narrow interface to the ethernet driver and a narrow interface for the TLS compartment to use and ensure that a compromise of the network stack can’t do very much.
We looked at this as the basis for CHERIoT RTOS (we were at Microsoft, it was owned by Microsoft) and decided not to because retrofitting security to it was harder than writing something from scratch. It’s absolutely terrifying code. Everything pokes at the internal data structures of everything else. It was also full of memory safety bugs (I think MSRC found 20 in the first day of their audit. Want to bet they missed some?). After looking at the code, I was shocked that MS had paid money for it. I sincerely hope that whoever approved that decision had to spend some quality time on their Connect in the ‘what could you have done better’ section, but I suspect that they were promoted.
I strongly suspect that MS is giving this away because no one internally wants it. It’s probably fine for traditional embedded things, where all inputs are trusted, but for IoT devices it’s going to come with a massive cost for regularly rolling out security updates.
One would hope not. Such a strategy is short sighted at best. My personal experience suggests that the name association to both Microsoft and Azure is likely to have a long half-life.
Eclipse Foundation is where projects go to die.
Hey now, you forgot the ASF.
:-( Too bad they have this image now. I really liked Eclipse (the IDE) but I never saw much value in all these other projects they have (and I was doing full time Java for a very long time). Except for jetty, I think I never used anything from eclipse.
The author of the Dependency rejection story said this in its comments (highlighting relevant part and hope I’m not misconstruing).
I think CHERIoT RTOS decision making as you explained really highlights the type of dependencies this pragmatically applies to.
edit: If it wasn’t clear, sounds like a good decision to build from scratch rather than “retrofitting”.
I watched Kunyan Liu’s presentation about CHERIoT at the RISC-V Summit. Fascinating stuff! Finding a bunch of memory bugs on day 1 would definitely be anathema to CHERIoT’s goals, eh?
Kunyan did an amazing job implementing our ISA in Ibex.
It would have been annoying to have those bugs. Most of them wouldn’t have appeared on day 1 though, they only appear when the system is under attack, and so we’d have had dynamic failures, not static ones.
Oh yes by “finding on day one” I was referring to MSRC finding 20 bugs on the first day of their audit but good point, in real-world usage you don’t find that stuff painlessly on day 1, you find it much later, much more painfully…
Yup, the difference for us is that bugs like these would have been deterministic traps, not things that easily led to arbitrary code execution, and the blast radius would have been confined to a specific compartment. That’s predicated on actually being able to compartmentalise things, which you can’t if, for example, the network stack expects to directly manipulate the scheduler’s internal data structures (concrete example from ThreadX). This prevents the network stack from being a separate failure domain. In contrast, we can run the network stack with a narrow interface to the ethernet driver and a narrow interface for the TLS compartment to use and ensure that a compromise of the network stack can’t do very much.