Explainers11 June 20266 min read

How a kernel driver sees your machine

Ring 0 is a very good seat. It is not a seat that sees everything, and the gap is built into the design rather than a matter of effort.

By Lethal Research

Arguments about kernel anti-cheat fall into two bad camps. It sees everything, or it sees nothing useful. Both are wrong the same way. Both treat a privilege level as if it were a point of view. A driver at ring 0 has huge power over the operating system it lives in. Its blind spots are not about permission. They are about what exists inside that system's map of the world in the first place. This post is about that line, at a design level only. There is nothing here about evading anything.

What ring 0 genuinely gets

A signed kernel driver on Windows runs in the same address space as the kernel. It can walk the structures the kernel keeps. It can sign up for the notices the kernel sends. It can look at the hardware the kernel found at boot. In practice that is a very long list.

Every process, thread, module and handle the kernel knows about, with start and exit notices as they happen.
The loaded driver list, and callbacks when a new image loads.
The PCI device tree as found at boot, with the config space of each function.
The shape of the USB tree, and the descriptors every device reported about itself.
The registry, the file system, and the traces of the past that both keep.
What the platform firmware reports: whether Secure Boot is on, whether a TPM is fitted, and what it measured.
Its own health, as far as anything can check its own health from the inside.

Where the view ends

The limits are built into the design. A driver sees what the machine it runs on can describe.

Boundary	Why it is a boundary	What that does not mean
Another physical machine	A driver has no execution on a separate computer with its own kernel, memory and clock.	It does not mean a second machine is unobservable. It means it is not enumerable from inside the first one.
Bus-master reads that the OS never mediates	DMA is a hardware transaction between a device and the memory controller. The CPU is not asked.	It does not mean nothing can see it. The platform has its own mediation layer, covered below.
Anything above the kernel's own honesty	A driver reading kernel structures is trusting the kernel. Everything below the OS is out of scope.	It does not mean firmware and hypervisor layers are unexamined. Attestation exists precisely for this.
The physical world	A human hand on a mouse is not a data structure.	It does not mean input is unexamined. The results of input are very examinable, statistically.

Where DMA actually sits

This is the part people discuss loosely. A PCIe device doing DMA is not sneaking past the kernel. It is using the bus for what the bus is for. Bus mastering is how storage controllers, network cards and GPUs move data without burning CPU time. That fact sits under the whole approach. It is also why the guard against it is a platform feature, not an anti-cheat feature.

The platform guard is the IOMMU. Microsoft's Kernel DMA Protection uses the system IOMMU to stop external devices doing DMA unless their drivers support memory isolation through DMA remapping. A device whose driver does not support it is blocked from starting by default. It stays blocked until a signed-in user unlocks the screen. Microsoft is plain about the limits of the feature. Its documentation states that Kernel DMA Protection only guards against drive-by DMA attacks after the OS has loaded. Guarding the machine before boot is the job of system firmware.

External projectKernel DMA Protection (Microsoft Learn)First-party documentation on the IOMMU policy, what it covers, and the limits Microsoft states.

The boundary is moving, and not in one direction

Two shifts are worth tracking. First, platform attestation is spreading. Secure Boot and TPM 2.0 have gone from a niche policy to a shipping requirement on major titles. So the question is less what a driver can see and more what the firmware will vouch for. Second, Microsoft has been moving security vendors out of the kernel. The Windows Resiliency Initiative announced a private preview of a platform that lets endpoint security run in user mode. Whether anti-cheat takes that path is not settled. Anyone who tells you it surely will, or surely will not, is guessing.

External projectThe Windows Resiliency InitiativeMicrosoft's June 2025 post on the private preview of an endpoint security platform that runs outside the kernel.

The conclusion people skip

A kernel driver cannot list a second machine. That is not the same as saying a two-machine setup is safe. Those are different claims, and the second does not follow from the first. Detection is not one check that either sees you or does not. It is a pile of signals from the platform, the network, the account, the match and the player. Design choices only take away one class of them. Nobody, us included, can promise an outcome here. Read anyone who does as a vendor who has chosen to lie to you.

External projectKernel-level anti-cheat overviewGeneral background on the products in this space, and on the criticism of the model.

The guides behind this post

DMA setup for Marvel Rivals: NetEase anti-cheat and Kernel DMA Protection

8 min read

Marvel Rivals runs NetEase's own anti-cheat, which starts with the game and cannot be turned off on its own. The game's official guide asks players to turn on Kernel DMA Protection, the Windows feature built to stop outside PCIe devices reading memory.

Open the guide