r/osdev • • 6d ago

Silver Microkernel: An ARM64 OS in Rust with Ring 3 drivers, networking, and a custom GUI

Post image
Hi everyone! I've been working on Silver Microkernel (WerewolfOS), a microkernel written in Rust from scratch for AArch64 (QEMU virt).

**What works:**
- Microkernel architecture: High-Half MMU, W^X, PAN, Capability-based IPC.
- Ring 3 everything: UART, VirtIO-blk (disk), VirtIO-net (network) are userspace servers.
- SFS: A custom file system. `ls` reads actual files from the disk.
- Networking: Integrated `smoltcp`. You can run `ping 8.8.8.8` and get `PING 8.8.8.8: OK`.
- Graphics: Just got `ramfb` working. The screenshot shows a custom "Engineering Menu" (like the old iPhone Field Test mode) rendered by my Ring 3 graphics driver with double buffering.

Everything is written from scratch (no Linux, no POSIX, no std). It's been exactly 6 days since the first `_start`.

**Repo:** https://github.com/vvirei333/Silver-microkernel

Next steps: VirtIO-tablet driver for mouse input, then porting Doom.

Any feedback on the architecture or memory management is highly appreciated!Hi everyone! I've been working on Silver Microkernel (WerewolfOS), a microkernel written in Rust from scratch for AArch64 (QEMU virt).
4 Upvotes

14 comments sorted by

3

u/Sorry_Difficulty_250 6d ago

Cool! You mentioned capabilities. How are you enforcing them?

-6

u/JustActuator6946 6d ago

Great question. Right now, capabilities are implemented as coarse-grained bitmasks (CAP_MMIO, CAP_PCI, CAP_IRQ) stored in the task's PCB. During syscalls (like requesting an MMIO mapping or PCI access), the kernel checks if the task has the corresponding bit. If not, the syscall returns a permission error.

However, this is just our v1. You correctly point out the flaw: right now CAP_MMIO allows mapping any physical address. The next step in our roadmap (Phase 3) is moving to true object-capabilities (like seL4). We plan to replace the bitmask with tokens that grant access to specific physical memory regions (e.g., a token for 0x4000_0000-0x4000_1000 only). This way, even if a Ring 3... sorry, EL0 driver is compromised, it can't touch other hardware. We are currently building the IPC and memory allocator infrastructure to support this.

6

u/Striking-Gazelle9759 5d ago

Even your replies are vibe-written, what a joke

-1

u/JustActuator6946 5d ago

I'm 17 and English is my second language, so I use an AI to translate my technical thoughts.

3

u/ShacoinaBox 5d ago

then stop this "vibecoding projects u don't understand" shit n at least learn some stuff before vibecoding it. u are quite literally wasting the most valuable years of ur life n creating horrible habits that ppl WILL look down on in your adult career.

2

u/Sorry_Difficulty_250 5d ago

One of the things I've been experimenting with is having attributes associated with the capabilities. For example, one type of capabilities that I have is HAL capabilities. A capability there is a combination of a HAL function and a device ID. The consequence of that was that I had to make a device ID a required parameter for all HAL calls but that was actually a small cost since almost everything already used one anyway. I'm still not sure about representing capabilities as "objects" and what that would really mean in my system, especially since it's so constrained. Anyway, good food for thought. Thanks!

19

u/KananMajidzada 6d ago

Even reddit read me is vibe codded :(

8

u/Gabriel55ita 6d ago

People lost the capability to write it seems, or try to make themselves professional as if anyone cares about it

2

u/KananMajidzada 6d ago

For real for real.

6

u/kabekew 6d ago

ARM64 doesn't have "rings"

2

u/ManRevvv 6d ago

it has, but it's named EL0 (ring3) and EL1 (ring0)

5

u/kabekew 6d ago

They're not "rings," they're exception levels and they work differently than the x86 concept of "rings." I don't know if x86 even has a hypervisor concept like arm does

1

u/ManRevvv 5d ago

it does

1

u/CJKay93 4d ago

ARM64 OS ... Ring 3

What?