Case study · kernel boots
Grey OS
I have read a great deal of kernel code and written none of it. Reading gives you the shape of a system; writing gives you the failure modes. Grey OS is a 64-bit kernel built from the firmware up, so that the abstractions I lean on every day stop being a diagram.
- Language
- Rust, no_std
- Target
- x86_64, UEFI
- Runs on
- QEMU
- Works today
- Boots, paints framebuffer
- Works next
- Page tables, heap, interrupts
- Status
- Unfinished, publicly
01
The premise
A kernel that boots on x86_64 under UEFI, in Rust, without the standard library. no_std is not a purity exercise — it is the removal of the allocator, the panic handler and the operating system underneath, all three of which are the things usually doing the work for you.
Small and documented unsafe. Every unsafe block is a claim about aliasing or validity that the compiler cannot check, and a claim with no comment is a bug with a delay fuse.
02
Where it is
It boots under UEFI in QEMU and paints the framebuffer. That sentence carries a lot: a loader, a GDT, a stack you did not get for free, and a memory map handed over by firmware that has to be trusted and then verified.
Nothing about it is finished. The open checklist lives in the repository and staying public with it is the point. A kernel project that only advertises the parts that work is a portfolio piece, not an engineering one.
03
Why it is hard
Memory, paging and interrupts share one failure mode: the triple fault. The machine resets, the debugger shows nothing, and the evidence burns with the fire. Debugging stops being print statements and becomes bisection — disable the last thing you added and see whether the reset still happens.
That is the real return on the project. On Android you work in a userspace being remarkably polite about the kernel underneath it. A few weeks of fighting a page table makes that politeness visible, and makes the cost of each abstraction visible with it.
04
Constraints I chose
- Rust, no_std
- No allocator until I write one, and none borrowed from a crate that quietly assumes an operating system exists.
- x86_64 under UEFI
- Firmware does the first half, so the project starts where the interesting part starts: with a memory map it did not construct.
- QEMU before hardware
- A reset in an emulator costs two seconds and leaves a trace. The same reset on hardware costs an evening. Hardware comes once the emulator is boring.
05
Next
Page tables, then a heap, then interrupts on a timer. After that the first thing anyone could reasonably call an operating system: a scheduler with two things to schedule.
A triple fault is the most honest error message in computing. It tells you that something you believed was wrong. It does not tell you which thing.