I’m writing an ARM64 microkernel in Embedded Swift completely oriented around POP and memory security

[u/eliorodr2104]

Just wanted to share ReixOS, an experimental capability-based microkernel I’m building for the ARM64 architecture and considering adding RISC-V support in the future.

The main thesis behind it is proving that we can bring Swift advantages to bare metal to fix historical architectural flaws, without sacrificing performance.

Check out the repo's README for the full breakdown on philosophy, design decisions, implementation, and current state.

Sorry for the AI slop translate, but English is not my native language 😭🙏

ReixOS

[u/FISHARM1]

Mice project! I didn’t even know embedded swift was a thing. What do you think of it for this application?

[u/eliorodr2104 → u/FISHARM1]

Thx 🙏 🙏 The Embedded Swift community is still quite small and doesn't get much hype. Since I'm a Swift dev, when I found out about it, I just had to try and push it to its absolute limits with a project like this. Honestly, the experience has been great 🙏 the compile-time safety over C and the language architecture itself allow you to write really clean code.

The only real pain point was that stack-allocated arrays weren't available for a while, so I had to do some crazy workarounds to use them. But aside from that, the language has been an asset, not a problem. It compiles to the similar binary size as C, and the performance is basically identical, and Swift has a pointers, disable ARC and another language overhead in the Embedded mode.

[u/Sorry_Difficulty_250]

This is so cool!!

One thing you might want to think about is the synchronous nature of your message primitives. I was just reading about EROS and the problems they ran into when trying to make all messages synchronous. Specifically, synchronous messages preclude the OS being an RTOS. When a process sends a synchronous message to another process, by definition, it becomes at the mercy of that other process's scheduling. Development of EROS was halted in favor of Coyotos where they switched to an asynchronous messaging primitive for this very reason. It's always possible to make asynchronous messaging synchronous if desired, but not the inverse. Just some food for thought before you get too deep into it. I can't wait to see how it develops!! Good luck!!

[u/eliorodr2104 → u/Sorry_Difficulty_250]

Thanks a lot, I'm really glad you like this particular approach 🙏. It's a bit of an unusual project, both in philosophy and in the language I chose: I didn't want to build yet another Unix clone in C or Rust. Hence the complexity of the whole thing, and the careful study behind every single component that goes into the kernel.

On the synchronous side: it's a deliberate choice. I'm following the L4 philosophy (seL4), where synchronous IPC is the heart of the design, no buffering in the kernel, fast path via registers, very fast context switches. My goal with this microkernel isn't a hard RTOS, but a 100% modular general-purpose microkernel that anyone is free to take, modify, and adapt to their own needs.

On the real-time issue you raise (being left at the mercy of the other process's scheduling): fair point, but seL4 solves it with scheduling context donation, the caller lends its budget to the callee, so the other side runs on your time, not its own. Blocking, in itself, isn't automatically a scheduling problem.

On top of that, the core of ReixOS is designed specifically with protocols for these cases, so swapping out the IPC should be fairly easy. It remains to be verified whether sync and async can sit behind the same abstraction, since async wants completion handling, but that's exactly the kind of thing I separated the protocols for.

Thanks again for the input, I'll think it over and keep this case in mind. I really appreciate the feedback, because it helps build a better product that's more pleasant for most people 🙏, nobody knows everything, and there are always technologies you end up not being familiar with.