You're correct that they're used a decent bit in the defense industry. I can't talk too much about it for obvious reasons, but it's an area where I would expect an uptick in their usage within the next decade in the defense field alone. Check out the DoD's modernization efforts regarding seL4 and L4Re. In-depth knowledge of these microkernels is going to be a skillset in very high demand as defense contractors are forced to adhere to the modernization efforts pushed forth by the DoD.
Tangentially, I'd have loved to see a modern, (se)L4 based desktop (general purpose) operating system, capabilities-based, with services written in a safe language, with no legacy (POSIX) baggage.
Failing that, I hope to be able to hack on something along those lines when I retire :)
(before someone mentiones Fuchsia - Zircon is cool'n'all, but we're talking about L4 here)
This(1)(2) might hold you over for a bit:
"Genode's microkernel architecture, capability-based security, sandboxed device drivers, and virtual machines in a novel operating system for commodity PC hardware and the PinePhone. Sculpt is used as day-to-day OS by the Genode developers. "
> Genode is based on a recursive system structure. Each program runs in a dedicated sandbox and gets granted only those access rights and resources that are needed for its specific purpose. Programs can create and manage sub-sandboxes out of their own resources, thereby forming hierarchies where policies can be applied at each level.
Damn, I've been hoping someone would create something like this for quite some time!
The difficulty is the same as for current sandboxing efforts on desktop Linux though: most existing applications assume unrestricted access to user data. They have to be adapted or have to be granted unrestricted access. Otherwise users will simply not be willing/able to use the machine in secure ways.
The technologies has been there for decades, but is applicable to a greenfield setting only.
> The difficulty is the same as for current sandboxing efforts on desktop Linux though
You're right, that is a problem. However, the situation on Linux is even worse since you can't even nest sandboxes/containers in most real-world situations.
Genode Sculpt releases, in April and October, are where they roll out user interface and other visible upgrades that form a complete system. I'm hoping to make it my daily driver in the near future.
Same. I still check ~yearly https://news.ycombinator.com/item?id=25554912 to see if Robigalia is progressing (sadly it seems the website has casino spam on it now, cmrx64 in case you look for mentions) or someone else has taken up the mantle.
I don’t look for mentions, but how could i miss this thread ;)
The new authoritative link is <https://rbg.systems>; a DNS registration oversight has that spam parked on the old site :(
I still dream about taking that project back up. Maybe there’s some way to find funding for it… otherwise i am currently looking for a job (if anyone reading wants to hire me :)
Check out https://www.dbos.dev/ for a different take on “persistent OS”, i think it’s neat!
90k USD per yr should do it. I don’t have the skills/inclination/bullshit tolerance to deal with any kind of SBIR or VC, tho i did briefly explore the SBIR route with the encouragement of a brave collaborator (we visited DARPA together)
It's not completely "legacy-free", nor is it purely capability-oriented, but I'm writing a QNX-like OS (https://gitlab.com/uxrt/uxrt-toplevel) based on a kernel forked from seL4 with a preference for servers written in safer languages. Even though it is going to be fairly Unix-like it will diverge from conventional Unix in a number of ways and either discard or demote quite a few legacy Unix features. For example, there will be no support for reversion to the traditional Unix security model in the core OS, with the base VFS implementing a security model based on a mix of per-process ACLs and capability transfers, and on top of that there will be a role-based access control model (there will be a fakeroot-type compatibility layer that simulates traditional Unix security within an environment constrained by the native security model). I don't think there's a good way to make a purely capability-oriented general-purpose OS since as soon as you have a way to look up files by human-readable names instead of capabilities your OS is no longer purely capability-oriented.
IMO most of the issues with typical Unix-like OSes are more due to specific outdated architectural features rather than the Unix API or shell environment. A lot of what could be done with a completely new OS could instead be done by designing a Unix-like OS for extensibility by reducing the core API down to a small set of file calls that act as an IPC transport layer and name service and then building everything on top of that, building object-oriented wrapper libraries on top of the filesystem, and reimplementing the traditional Unix APIs outside the core filesystem ones on top of the newer APIs. Existing applications could be ported to such a system incrementally rather than having to do everything all at once or relegate them to some kind of limited "penalty box" compatibility layer (and any binary compatibility layer for Linux or other conventional Unices would integrate better into such a system than into something completely new).
Currently Android is the best we have gotten thus far in that sense.
- Managed userspace
- OS services can be written in Java/Kotlin if desired, and some actually are.
- NDK has a limited set of use cases, mainly for writing native method implementations, 3D rendering and real time audio, and POSIX isn't officially supported beyond to what ISO C and ISO C++ require for their standard libraries implementation.
Naturally OEMs and people that root their devices, push stuff directly with ADB to their phones in developer mode have a different view, but I am writing from the point of view of how the OS behaves in normal devices, by people that don't even know there is such thing as the magic incantation to enable developer mode.
Is this the best we can have, I surely hope not.
I also would like to see something similar, but industry always takes one step forward, two back, in this kind of stuff.
By the way, look into TamaGo, Go based toolchain for bare metal programming firmware.
Safe what? Rust isn't memory safe if you are using unsafe anywhere. There are other "safety" issues with rust as well. Sel4 is in c but it's provably safe (if you're on arm).
This comment demonstrates a lack of understanding of what the unsafe keyword is for in Rust.
Unsafe specifically states that no code within it may introduce UB after the unsafe block exits (post-condition). It also doesn't allow certain operations no matter how hard you try (e.g. the borrow checker still applies, but you can use raw pointers in ways you couldn't outside of an unsafe block, assuming you don't introduce UB).
As someone designing a kernel in Rust, you literally cannot avoid unsafe code, regardless of the language, to implement a kernel.
It's worth mentioning that "unsafe" and "vulnerable" are two different things.
SeL4 is safe because of its extensively verified codebase written in a language suited for verification. Last I checked they port it to C after the fact, but it could just as well be ported to Rust. It'd still be "unsafe" but significantly less "vulnerable".
For example, modifying cr3 or TTBRn_EL1 is incredibly unsafe. But it happens all the time when context switching.
In the kernel I use `unsafe` pretty commonly to denote functions with preconditions not representable by the type system. This enforcement wouldn't even be possible in C or any other language I know of personally that'd be efficient to write an OS in.
The only gripe I have with Rust's unsafe is that I can't mark methods with preconditions as unsafe while still requiring `unsafe` clauses within the function body. I've thought about opening an RFC for `unsafe(pub)` for this reason.
But doing so has made iteration and overall safety of the codebase much easier to reason about because it forces me to think about every call site in which I might introduce a problem if not done carefully.
> This enforcement wouldn't even be possible in C or any other language I know of personally that'd be efficient to write an OS in.
The sky is the limit when it comes to verification of complex properties for C programs. You “just” need a few expert level theorem prover users and a couple of years :)
If you’re actually operating in the kind of domain where exhaustive verification is worth the time investment, C blows Rust out of the water (due to it’s simple semantics and mature ecosystem of verification tooling). There remain no formal semantics of the surface level rust language (and constructing one is a daunting task given its deep and baroque complexity). Verification at the MIR or LLVM levels may be more tractable, but I’m not aware of any large scale results here. C or assembly in combination with some verification tooling remains the gold standard for fast and correct software at the highest level.
Rust offers reasonable memory safety in a relatively accessible and fully automated package. It’s a better choice than C for the majority of cases, but it’s far from the last word when it comes to safety.
btw (and as noted in a sibling comment), sel4 is fully verified down to the assembly level.
> The only gripe I have with Rust's unsafe is that I can't mark methods with preconditions as unsafe while still requiring `unsafe` clauses within the function body.
This is being fixed in the 2024 edition. Or now, with `#[warn(unsafe_op_in_unsafe_fn)]`.
sel4 is implemented 3 times: in c, haskell and isabelle/HOL.
The implementation in isabelle is proven to satisfy various key high level security properties. All 3 implementations are proven to be semantically equivalent. The compiled assembly output from gcc is also proven to be semantically equivalent to the C implementation.
Having these implementation layers is helpful for the proof work since the highest level properties can be proven over a much simpler and highly abstracted implementation (in issabelle / HOL), and the layers make the chain of equivalence proofs down to assembly more tractable. Most of the proof work is done in isabelle with the final C <-> assembly proofs using a custom automated smt based proof engine implemented in python.
The trusted components are the various language semantics / import tools, as well as a few very low level pieces of actual OS code (mostly parts of the early boot sequence iirc).
Section 3 in the whitepaper <https://sel4.systems/About/seL4-whitepaper.pdf> describes how it is done: (1) they restrict themselves to a possible-to-reason subset of C (that they have a parser in Isabelle for), and implement a kernel and prove the implementation is formally correct, and (2) to avoid compiler/kernel bugs of host & trojan horses, they verify the compiled/linked output as well.
Their Figure 3.2 shows how this is done: each transformation into the "Graph Language" nodes is proven formally correct. They need two proofs because the binary is automatically proven correct, i.e. what they prove is that their formalized binary is equivalent to the original binary using a HOL4 disassembler, without knowing what sort of binary they have at their hands. On the C side, they preserve semantics while proving the program correct (manually, i.e. they wrote the proofs themselves), and then they prove the two are equivalent, again automatically, using SMT solvers and throwing small chunks of data at it.
As they explain, proving the two "Graph Language" representations to be equivalent semantically is, in general, undecidable like the halting problem. However, they get away with it because the C compiler is not too wild in its output.
Ferrocene doesn't involve formal proofs. ISO 26262 and IEC 61508 are primarily process-focused standards for project management, quality control, integration, testing, and code review. To the extent there's automated code analysis, it would involve linting for disallowed patterns similar to MISRA C.
The point still stands: rust isn’t memory safe if you use unsafe.
It’s true that to write a kernel safely, you need more than memory safety, but that’s kind if a different point. Folks don’t just use the unsafe construct in Rust to do kernely things.
Yeah I read it. I define memory safe as: Any program accepted by the compiler follows the typing rules of the language.
That holds for Rust if you don’t use unsafe at all. It also holds in other memory safe languages (like JavaScript). Some memory safe languages gaurantee this without any caveats (JavaScript) while others guarantee it with caveats (Rust if you don’t use unsafe, Java if you don’t use certain APIs, etc).
https://kernkonzept.com/ is a company developing the L4Re OS. The company is a spinoff from the TU Dresden Operating Systems group. Afaik their main customer is the automotive industry which uses their hypervisor. L4Re is also certified for all kinds of government secrecy levels, so I would assume they have some users in that area.
They used to be involved in the "chancellor phone", a hypervised system with an open Android OS and a more closed side. It's 10 years ago. I have no idea whether the product still exists and if yes, if it's still done the same way.
Nice! Yeah, that's definitely modern enough. Do you know if it runs as a hypervisor in the Secure Enclave firmware? It seems like the processor itself is low-power enough that it might not have virtualization features.
"Genode's microkernel architecture, capability-based security, sandboxed device drivers, and virtual machines in a novel operating system for commodity PC hardware and the PinePhone. Sculpt is used as day-to-day OS by the Genode developers. "
I know that at one point they did (2012-ish), but do they still? From what I could make of some of the recent reverse engineering research on Qualcomm modems, they seem to suggest that they've been using a homegrown RTOS for awhile now.
You're correct that they're used a decent bit in the defense industry. I can't talk too much about it for obvious reasons, but it's an area where I would expect an uptick in their usage within the next decade in the defense field alone. Check out the DoD's modernization efforts regarding seL4 and L4Re. In-depth knowledge of these microkernels is going to be a skillset in very high demand as defense contractors are forced to adhere to the modernization efforts pushed forth by the DoD.
Tangentially, I'd have loved to see a modern, (se)L4 based desktop (general purpose) operating system, capabilities-based, with services written in a safe language, with no legacy (POSIX) baggage.
Failing that, I hope to be able to hack on something along those lines when I retire :)
(before someone mentiones Fuchsia - Zircon is cool'n'all, but we're talking about L4 here)
This(1)(2) might hold you over for a bit: "Genode's microkernel architecture, capability-based security, sandboxed device drivers, and virtual machines in a novel operating system for commodity PC hardware and the PinePhone. Sculpt is used as day-to-day OS by the Genode developers. "
It looks pretty neat - could be fun to play with!
1) https://genode.org/
2) https://genode.org/download/sculpt
They
> Genode is based on a recursive system structure. Each program runs in a dedicated sandbox and gets granted only those access rights and resources that are needed for its specific purpose. Programs can create and manage sub-sandboxes out of their own resources, thereby forming hierarchies where policies can be applied at each level.
Damn, I've been hoping someone would create something like this for quite some time!
The difficulty is the same as for current sandboxing efforts on desktop Linux though: most existing applications assume unrestricted access to user data. They have to be adapted or have to be granted unrestricted access. Otherwise users will simply not be willing/able to use the machine in secure ways.
The technologies has been there for decades, but is applicable to a greenfield setting only.
> The difficulty is the same as for current sandboxing efforts on desktop Linux though
You're right, that is a problem. However, the situation on Linux is even worse since you can't even nest sandboxes/containers in most real-world situations.
Genode Sculpt releases, in April and October, are where they roll out user interface and other visible upgrades that form a complete system. I'm hoping to make it my daily driver in the near future.
Oh! How is it for a dev. box ?? Can you get gcc/clang/rust/python ? Does it have a decent browser and code editor?
It sounds like fun to play with - I've been wanting to try something new...
They have native 3d acceleration, native modern web browser and virtualization support to e.g. run Linux and any non-ported software on that.
Genode is no joke.
Thanks man - definitely gonna have a go at then :-)
Same. I still check ~yearly https://news.ycombinator.com/item?id=25554912 to see if Robigalia is progressing (sadly it seems the website has casino spam on it now, cmrx64 in case you look for mentions) or someone else has taken up the mantle.
I haven't looked much further but some indication https://d3s.mff.cuni.cz/files/teaching/nswi161/martin-decky-... Huawei is doing interesting work.
I don’t look for mentions, but how could i miss this thread ;)
The new authoritative link is <https://rbg.systems>; a DNS registration oversight has that spam parked on the old site :(
I still dream about taking that project back up. Maybe there’s some way to find funding for it… otherwise i am currently looking for a job (if anyone reading wants to hire me :)
Check out https://www.dbos.dev/ for a different take on “persistent OS”, i think it’s neat!
Out of curiosity what would it cost to hire you to work on rdg project full time?
90k USD per yr should do it. I don’t have the skills/inclination/bullshit tolerance to deal with any kind of SBIR or VC, tho i did briefly explore the SBIR route with the encouragement of a brave collaborator (we visited DARPA together)
It's not completely "legacy-free", nor is it purely capability-oriented, but I'm writing a QNX-like OS (https://gitlab.com/uxrt/uxrt-toplevel) based on a kernel forked from seL4 with a preference for servers written in safer languages. Even though it is going to be fairly Unix-like it will diverge from conventional Unix in a number of ways and either discard or demote quite a few legacy Unix features. For example, there will be no support for reversion to the traditional Unix security model in the core OS, with the base VFS implementing a security model based on a mix of per-process ACLs and capability transfers, and on top of that there will be a role-based access control model (there will be a fakeroot-type compatibility layer that simulates traditional Unix security within an environment constrained by the native security model). I don't think there's a good way to make a purely capability-oriented general-purpose OS since as soon as you have a way to look up files by human-readable names instead of capabilities your OS is no longer purely capability-oriented.
IMO most of the issues with typical Unix-like OSes are more due to specific outdated architectural features rather than the Unix API or shell environment. A lot of what could be done with a completely new OS could instead be done by designing a Unix-like OS for extensibility by reducing the core API down to a small set of file calls that act as an IPC transport layer and name service and then building everything on top of that, building object-oriented wrapper libraries on top of the filesystem, and reimplementing the traditional Unix APIs outside the core filesystem ones on top of the newer APIs. Existing applications could be ported to such a system incrementally rather than having to do everything all at once or relegate them to some kind of limited "penalty box" compatibility layer (and any binary compatibility layer for Linux or other conventional Unices would integrate better into such a system than into something completely new).
Currently Android is the best we have gotten thus far in that sense.
- Managed userspace
- OS services can be written in Java/Kotlin if desired, and some actually are.
- NDK has a limited set of use cases, mainly for writing native method implementations, 3D rendering and real time audio, and POSIX isn't officially supported beyond to what ISO C and ISO C++ require for their standard libraries implementation.
Naturally OEMs and people that root their devices, push stuff directly with ADB to their phones in developer mode have a different view, but I am writing from the point of view of how the OS behaves in normal devices, by people that don't even know there is such thing as the magic incantation to enable developer mode.
Is this the best we can have, I surely hope not.
I also would like to see something similar, but industry always takes one step forward, two back, in this kind of stuff.
By the way, look into TamaGo, Go based toolchain for bare metal programming firmware.
https://www.phoronix.com/news/TamaGo-Bare-Metal-Go-ARM
> with no legacy (POSIX) baggage.
Cool, who's going to write all the new software for your platform?
It worked pretty well for Apple, Google and Microsoft.
Safe what? Rust isn't memory safe if you are using unsafe anywhere. There are other "safety" issues with rust as well. Sel4 is in c but it's provably safe (if you're on arm).
This comment demonstrates a lack of understanding of what the unsafe keyword is for in Rust.
Unsafe specifically states that no code within it may introduce UB after the unsafe block exits (post-condition). It also doesn't allow certain operations no matter how hard you try (e.g. the borrow checker still applies, but you can use raw pointers in ways you couldn't outside of an unsafe block, assuming you don't introduce UB).
As someone designing a kernel in Rust, you literally cannot avoid unsafe code, regardless of the language, to implement a kernel.
It's worth mentioning that "unsafe" and "vulnerable" are two different things.
SeL4 is safe because of its extensively verified codebase written in a language suited for verification. Last I checked they port it to C after the fact, but it could just as well be ported to Rust. It'd still be "unsafe" but significantly less "vulnerable".
For example, modifying cr3 or TTBRn_EL1 is incredibly unsafe. But it happens all the time when context switching.
In the kernel I use `unsafe` pretty commonly to denote functions with preconditions not representable by the type system. This enforcement wouldn't even be possible in C or any other language I know of personally that'd be efficient to write an OS in.
The only gripe I have with Rust's unsafe is that I can't mark methods with preconditions as unsafe while still requiring `unsafe` clauses within the function body. I've thought about opening an RFC for `unsafe(pub)` for this reason.
But doing so has made iteration and overall safety of the codebase much easier to reason about because it forces me to think about every call site in which I might introduce a problem if not done carefully.
> This enforcement wouldn't even be possible in C or any other language I know of personally that'd be efficient to write an OS in.
The sky is the limit when it comes to verification of complex properties for C programs. You “just” need a few expert level theorem prover users and a couple of years :)
If you’re actually operating in the kind of domain where exhaustive verification is worth the time investment, C blows Rust out of the water (due to it’s simple semantics and mature ecosystem of verification tooling). There remain no formal semantics of the surface level rust language (and constructing one is a daunting task given its deep and baroque complexity). Verification at the MIR or LLVM levels may be more tractable, but I’m not aware of any large scale results here. C or assembly in combination with some verification tooling remains the gold standard for fast and correct software at the highest level.
Rust offers reasonable memory safety in a relatively accessible and fully automated package. It’s a better choice than C for the majority of cases, but it’s far from the last word when it comes to safety.
btw (and as noted in a sibling comment), sel4 is fully verified down to the assembly level.
> The only gripe I have with Rust's unsafe is that I can't mark methods with preconditions as unsafe while still requiring `unsafe` clauses within the function body.
This is being fixed in the 2024 edition. Or now, with `#[warn(unsafe_op_in_unsafe_fn)]`.
Music to my ears, thanks!
sel4 is implemented 3 times: in c, haskell and isabelle/HOL.
The implementation in isabelle is proven to satisfy various key high level security properties. All 3 implementations are proven to be semantically equivalent. The compiled assembly output from gcc is also proven to be semantically equivalent to the C implementation.
Having these implementation layers is helpful for the proof work since the highest level properties can be proven over a much simpler and highly abstracted implementation (in issabelle / HOL), and the layers make the chain of equivalence proofs down to assembly more tractable. Most of the proof work is done in isabelle with the final C <-> assembly proofs using a custom automated smt based proof engine implemented in python.
The trusted components are the various language semantics / import tools, as well as a few very low level pieces of actual OS code (mostly parts of the early boot sequence iirc).
Is there a verified SeL4 that supports multi-core yet?
multicore sel4 is implemented but still unverified:
https://docs.sel4.systems/projects/sel4/frequently-asked-que...
I guess https://github.com/seL4/l4v/tree/rt is the ongoing verification work for that
> SeL4 is safe because of its extensively verified codebase written in a language suited for verification
I think this is incorrect. It is written in C, compiled to arm assembly, and the assembly is analyzed and checked by Isabelle/HOL.
You may be right, I was under the impression that the Haskell version was the verified version.
Section 3 in the whitepaper <https://sel4.systems/About/seL4-whitepaper.pdf> describes how it is done: (1) they restrict themselves to a possible-to-reason subset of C (that they have a parser in Isabelle for), and implement a kernel and prove the implementation is formally correct, and (2) to avoid compiler/kernel bugs of host & trojan horses, they verify the compiled/linked output as well.
Their Figure 3.2 shows how this is done: each transformation into the "Graph Language" nodes is proven formally correct. They need two proofs because the binary is automatically proven correct, i.e. what they prove is that their formalized binary is equivalent to the original binary using a HOL4 disassembler, without knowing what sort of binary they have at their hands. On the C side, they preserve semantics while proving the program correct (manually, i.e. they wrote the proofs themselves), and then they prove the two are equivalent, again automatically, using SMT solvers and throwing small chunks of data at it.
As they explain, proving the two "Graph Language" representations to be equivalent semantically is, in general, undecidable like the halting problem. However, they get away with it because the C compiler is not too wild in its output.
> but it could just as well be ported to Rust
Without formal semantics for the complete rust language the result couldn't be verified. Rust's complexity makes it hard to define formal semantics.
I wouldn't normally bring this up as a disadvantage of rust, but people aren't normally talking about software that has been formally verified.
Check out ferrocene.
Ferrocene doesn't involve formal proofs. ISO 26262 and IEC 61508 are primarily process-focused standards for project management, quality control, integration, testing, and code review. To the extent there's automated code analysis, it would involve linting for disallowed patterns similar to MISRA C.
The point still stands: rust isn’t memory safe if you use unsafe.
It’s true that to write a kernel safely, you need more than memory safety, but that’s kind if a different point. Folks don’t just use the unsafe construct in Rust to do kernely things.
> rust isn’t memory safe if you use unsafe.
Did you read my comment at all? How do you define "memory safe"?
Yeah I read it. I define memory safe as: Any program accepted by the compiler follows the typing rules of the language.
That holds for Rust if you don’t use unsafe at all. It also holds in other memory safe languages (like JavaScript). Some memory safe languages gaurantee this without any caveats (JavaScript) while others guarantee it with caveats (Rust if you don’t use unsafe, Java if you don’t use certain APIs, etc).
I didn't neccessarily mean Rust, but was curios to see how that would look.
Here's a Rust demo implementation of the seL4 root task (the first process that gets started on boot) using their Rust SDK and it doesn't look like it's using unsafe anywhere: https://github.com/seL4/rust-root-task-demo/blob/main/crates...
(I don't speak Rust so I might have missed it).
Go might be another interesting choice.
(let's not turn this thread into Rust vs Go vs whatever agaaaaaain ... we've got enough of those please).
https://kernkonzept.com/ is a company developing the L4Re OS. The company is a spinoff from the TU Dresden Operating Systems group. Afaik their main customer is the automotive industry which uses their hypervisor. L4Re is also certified for all kinds of government secrecy levels, so I would assume they have some users in that area.
Two products for one-way data transfer, based on L4Re:
- https://www.genua.eu/it-security-solutions/data-diode-cyber-... - https://www.genua.eu/it-security-solutions/data-diode-vs-dio...
Disclaimer: I work for genua, the maker of these products.
They used to be involved in the "chancellor phone", a hypervised system with an open Android OS and a more closed side. It's 10 years ago. I have no idea whether the product still exists and if yes, if it's still done the same way.
I believe Apple uses it in at least one of the auxiliary service processors in their current portfolio under the moniker "Darbat" or "L4/xnu"
https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...
https://microkerneldude.org/2016/04/14/so-the-fbi-cracked-th...
Darbat was their project mainly to run macOS on L4. AFAIK this was canceled, and no work has happened since around 2006.
The newer L4 stuff (like Apple's Secure Enclave) is based on L4Ka::Pistachio, but with proprietary changes made by Apple. [1]
[1] https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-De...
You could check out Helios, which is inspired by L4 [0]
[0] https://ares-os.org/docs/helios/
seL4 foundation member list[0] might give you some hints.
0. https://sel4.systems/Foundation/Membership/
Apple’s Secure Enclave Processor?
Citation: https://support.apple.com/en-gb/guide/security/sec59b0b31ff/... "The Secure Enclave Processor runs an Apple-customised version of the L4 microkernel."
From the rumor mill morgue, back in 2006 there was some speculation about macOS, err, Mac OS X transitioning to L4: https://arstechnica.com/staff/2006/06/4407/
They hired a ton of UNSW graduates who had worked on L4 around that time.
Was at UNSW recently, can confirm that apple doing special L4 stuff right now.
Nice! Yeah, that's definitely modern enough. Do you know if it runs as a hypervisor in the Secure Enclave firmware? It seems like the processor itself is low-power enough that it might not have virtualization features.
I am pretty sure there is no hypervisor. I am pretty sure the processor supports EL2 but it doesn't get used for anything to my knowledge.
This(1)(2) any good for ya?
"Genode's microkernel architecture, capability-based security, sandboxed device drivers, and virtual machines in a novel operating system for commodity PC hardware and the PinePhone. Sculpt is used as day-to-day OS by the Genode developers. "
1) https://genode.org/
2) https://genode.org/download/sculpt
I believe the Qualcomm modems run a L4 variant.
I know that at one point they did (2012-ish), but do they still? From what I could make of some of the recent reverse engineering research on Qualcomm modems, they seem to suggest that they've been using a homegrown RTOS for awhile now.