Google is exploring a new approach to Linux kernel security that could significantly change how device drivers interact with the operating system. The experimental project, known as Kage, uses compiler-based sandboxing to isolate drivers inside the kernel, potentially limiting the damage caused by memory corruption, programming errors, and exploitable vulnerabilities without requiring drivers to run as separate user-space processes.

The research was presented at the Linux Plumbers Conference 2026, held October 5–7, with Stanford University and Google researcher Zachary Yedidia discussing how LLVM's Lightweight Fault Isolation (LFI) technology can create restricted execution environments for native kernel code. Unlike conventional isolation techniques, which often depend on separate processes or virtual machines, Kage attempts to preserve the performance advantages of kernel-space execution while reducing the amount of memory individual drivers can access.

Early prototypes have already demonstrated the concept using NVMe storage, networking, and Wi-Fi drivers. However, Kage remains an experimental research project rather than a feature available in mainstream Linux distributions. Its developers are still investigating performance, hardware access, and compatibility with more complicated drivers, including graphics hardware.

Why Device Drivers Remain a Major Linux Security Challenge

Linux device drivers are responsible for connecting the operating system to hardware components, including graphics cards, network adapters, storage controllers, USB devices, and wireless chipsets. Most traditional Linux drivers execute in kernel space, giving them privileged access to system resources and the ability to interact directly with hardware. This architecture is one reason Linux can deliver high performance across such a broad range of devices, but it also creates a significant security challenge.

When an ordinary application encounters a memory error, the operating system can often terminate that process without affecting the rest of the system. Kernel drivers operate under different conditions. Because they typically share the kernel's address space and privileges, an invalid memory access or exploitable vulnerability can affect unrelated kernel components, potentially resulting in a system crash, privilege escalation, or complete compromise of the operating system.

The challenge becomes more complicated when considering the enormous number of drivers supported by Linux. Some are maintained by large organizations with extensive testing infrastructure, while others receive contributions from smaller development teams or individual maintainers. Even carefully reviewed drivers can contain bugs, particularly when they interact with complicated hardware, asynchronous operations, and memory-management mechanisms.

Google's Kage research addresses this fundamental problem by questioning whether every driver needs unrestricted access to the entire kernel simply because it executes at kernel privilege level.

Introducing Kage and Its In-Kernel Sandbox Architecture

Kage is an experimental Linux kernel subsystem designed to execute selected kernel modules inside restricted memory regions. The approach relies on LLVM's Lightweight Fault Isolation technology, which constrains the memory accesses and control-flow operations performed by compiled native code. Rather than relocating a driver to user space, Kage allows it to continue running within the kernel while enforcing boundaries around the memory it can access.

This distinction is central to the project's design. Sandboxed drivers continue executing at the same hardware privilege level as the rest of Linux and remain within the kernel's address space. However, their compiled instructions are constrained so that memory operations cannot freely reach outside the designated sandbox region. The objective is to contain certain classes of memory corruption without requiring the substantial architectural changes associated with moving existing drivers into separate processes.

The Linux Plumbers Conference presentation describes Kage as an attempt to keep sandbox transition costs relatively low while reducing the engineering effort needed to adapt existing drivers. Instead of rewriting the Linux driver architecture, developers could potentially modify selected drivers to operate through validated interfaces while keeping much of their original functionality intact.

That approach could make driver isolation more practical for a mature operating system such as Linux, where replacing thousands of established drivers with an entirely new architecture would be extremely difficult.

How LLVM Lightweight Fault Isolation Works

Lightweight Fault Isolation is a software-based isolation technology developed through research at Stanford with support from Google. Its purpose is to allow native machine code to execute within restricted regions of an existing process without necessarily requiring a separate process or virtual machine for isolation. Kage adapts that concept to the Linux kernel, where performance-sensitive drivers often need to communicate frequently with other kernel subsystems.

At a high level, LFI relies on compiler-generated restrictions and verification of the resulting machine code. Memory accesses are constrained to approved regions, while control-flow restrictions prevent sandboxed code from freely executing arbitrary instructions outside the permitted environment. The result is an isolation model that operates within the same hardware privilege level while attempting to prevent code from escaping its assigned boundaries.

Consider a simplified example of a memory operation that might appear in a conventional C driver:

void write_device_buffer(char *buffer, size_t index)
{
    buffer[index] = 0x42;
}

If index contains an incorrect value, the function could write beyond the intended buffer. In conventional kernel code, an out-of-bounds write may corrupt unrelated kernel memory if the resulting address is accessible. Such errors are especially dangerous because the kernel generally has extensive access to system memory.

With an LFI-based sandbox, the generated machine code is constrained so that its memory operations remain within an authorized region. This does not automatically correct the programming error, nor does it guarantee that the driver will continue functioning after a fault. Instead, the goal is to prevent certain invalid memory operations from affecting memory outside the isolated component.

An important aspect of LFI is its machine-code verifier, which checks that compiled instructions comply with the sandbox's restrictions. This reduces reliance on the compiler itself as a trusted security component. According to the Kage presentation, the verifier is intended to preserve isolation even when the sandboxed code is potentially malicious, rather than merely protecting against accidental mistakes.

Why Machine-Code Verification Matters

Compiler-based security mechanisms introduce an important question: what happens if the compiler produces incorrect code? If isolation depends entirely on the compiler inserting the appropriate restrictions, a compiler bug could undermine the security boundary. LFI addresses this concern by checking the resulting executable instructions rather than assuming every transformation performed during compilation is correct.

The verifier examines whether the machine code follows the required rules for memory access and control flow. Code that does not satisfy those restrictions should not be accepted as valid sandboxed code. This separation between generating code and verifying its safety helps reduce the amount of trusted software involved in enforcing the isolation boundary.

For kernel drivers, this is particularly important because the consequences of a sandbox escape could be severe. A malicious or compromised driver that successfully bypasses its memory restrictions could potentially regain the broad access traditionally available to kernel modules. The verifier is therefore a central part of the proposed security model, not simply an optional development tool.

LLVM support is also progressing across processor architectures. LFI support is already upstream for AArch64, while x86 and x86_64 support is being developed with completion targeted around LLVM 24. This matters because any practical Linux driver-isolation technology must eventually support the architectures used across servers, desktops, embedded systems, and mobile devices.

Kage Uses BTF to Create Safer Driver Interfaces

Restricting memory access is only one part of isolating a device driver. Drivers still need to communicate with the rest of the kernel, requesting services, exchanging information, and accessing resources required to operate hardware. If those interactions expose unrestricted kernel pointers or allow arbitrary function calls, the sandbox's protection could be weakened considerably.

Kage addresses this problem by using BPF Type Format (BTF) metadata to validate function signatures when calls cross the boundary between a sandboxed module and the main kernel. BTF is commonly associated with eBPF, but it also provides structured information about kernel types and interfaces that can be useful for other security mechanisms.

By using this metadata, Kage can check that calls between the kernel and isolated modules follow the expected interfaces. The project also replaces kernel pointers with opaque handles during these interactions, reducing the amount of internal kernel memory directly exposed to sandboxed code.

An opaque handle represents a resource without exposing the underlying pointer. A conceptual interface might look like this:

/* Illustrative example, not an actual Kage API */

typedef unsigned long kernel_handle_t;

int process_device_request(kernel_handle_t device)
{
    /* Access the resource through a validated interface. */
    return 0;
}

Instead of receiving unrestricted access to an internal kernel structure, the sandboxed driver receives a handle that can be interpreted by a trusted interface. The kernel can then validate operations involving that resource. This helps separate the driver's legitimate functionality from the broad memory privileges that conventional kernel code normally possesses.

VKage Combines Driver Isolation With VirtIO

Researchers are also experimenting with a related architecture called VKage, which combines Kage with VirtIO. Traditionally, VirtIO provides standardized interfaces that allow virtual machines to communicate efficiently with virtual devices. A guest operating system might use VirtIO for networking or storage rather than interacting with a fully emulated physical device.

VKage explores using these abstractions differently. Instead of communicating with a driver running inside a separate virtual machine, the kernel communicates with a driver isolated inside a Kage sandbox. The design effectively applies VirtIO-style interfaces to an in-kernel isolation boundary, creating a potential way to separate device-driver functionality from the rest of the operating system without introducing a complete guest operating system.

This approach is particularly interesting because existing VirtIO interfaces already provide well-understood models for communicating with storage and networking devices. Reusing those concepts could make it easier to adapt certain drivers to a sandboxed architecture while limiting the amount of direct interaction they require with unrelated kernel components.

According to reporting published October 7, VKage prototypes have already demonstrated working NVMe, networking, and Wi-Fi drivers. These results show that the research has progressed beyond simple computational modules, although the developers still need to evaluate performance and expand support for more complicated hardware interactions.

NVMe, Networking, and Wi-Fi Demonstrate the Potential

The choice of NVMe, networking, and Wi-Fi drivers is significant because these components represent different categories of hardware workloads. NVMe drivers handle high-speed storage operations where latency and throughput are critical. Network drivers process packets, manage device queues, and interact closely with the kernel networking stack. Wireless drivers add further complexity through firmware communication, connection management, and radio-specific operations.

Successfully prototyping isolation for these devices suggests that Kage could eventually support practical hardware workloads rather than being limited to small modules that perform calculations. Nevertheless, demonstrating that a driver can function inside a sandbox is different from proving that it can do so efficiently and securely under all operating conditions.

For storage and networking workloads, even modest performance overhead can become significant when a device processes hundreds of thousands or millions of operations per second. The researchers therefore need to measure how frequently sandbox transitions occur, how much instruction instrumentation costs, and whether communication across validated interfaces creates bottlenecks.

The project's next phase will need to establish whether the security benefits justify those costs. Until detailed performance results become available, claims that Kage provides production-ready isolation with negligible overhead would be premature.

DMA and Hardware Access Remain Major Obstacles

One of the most difficult aspects of sandboxing device drivers is controlling Direct Memory Access (DMA). DMA allows hardware devices to transfer data directly between device buffers and system memory without requiring the CPU to copy every byte. It is essential for high-performance storage, networking, and graphics workloads, but it also creates a challenge for software-based isolation.

LFI constrains instructions executed by the CPU. A hardware device performing DMA, however, does not necessarily follow those software restrictions. If a compromised driver can configure a device to write to arbitrary physical memory, the device could potentially bypass the protection applied to the driver's CPU instructions.

Linux drivers commonly interact with the kernel's DMA mapping infrastructure through operations such as:

dma_addr_t dma_address;

dma_address = dma_map_single(
    device,
    buffer,
    buffer_size,
    DMA_TO_DEVICE
);

if (dma_mapping_error(device, dma_address)) {
    /* Handle mapping failure. */
}

This is a conventional Linux DMA API example, not Kage-specific code. It illustrates why sandboxing drivers requires more than restricting ordinary pointer operations: the hardware itself must also be prevented from accessing unauthorized memory.

Kage's development roadmap includes DMA isolation through an Input-Output Memory Management Unit (IOMMU). An IOMMU can restrict the physical memory regions accessible to a device, potentially complementing LFI's restrictions on CPU-executed instructions. The researchers are also investigating memory-mapped I/O, shared buffers, and interrupt routing, all of which are necessary for supporting more complicated drivers.

These capabilities remain part of the research effort. Their inclusion in the roadmap should not be interpreted as evidence that Kage already provides complete protection against malicious hardware access.

Could GPU Drivers Eventually Be Sandboxed?

Graphics drivers represent another possible application for Kage, although they are substantially more complicated than many conventional device drivers. Modern GPU drivers manage memory allocation, command submission, synchronization, display hardware, power management, and communication with graphics processors. They frequently interact with the Linux Direct Rendering Manager subsystem and rely heavily on shared memory and DMA.

A vulnerability in a graphics driver can be particularly serious because GPUs process workloads originating from browsers, games, multimedia applications, and other software that may handle untrusted content. Limiting the memory accessible to GPU drivers could therefore provide meaningful security benefits, especially on systems where applications frequently interact with complex graphics interfaces.

However, isolating a GPU driver would require solving numerous challenges involving shared buffers, hardware command queues, memory mapping, and interrupts. The researchers have identified GPU drivers as a possible future target, but there is no confirmed implementation demonstrating complete GPU driver isolation through Kage.

The October 7 reporting also notes that Google may explore Kage or VKage for Android device drivers. Android's dependence on the Linux kernel and its large collection of hardware-specific drivers makes it a potentially interesting environment for this research, but no Android release has been announced as shipping the technology.

How Kage Compares With Rust for Linux

Kage arrives during a period when Linux developers are increasingly interested in reducing memory-safety vulnerabilities. One of the most visible efforts is Rust for Linux, which allows selected kernel components and drivers to be written using Rust's memory-safety features. Rust can prevent many common memory-management errors through its ownership and borrowing model, reducing the likelihood that unsafe memory operations will be introduced into new code.

Kage approaches the problem from a different direction. Rather than requiring developers to rewrite existing drivers in another programming language, it attempts to constrain native driver code within a restricted execution environment. This could make it useful for the large collection of existing C drivers that would be expensive or impractical to rewrite completely.

The two technologies address different parts of the security problem. Rust aims to prevent many memory-safety bugs from occurring, while sandboxing attempts to contain the consequences when vulnerable or malicious code executes. A memory-safe driver can still contain logic errors, and a sandboxed driver can still malfunction within its permitted environment.

In principle, Linux could benefit from both approaches. Memory-safe implementations could reduce the number of vulnerabilities introduced into new drivers, while isolation mechanisms could provide additional protection around existing native code.

What Linux Users Can Do Today

Kage is not currently available as a standard feature in mainstream Linux kernels, so users cannot simply enable it through a configuration option or install a package from their distribution's repositories. Nevertheless, understanding which kernel modules are loaded and where they originate remains useful for administrators evaluating system security.

Linux provides several commands for examining its driver environment. To list currently loaded modules, use:

lsmod

To inspect a particular driver, such as the Intel i915 graphics module, run:

modinfo i915

Administrators can also review kernel messages from the current boot to identify driver initialization failures, hardware errors, or unexpected module behavior:

sudo journalctl -k -b

For a quick view of the running kernel version and its module directory:

uname -r
ls /lib/modules/$(uname -r)/

These commands do not provide sandboxing or prevent kernel vulnerabilities. They are diagnostic tools that help administrators understand the components running with kernel privileges. Keeping the kernel updated, minimizing unnecessary third-party modules, and applying vendor security fixes remain important defensive practices while technologies such as Kage continue developing.

What Needs to Happen Before Kage Can Reach Mainline Linux?

The distance between a working research prototype and a production Linux kernel feature can be substantial. Kage has demonstrated an interesting isolation model, but its developers still need to address the practical requirements of complex hardware drivers, including reliable memory sharing, DMA restrictions, interrupt handling, and integration with existing kernel interfaces.

Performance testing will be another decisive factor. Kernel developers are generally cautious about introducing mechanisms that add significant overhead to common operations, particularly when they affect storage, networking, or other performance-sensitive subsystems. Kage will need to demonstrate that its isolation model offers worthwhile security improvements without imposing unacceptable costs on ordinary hardware workloads.

The project must also undergo the extensive technical review associated with Linux kernel development. Its interfaces, maintenance requirements, security assumptions, and compatibility with existing drivers will all need careful evaluation before it can be considered for broader adoption.

As of October 8, 2026, Kage remains experimental, with no announced mainline Linux integration schedule or confirmed distribution rollout. Its current significance lies in demonstrating a possible direction for future kernel security rather than offering an immediately deployable solution.

Conclusion

Google's Kage research presents an ambitious alternative to the traditional assumption that every Linux device driver must operate with unrestricted kernel memory access. By combining LLVM Lightweight Fault Isolation with validated interfaces and restricted execution regions, the project explores whether existing native drivers can be isolated without sacrificing the architectural advantages of running inside the kernel.

The early demonstrations are encouraging. Kage can already sandbox simple computational modules, while VKage prototypes have extended the concept to NVMe, networking, and Wi-Fi drivers. The use of BTF metadata, opaque kernel handles, and machine-code verification provides a foundation for enforcing boundaries between isolated code and the rest of Linux.

Important challenges remain, particularly around DMA, shared memory, interrupts, graphics drivers, and real-world performance. Kage is not ready for ordinary Linux installations, and there is no confirmed timeline for its inclusion in the mainline kernel. Even so, the project highlights a meaningful shift in kernel security research: rather than relying exclusively on eliminating every driver vulnerability, developers are investigating ways to prevent individual driver failures from compromising the entire operating system.

If that approach proves practical, Kage could eventually become another important layer of protection for Linux systems, complementing memory-safe programming, hardware-assisted isolation, and the security mechanisms already used throughout the kernel.