Claude Fable 5 wrote a booting, NT-shaped Rust kernel in 38 minutes

[WhoCares]

AI gives us a broader view


The features described by the author (ownership-based unsafe isolation, IRQL-bound spinlocks, and NonPagedPool-backed standard library collections) only prove that nanokrnl has built an exceptionally elegant and safe low-level scaffolding. However, if the goal is to be compatible with or rival a highly complex macro/hybrid kernel like Windows NT, these mechanisms are just the tip of the iceberg.

The sheer scale and complexity of Windows NT cannot be covered by "memory safety" and "spinlocks" alone. To support an NT-like kernel, one must solve several hardcore architectural challenges that often conflict with Rust's strict ownership model:

1. The Complex IRQL Hierarchy and Synchronization Primitives

While elevating the IRQL to DISPATCH_LEVEL via a SpinLock solves high-priority concurrency safety, this is merely the entry level of NT synchronization.

Lower-level IRQLs: How do you handle hardware interrupts (DIRQL)? How do you elegantly defer tasks by designing a safe queue for DPCs (Deferred Procedure Calls) and APCs (Asynchronous Procedure Calls)?

Higher-level Synchronization: At routine scheduling levels (PASSIVE_LEVEL and APC_LEVEL), NT heavily relies on Mutexes (KMUTEX), Semaphores (KSEMAPHORE), Events (KEVENT), and the highly complex "Wait Block" architecture (KeWaitForSingleObject / KeWaitForMultipleObjects). These thread-blocking synchronization primitives have massive state machines and are far harder to abstract than a simple SpinLock<T>.

2. The Chaotic and Massive I/O Subsystem: IRPs (I/O Request Packets)

This is the most iconic design of Windows NT and arguably the most painful part to rewrite in Rust. NT's I/O is inherently highly asynchronous.

When a read request is initiated, the kernel generates an IRP, which is bounced around like a hot potato across various driver layers (filter drivers, bus drivers, device drivers) via IoCallDriver.

Chaotic Lifecycles: An IRP can be pending, canceled at any time (via Cancellation Routines), time out, or be completed directly by underlying drivers.

Rust's Ownership Dilemma: Who "owns" the IRP? If an IRP is still undergoing underlying hardware DMA transfers but the user-mode thread is suddenly killed, how do you ensure the cancellation logic won't lead to "Use-After-Free" or "Double-Free"? In C, this relies on conventional pointers and reference counting. Modeling a perfect IRP routing framework in Rust using safe lifetimes and the borrow checker is incredibly difficult.

3. The Virtual Memory Manager (VMM) Beyond NonPagedPool

Being able to allocate a few kilobytes of memory from the NonPagedPool using Box/Vec only solves the issue of "kernel-mode local variables/dynamic data." A true NT memory manager must govern the entire virtual address space:

The PagedPool Trap: If your data is in the PagedPool and you touch it while IRQL >= DISPATCH_LEVEL (e.g., while holding a SpinLock), and that memory happens to be paged out to disk (Pagefile), it will instantly trigger a deadlock or a BSOD. Rust's type system struggles to automatically determine at compile time whether a pointer points to Paged or NonPaged memory.

Private Memory and Working Sets: When any executable launches, the kernel must map its PE image, establish private memory segments, maintain page tables (PDE/PTE), and manage physical memory working sets.

MDLs (Memory Descriptor Lists): When handling video streams or large file I/O, the kernel must lock physical memory pages and build an MDL so hardware DMA can access it directly. This involves complex abstractions mapping virtual addresses to physical ones.

4. The Object Manager

Windows NT is highly object-oriented (implemented in C at the kernel level).

Processes, threads, mutexes, files, and even registry keys are all "objects" in the kernel (managed via the Obp internal APIs).

These objects not only have Handles and reference counts (PointerCount) but also involve exceedingly complex Security Descriptors and namespace management. How do you build a unified, safe object lifecycle manager in Rust while maintaining binary compatibility with the NT API?

5. Plug and Play (PnP) & Power Management

PnP and Power Management IRP state machines are a driver developer's nightmare. Devices can be physically yanked out at any moment (Surprise Removal), and the system can enter sleep states anytime (D0 to D3 transitions). The kernel must safely broadcast these state changes across the entire device stack and handle all sorts of bizarre blocking and failure behaviors from various drivers.

Conclusion

As an engineering evaluation, the features showcased by the nanokrnl author represent an outstanding Proof of Concept (PoC). It proves that Rust can eliminate some of the most foolish concurrency and memory out-of-bounds errors at the very bottom of the NT architecture.

However, for a complete NT Kernel, this is absolutely insufficient. Bridging NT's historically complex asynchronous I/O state machines, object manager lifecycles, and highly dynamic PnP architecture in Rust—while maintaining performance and compatibility—cannot be solved by a few clever generic wrappers (like SpinLock<T>). It requires thousands of carefully designed "safety contracts" and a tremendously massive software engineering effort.