Microsoft's kernel previews put Rust's safety boundary into existing systems

Introducing Rust into an existing kernel requires deciding where the language's guarantees begin. New code must interact with memory and interfaces created outside its own ownership model. Microsoft's October 25 Surface security post reports Rust integration in Azure and Windows kernel Insider previews. It also describes work on open platforms for Rust firmware and driver development.

The report points to July's Windows Insider build 25905. That announcement identifies win32kbase_rs.sys as a new implementation of GDI regions in safe Rust, calls it a small trial, and describes a gradual Canary rollout. This establishes preview integration, rather than a claim that Windows has been rewritten or that the implementation is generally available.

I am impressed by Rust's semantics and find it compelling for work that might otherwise be written in C. This report matters to that judgment because it concerns a component within an existing operating system. The interesting question is how an implementation can use safe Rust while respecting the contracts of the code surrounding it.

References carry stronger assumptions than addresses

The Rust book shipped with Rust 1.73 explains that a reference is more than an address. It must point to a valid value for the lifetime of the reference. The compiler uses ownership and borrowing to reject code that could leave a reference pointing to data that has already gone away.

That changes ordinary implementation work. A function borrowing a value does not take ownership of it, and returning from the function does not destroy the borrowed value. The caller's ownership and the borrow's lifetime provide a relationship the compiler can check. A raw address alone does not encode the same relationship.

The distinction becomes important at any existing-system boundary. Memory may arrive through an interface whose producer is not subject to Rust's rules. Before safe Rust treats that memory as a reference, some code needs to establish the reference's validity obligations. Simply giving an address a Rust type cannot make its allocation lifetime correct.

This is a consequence of the language model, rather than a description of Microsoft's unpublished implementation details. The public preview report names a safe Rust component but does not explain every boundary inside it. Rust's documented rules provide a way to understand what a sound boundary must guarantee without guessing how that specific component implements it.

Exclusive mutation makes aliasing part of the contract

Borrowing also constrains simultaneous access. The book describes allowing one mutable reference or multiple immutable references for a value, with validity required throughout their uses. The restrictions prevent code from retaining incompatible references that could observe unsynchronized mutation.

That makes an API's permissions visible in its parameter types. A shared reference permits observation under its contract. A mutable reference gives exclusive access for its relevant use. The compiler can reject overlapping borrows when one function still needs a reference and another operation attempts incompatible access.

For systems code, this matters because an object's lifetime and its access rights are different questions. A pointer can still address allocated memory while another operation changes that memory in a way the reader did not expect. Tracking validity alone does not establish that concurrent or overlapping access obeys the required rules.

The book connects these borrowing restrictions with preventing data races. Its definition involves simultaneous access, at least one writer and missing synchronization. Rust's checks make some invalid arrangements fail during compilation, before a particular runtime schedule is needed to expose them.

I find the explicit access distinction useful because it forces an implementation to state who may mutate a value while someone else uses it. That is a concrete design obligation. It can affect how an API divides an object into independently usable pieces and how long a caller retains access.

Unsafe code handles operations the compiler cannot establish

The versioned chapter on unsafe Rust explains why systems programming still needs operations outside the ordinary safety checks. Direct hardware interaction and foreign-language interfaces can require access that the compiler cannot independently validate.

Raw pointers illustrate the difference. They can be null, may fail to point to valid memory and need not obey the borrowing rules for ordinary references. Creating a raw pointer does not itself require dereferencing it. Accessing the pointed-to value is the operation that requires an unsafe context and a justification for validity.

The unsafe keyword does not disable all compiler checks. As the book explains, the borrow checker continues to check references used inside unsafe code. The keyword permits specific additional operations, including dereferencing raw pointers and calling unsafe functions. Those operations transfer particular proof obligations to the programmer.

An unsafe function's contract is consequently part of the usable API. The caller needs to know which conditions the compiler cannot establish and must satisfy them before the call. A function cannot become sound merely because its call site appears inside an unsafe block. The conditions still have to hold in the actual execution.

This is how Rust can address low-level systems work without claiming that the compiler understands every device or foreign allocator. The implementation can use unchecked operations where necessary while keeping the obligations around them explicit. The scope and correctness of those obligations determine whether ordinary safe callers receive the promised guarantees.

Safe interfaces can contain a smaller unsafe implementation

The book uses splitting a mutable slice into disjoint parts as an example. A straightforward expression returning two mutable ranges can fail borrowing checks because the compiler does not establish that the ranges do not overlap. A lower-level implementation can use raw pointers after checking the split position.

The resulting interface can remain safe. Its implementation establishes that both returned slices refer to valid, disjoint portions of the original allocation. Callers then use the operation without repeating the pointer reasoning. The unsafe work has an owner and a limited purpose.

That is the relevant architectural opportunity in a mixed system. A carefully justified low-level interface can give a larger amount of code ordinary references and safe operations. The compiler can then check uses above that interface, instead of requiring every caller to reason independently about raw addresses.

The opposite arrangement spreads the same obligations across many call sites. Every direct raw-pointer consumer needs to know whether the memory is valid and whether access is compatible with other users. Concentrating the conversion behind a sound interface makes the review question more specific, even though it does not eliminate review.

This analysis does not establish the size of Microsoft's unsafe implementation or identify which particular interfaces it uses. The public sources do not supply that evidence. It explains why the description of a safe Rust implementation is technically meaningful without extending it into an unsupported claim that no unsafe code exists anywhere below it.

The distinction also helps explain why a safe API is an engineering deliverable in its own right. Its implementation must preserve the assumptions callers are allowed to make, including assumptions that ordinary type checking then carries through the rest of the program.

Memory safety is a property with a defined scope

Borrowing and validity rules do not determine whether a function implements the intended policy. An operation can use valid memory and return the wrong answer. A systems component still needs correct behavior at its external interface in addition to correct memory access within its implementation.

This is why a preview integration is useful evidence of adoption but not a measurement of all security outcomes. A language can remove certain ways to express invalid access in safe code. The remaining correctness questions include the soundness of unsafe interfaces and the actual behavior required by the surrounding system.

My interest in the Windows work is the possibility of moving those obligations to a smaller set of low-level interfaces while writing more implementation in checked code. That is consistent with Rust's documented design. The benefit depends on the references supplied to safe code being valid and on unsafe implementations honoring the contracts their callers rely on.

The October report therefore has a concrete systems-programming implication without requiring a claim about a complete rewrite. Rust can participate within an established kernel. Understanding the safety contribution requires following the point where external memory becomes a Rust value, then distinguishing compiler-checked use of that value from the obligations retained by the lower-level interface.