Hacker News Reader

Comment by 323 | Hacker News Reader

Windows already does this for a number of years.

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).

View on HN

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.

The same was true with Windows Vista and Nvidia graphics drivers

https://www.engadget.com/2008-03-27-nvidia-drivers-responsib...

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.

Intel Rapid Storage technology is another absolute trash piece of software.

Fortunately, Microsoft is effectively killing off those storage driver messes by having DirectStorage only support the standard Microsoft NVMe driver

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

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.

Windows actually uses a cpu feature for kernel patch protection right? I remember trying to figure out why Linux doesn't.

On modern Windows, it actually always runs as guest on Hyper V, and thus many such protection mechanisms ping back on virtualization.

Secure kernel and driver guard are another features with similar protection level.

Are you talking about VBS/HVCS? Isn't that optional or is it on by default for kernel stuff?

Optional on Windows 10, compulsory on Windows 11.

One of the reasons for the hardware requirements.

Wow, didn't know thanks.

How can code be running in kernel mode if it doesn’t have unrestricted memory access?

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.

[0]: https://windowsloop.com/disable-enable-device-guard-windows-...

[1]: https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk...

> 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,

OP's point was about kernel patch protection

how do I disable that?

> but it's another to prevent you from mapping it when you do need it

How do you know if it's a user needing to use it, or an attacker pretending to be a user needing to use it?

I'm willing to accept that if a malicious kernel driver gets loaded, I'm completely pwned.

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".

It is anti-driver-freedom.

Most users don't want driver-freedom. They want user-freedom, that is easily achieved by keeping the kernel open source and replaceable.

If you want to break some in-kernel protection, you can just patch the kernel and remove it.

> They want user-freedom, that is easily achieved by keeping the kernel open source and replaceable.

The original comment I replied to was about the Windows kernel.

Can you elaborate how this feels anti-user?

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.

Ahh right, I forgot about the "user requested" security flag. Makes sense.

> Should any process be able to access the memory of any other process?

Any process? No. My processes? Yes. That includes "sensitive" memory like cryptographic keys.

What distinguishes your processes?

Still build the security protections but allow the administrator to selectively disable/override them.

If you're the admin of the system you can just load up your own kernel, or kernel modules, etc.

> I should have total access to everything

You do have total access. You chose to install an OS that wants to limit it.

Reply on news.ycombinator.com