Drivers which run in kernel space are not allowed anymore to access whatever they want, and Windows own kernel space data structures are protected against modifications by other kernel mode running code (kernel patch protection).
And Windows needed that feature much, much earlier.
One of the open secrets about windows is that in the 3.1 to 98 era, quite a large percentage of system crashes were actually caused by Creative Labs’ audio drivers. Those guys could not produce stable software if their lives depended on it.
But I don’t blame CL for Windows being crash prone. Microsoft made a choice and a compromise to get popular. A permissive driver model made them more popular with customers. If you pander, then the rewards and the consequences are both yours to enjoy.
MS tried to have their cake and eat it too back then. They wanted everyone to think they were the most sophisticated and powerful company because they were the smartest company in the world (which was the internal dialog at the time according to insiders I interviewed), but at the same time that it was all dumb luck and they couldn’t control anything.
Many successful companies and individuals fall into that trap of being unable to differentiate between talent and luck. I'm certainly not saying Microsoft doesn't employ plenty of very talented individuals. But it also takes some fortunate twists of fate to succeed, which were completely out of Microsoft's control. Success is never guaranteed.
Probably didn't help that Microsoft was founded at the end of the Corporate Raider era either. If you ran a company and decided that one of your big successes was being in the right place at the right time, you might keep a bigger war chest to get you through your next bad luck window. But that pile of liquid assets paints a big bullseye on your forehead.
It was 'better' to just assume you were awesome and hope your luck held for years on end. And if it didn't, then you could tell a story about how talent got you big and bad luck took you out. No, it was luck both ways or skill both ways.
Audio drivers being the bane of Windows stability didn't truly stop until Microsoft took Creatives toys away by force with Vista's new audio stack. Instead the new GPU drivers indeed took over that role, but at least more temporarily.
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.
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.
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.
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"?
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 page tables can be set up so kernel-mode code doesn't have access to all of memory. You could get around this by modifying the cr3 register to point to a different page directory, but that could cause problems whenever a context switch happens and cr3 is reverted. Microsoft also has PatchGuard, which could probably detect changes like that.
In theory you could work around all these protections, but it would be difficult and fragile.
> Drivers which run in kernel space are not allowed anymore to access whatever they want
I don't like this. It's one thing to have memory the kernel doesn't usually need be unmapped by default, but it's another to prevent you from mapping it when you do need it. This reeks of DRM.
Prior to Microsoft changing things with Vista, drivers were free to rummage about and break systems. Blue screens were a common thing back then because drivers weren't careful. It's why Vista had such a bad rap for breaking systems; It exposed the driver authors who didn't care about safety.
Also, why does every kernel-safety measure have to be seen as anti-user or DRM? You're free to disable it[0] if you wish, just like Apple's SIP. It's there to keep users who don't know anything safe. Would you like it if an innocent looking piece of software was able to hide itself from the user (read: you) and the OS?[1] Preventing such attacks doesn't sound anti-user to me.
No idea why you're being downvoted. This does sound like an anti-user feature. Stuff like this exists to protect third party software from our analysis and "tampering".
As the owner of the machine, I should have total access to everything. There should be no protected memory I can't read, no execution I can't trace. The number one user of such security features are "rights holders" that consider me hostile and want to protect their software from me, the owner of the machine it is running on. The result is a computer that is factory pwned. It's not really my computer, they're just "generously" allowing me to run software on it as long as it doesn't harm their bottom line.
Virtualization based security, the technology enabling this, also enables DRM. It is currently required by Netflix for 4k resolution streaming.
How do you propose having security in that world? Should any process be able to access the memory of any other process? Should you opening a web page allow you a security issue there to be able to access your running applications?
I guess my question is, you seem to have a very hardline “everything” take that I don’t think extends to the real world
You're confusing "I" should have access to all the data on my machine, with "anything running on my machine" should have access to all the data on my machine.
Drivers which run in kernel space are not allowed anymore to access whatever they want, and Windows own kernel space data structures are protected against modifications by other kernel mode running code (kernel patch protection).