4 ms·

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

by rafale 4y ago

galangalalgol 4y ago
I'm curious what software is telling the kernel no. What enforces this?
- ape4 4y ago
  Why the kernel of course (joke attempt, I am wondering too)
  - salawat 4y ago
    Probably firmware/hardware.
    - monocasa 4y ago
      It's the type 1 hypervisor it wants to run on top of.
      - salawat 4y ago
        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"?
        monocasa 4y ago
        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.
- jandrese 4y ago
  The memory mapper. One of the side benefits of relocatable code is the ability to enforce policy at point of access.
323 4y ago
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-guard-part-1-skpg-initialization/ https://windows-internals.com/hyperguard-secure-kernel-patch...
- forgotpwd16 4y ago
  Very nice. Windows kernel devs is of the few good things Microsoft retains.
leeter 4y ago
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.
- maldev 4y ago
  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.
  - mmis1000 4y ago
    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.
    - maldev 4y ago
      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 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.

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

by rafale 4y ago

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

galangalalgol 4y ago

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

ape4 4y ago
Why the kernel of course (joke attempt, I am wondering too)
- salawat 4y ago
  Probably firmware/hardware.
  - monocasa 4y ago
    It's the type 1 hypervisor it wants to run on top of.
    - salawat 4y ago
      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"?
      - monocasa 4y ago
        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.
jandrese 4y ago
The memory mapper. One of the side benefits of relocatable code is the ability to enforce policy at point of access.

323 4y ago

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-guard-part-1-skpg-initialization/ https://windows-internals.com/hyperguard-secure-kernel-patch...

forgotpwd16 4y ago
Very nice. Windows kernel devs is of the few good things Microsoft retains.

leeter 4y ago

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.

maldev 4y ago
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.
- mmis1000 4y ago
  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.
  - maldev 4y ago
    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 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.