Hacker News Reader

Comment by rafale | Hacker News Reader

That's super interesting. Does it use some special CPU feature? The CPU usually let code running in kernel context do whatever it wants.

View on HN

In Windows 10/11 the core of the Windows kernel can run in a virtual machine totally separated from the rest of the kernel.

> HyperGuard takes advantage of VBS – Virtualization Based Security

> Having memory that cannot be tampered with even from normal kernel code allows for many new security features

> This is also what allows Microsoft to implement HyperGuard – a feature similar to PatchGuard that can’t be tampered with even by malicious code that managed to elevate itself to run in the kernel.

https://windows-internals.com/hyperguard-secure-kernel-patch...

Very nice. Windows kernel devs is of the few good things Microsoft retains.

Not a Windows Kernel Dev. But my understanding is it's more a tripwire than anything else unless virtualization based security is turned on. If that is activated then the Kernel has complete isolation from non-MS drivers and can prevent them from accessing critical data structures. MS has a list of known drivers that don't work with this and prevents users from activating it if it will break things.

Ya, you can look at the bugcheck codes and see the mechanism that does this. Since patchguard will always throw that bugcheck code, I think it's 0x109? It just does random scans and sees if it matches, it's nothing fancy. Even with VBS(virtualization based security) it functions the same and will still allow a driver to modify it, then crash. In windbg you can see this by "!analyze -show 0x109" assuming that its 0x109.

I think VBS's role is ensuring you can no longer patch the PatchGuard itself? Because the guard itself is no longer in the kernel and you can do nothing with it.

But I heard VBS has a ~10% overhead compared to not enable it. I wonder what does cost this. Enable hyperv itself didn't really cause observable difference though.

VBS's role is to mirror the kernel and wall it off through a hypervisor. So your kernel/usermode can't access the secure version. This basically lets it compare the "secure" kernel and the regular kernel structures. Things like the process list, Driver executable regions, signatures, and such are mirrored. So when a process spawns and it's added to the process/threadlist. Those operations are mirrored in the secure kernel then randomly checked for security.

VBS also secures things like the scan timer/event and some other methods people used to use to disable it. http://uninformed.org/index.cgi?v=8&a=5&p=18 .

The performance impact shouldn't really be noticeable at all. All you have is some memory operations which are "Duplicated", but not really since COW. But i'm not that much of an expert on patchguard besides the really basic functions.

I'm curious what software is telling the kernel no. What enforces this?

Why the kernel of course (joke attempt, I am wondering too)

Probably firmware/hardware.

It's the type 1 hypervisor it wants to run on top of.

Then would not the type 1 Hypervisor then become the "kernel" seing as we've defined kernels as "that chunk of code capable of unrestricted access to machine state"?

The line blurs for sure.

I would say it's 'a' kernel. The idea of there only being one kernel is probably a concept that makes for nice layered diagrams, but doesn't come close to describing reality because of the combinatorial complexity of options for different morphs of layering. Sort of like the OSI network layers model in that way.

The memory mapper. One of the side benefits of relocatable code is the ability to enforce policy at point of access.

Reply on news.ycombinator.com