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

[WhoCares]

Claude Fable 5 wrote a booting, NT-shaped Rust kernel in 38 minutes, with later work on Claude Opus growing it to run real Windows binaries.

Security startup Tolmo published a transcript-level account of Claude Fable 5 writing a booting, NT-shaped kernel in Rust from an empty directory in 38 minutes of active model work.

By the company's account it built the trusted computing base, booted in an emulator, passed its own self-tests, and root-caused its own low-level bugs, then over 8 more days, mostly on Claude Opus 4.8, grew to load unmodified Windows drivers and run real Windows binaries.

https://github.com/msuiche/nanokrnl

An NT-compatible kernel written in Rust: the architecture, abstractions, and (where it matters) the exact constants and layouts of the Windows NT kernel, rebuilt as a modern, memory-safe, freestanding Rust codebase. It boots on x86-64, runs real, unmodified Microsoft user binaries (cmd.exe, more.com, …) on its own NT syscalls, loads a genuine null.sys PE driver, and proves itself with a self-test suite on every boot.

It runs natively under QEMU and in your browser, via nanox, a bespoke ~60 KB x86-64 WebAssembly emulator that boots the unmodified kernel image directly in long mode, with no threads, no SharedArrayBuffer, and no COOP/COEP headers.

https://nanokrnl.ai

[chants]

Very cool. In terms of safety, I do see 53 .rs files with "unsafe": https://github.com/search?q=repo%3Am...pe=code&l=Rust

So it seems safety guarantees are still not assured - there should be some sort of formal proof/verification metadata extension for Rust that allows unsafe regions to be proven safe. Otherwise I consider these to be "cheating"

[Ibrahim_Mihai]

Originally Posted by chants

Very cool. In terms of safety, I do see 53 .rs files with "unsafe": https://github.com/search?q=repo%3Am...pe=code&l=Rust

So it seems safety guarantees are still not assured - there should be some sort of formal proof/verification metadata extension for Rust that allows unsafe regions to be proven safe. Otherwise I consider these to be "cheating"

Cheating? Look who's talking!

Well, there is still the same "unsafe code" issue with the vibe-coded decompilers you posted last week:
https://forum.exetools.com/showthread.php?t=21666
This is always a problem with vibe-coded content.

OTOH, at least the nanokrnl above is a excellent proof-of-concept of something that was only a pipe dream for many years.
If you've actually read the whole article carefully, you can see that it was meant only as a PoC and not for production use anyway!

A nano Windows kernel booting through a hand-built emulator in the browser, on its own NT syscalls, is quite an achievement.

Kudos to the creators of the nanokrnl projext!

[chants]

So this isnt the correct location to discuss this, prefer on the thread itself but it was hand written only the Ghidra protocol update, IDA SDK support update and some GUI bug fixes were "vibe coded" but also with harnesses to do automated headless IDA testing and such. Testing across Angr gives some solid proof and stability. Care was taken. Managing the details between two very different tool interfaces is a pretty massive undertaking especially when both are moving targets. Feel free to criticize the work. Though it can be more productive to make your own contributions.

[Ibrahim_Mihai]

You are criticizing a ground-breaking project by posting a generic Github search URL based on a string search for "unsafe code" in the repo. And you are talking about appropriateness, LOL.
There is not even any qualified discussion of the resultant search results.
It would have been more appropriate had you spent a few minutes explaining the findings or more importantly, suggesting solutions to avoid the unsafe code.
Rather, you just make it look like a hurried jealous criticism of an awesome project.

Did you try the same generic search on your own repo?
https://github.com/GregoryMorse/GhidraDec

You have included a lot of proprietary IDA SDK code in your repo which is of course illegal.
I don't know if this is an oversight or a blatant disregard for the IP rights of Hexrays.

At least the nanokrnl project does not have any illegally obtained code in their repo!

[chants]

The search was for "unsafe" on .rs files which is a legitimate analysis surface and point of safety concern and something interesting to discuss. Merely an observation - and I literally suggested a solution but you will clearly need to re-read my post.

Look you are ruining this thread which was on topic previously and going way off topic. Just delete your posts - move the criticism to the appropriate thread and this might be a worthwhile discussion.

There is legitimately *zero* IDA SDK material in the repository, just typical API bindings. Do you know how to read and understand code? You've not pointed out a single line. Looks like you are engaging in harassment for the pure sake of harassment. If there is an issue with "vibe coding" or what you claim to be proprietary source which there are not, then simple cite it. Citing a whole repo is just trolling.

[atom0s]

Originally Posted by Ibrahim_Mihai

You have included a lot of proprietary IDA SDK code in your repo which is of course illegal.
I don't know if this is an oversight or a blatant disregard for the IP rights of Hexrays.

IDA's SDK is open source and licensed under MIT. What are you talking about lol..?

https://github.com/HexRaysSA/ida-sdk

[Ibrahim_Mihai]

Originally Posted by atom0s

IDA's SDK is open source and licensed under MIT. What are you talking about lol..?

https://github.com/HexRaysSA/ida-sdk

Seems that it is free from the (very recent) IDA 9.2 update: https://hex-rays.com/blog/open-sourcing-ida-sdk
Thanks for bringing this up.

@chants I am not trying to harass. All I am saying is that the nanokrnl project is a ground-breaking achievement and is a very good start.
It is good to focus on the positive rather than on the negative.
That, and the project has just started. I'm sure they are working on making it more secure.

[chants]

@atomos you are absolutely right and from IDA 9.2 onward its no longer "bring your own SDK" and it is auto downloaded in the build scripts. I was thinking to put SDKs as encrypted zips that could be CI integrated with secrets in the repo but after thorough review of the license agreement, that was ruled out as a viable route. And in fact the small amount of research notes which are removed anyway are a moot point with the public SDK release. The repo has always been deliberately maintained with minimal risk and total compliance with any rights holders IP.

Why am I reminded of an octopus? When many limbs are chopped off, over a few months they regenerate anew.

[WhoCares]

The author puts some notes there:

Modern & safe by construction. unsafe is concentrated at the hardware boundary and in the intrusive data structures, each block with an explicit safety contract. SpinLock<T> owns its data and raises IRQL by construction, so the classic "touched shared state below DISPATCH_LEVEL" driver bug doesn't compile. Box/Vec/String work in-kernel and draw from NonPagedPool with the 'Rust' tag.

Originally Posted by chants

Very cool. In terms of safety, I do see 53 .rs files with "unsafe": https://github.com/search?q=repo%3Am...pe=code&l=Rust

So it seems safety guarantees are still not assured - there should be some sort of formal proof/verification metadata extension for Rust that allows unsafe regions to be proven safe. Otherwise I consider these to be "cheating"

[Ibrahim_Mihai]

Originally Posted by WhoCares

The author puts some notes there:

Modern & safe by construction. unsafe is concentrated at the hardware boundary and in the intrusive data structures, each block with an explicit safety contract. SpinLock<T> owns its data and raises IRQL by construction, so the classic "touched shared state below DISPATCH_LEVEL" driver bug doesn't compile. Box/Vec/String work in-kernel and draw from NonPagedPool with the 'Rust' tag.

Thanks @WhoCares for pointing this out.
Yes, this is exactly one of the main reasons why I was trying to point out to @chants that he is unnecessarily trying to point out the not-so-relevant-in-practice code as "unsafe" through a cursory and arbitrary keyword search for "unsafe code".

The nanokrnl project is definitely a ground-breaking project for those who understand the implications.

I would not have minded if chants provided some actionable code instead of just this statement:

there should be some sort of formal proof/verification metadata extension for Rust that allows unsafe regions to be proven safe. Otherwise I consider these to be "cheating"

Peace

[chants]

The README clarification is useful, and I am happy to refine my original comment accordingly.

Calling the use of "unsafe" itself “cheating” was too broad. A freestanding kernel necessarily has operations at hardware, ABI, allocator, paging, interrupt, and raw-pointer boundaries that Rust’s type system cannot prove safe. Rust’s own terminology is that an "unsafe" block discharges a proof obligation which the compiler cannot check; it does not mean that the code is automatically defective.

That said, counting and locating "unsafe" was not an “arbitrary” or irrelevant search. It identifies the portions of a supposedly memory-safe kernel that belong to its trusted computing base and therefore merit closer review. The repository itself makes exactly this distinction: it says that "unsafe" is concentrated at the hardware boundary and in intrusive data structures, with explicit safety contracts. That is a substantive and reassuring answer to the concern—not evidence that asking about the concern was illegitimate.

The technically appropriate next questions would be whether those contracts are complete, whether the safe abstractions actually preserve them, and whether tools such as Miri, sanitizers, model checking, fuzzing, or formal verification can cover some of the remaining obligations. Boot tests and emulator differential testing provide valuable evidence, but they are not general proofs of memory soundness.

So, to be precise: nanokrnl is an impressive proof of concept, and its use of localized, documented "unsafe" is normal for kernel development. It is also correct that Rust cannot by itself guarantee the soundness of those regions. Both statements can be true simultaneously.

What is not productive is repeatedly substituting speculation about my motives, unrelated accusations about another repository, or demands that a forum observation arrive with a completed patch. Your accusation about proprietary SDK code was already shown to be false. I have now clarified my wording and the technical issue. Unless you have identified a specific error in the analysis or a specific unsound block in the code, there is nothing further to argue about. Please let the thread return to the project itself.

[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.

[chants]

This is a fair and much more complete engineering assessment.

The current work demonstrates that Rust can provide strong safety boundaries for important low-level mechanisms, but it does not imply that the broader NT architecture has been solved. IRP cancellation and completion races, wait objects, paging constraints, DMA, object lifetimes, PnP, power management, and compatibility with existing drivers all require far more elaborate protocols and state machines.

Rust can encode some of those rules more explicitly through types, ownership, reference counting, pinned objects, capability-style APIs, and restricted state transitions. For example, paged and nonpaged allocations or operations permitted at particular IRQLs could potentially be represented by distinct types. But Rust cannot automatically prove the correctness of the full asynchronous protocol, external driver behaviour, hardware interaction, or every cancellation race.

So I agree with the distinction: nanokrnl is an impressive proof of concept and its current abstractions are valuable foundations, but they should not be interpreted as evidence that a complete, compatible, and safe NT kernel follows easily. The real research and engineering question is how much of NT’s historically informal discipline can be converted into enforceable abstractions while keeping the remaining "unsafe" core small, explicit, and auditable.