UEFI question

[BlackBunnyHunter]

Why does the EFI image have a PE header? Is the windows kernel responsible for loading the efi image?

I ask because I tought the EFI image is loaded before the kernel.

[BlackBunnyHunter]

Another question I have is why can't it be used with HVCI, the documentation says that HVCI runs at a greater privilege level. How is that possible? Isn't EFI the first thing that runs after the motherboard firmware has done its setup.

[Mattiwatti]

Why does the EFI image have a PE header? Is the windows kernel responsible for loading the efi image?

What is "the" EFI image you are wondering about in particular?

In general however the answer to this question is pretty straightforward: the PE format is mandated by the UEFI specification. (Some PEI/PEIM images may also use the smaller TE ("Terse Executable") format, which is different in some details but mostly similar.)

I ask because I tought the EFI image is loaded before the kernel.

That is correct. You can see the load flow and order in the graph in the README.

Another question I have is why can't it be used with HVCI, the documentation says that HVCI runs at a greater privilege level. How is that possible? Isn't EFI the first thing that runs after the motherboard firmware has done its setup.

This is an interesting question. First a minor technical correction: EfiGuard can be used with HVCI (you can try it if you want), it just won't do anything useful. So the question you probably meant to ask is: why doesn't EfiGuard work when HVCI is enabled?

It's true that, as a hypervisor, HVCI's privilege level trumps that of EfiGuard (barring some as-yet unknown disastrous vulnerability in Hyper-V), but (as you correctly point out) EfiGuard does run before HVCI is initialized. So which one 'wins'? That depends on how you look at it. First a note: I'm going to gloss over some differences in the boot process when HVCI is enabled which are actually pretty significant, but not super relevant here. So this is not exactly how it really works, but should give an idea.

Winload.efi starts the hypervisor is HVCI is enabled (or if automatic hypervisor startup is requested for any reason at all). At this point, EfiGuard could intercept winload, right? Well yes, that's true. You have to consider however what exactly EfiGuard could do at this point.

• Prevent the hypervisor from loading? This would probably be easy enough to do. However (and assuming winload.efi doesn't immediately abort at this point), the lack of hypervisor would be fairly obvious once the system is running.
• Replace the hypervisor with one that emulates the original? Theoretically possible perhaps, realistically not. There is also the fact that the Hyper-V hypervisor provides much more functionality than just HVCI.
• Allow the hypervisor to load, but in some crippled state in which HVCI is disabled? This is probably the best case scenario. It would have to be accomplished by patching securekernel.exe and/or skci.dll before they are loaded, in a way that is (A) not obvious to winload.efi, the regular kernel, or themselves, and (B) maintains the system's belief that HVCI is enabled (otherwise, why not simply disable HVCI to begin with?). I have looked at the options here quite extensively, and concluded that they are not feasible, mostly due to the way securekernel.exe/skci.dll are actually loaded: they are only loaded after the 'true' hypervisor executable (hvix64.exe/hvax64.exe, depending on your CPU) has been loaded and has virtualized the machine's CPUs. Therefore, for example, it is not possible for EfiGuard to know the address at which securekernel.exe will be loaded prior to entering the guest state.
• Allow the hypervisor to load, but patch out HVCI at some other time (e.g. once we have located the address at which securekernel.exe is loaded)? This is impossible, or in any case ought to be. If it isn't, then Microsoft would surely patch this immediately as it would be a severe vulnerability in Hyper-V.

I am aware of some alternative possibilities that might allow EfiGuard to disable or bypass HVCI, but I am not willing to discuss these at the moment, because (A) they are probably vulnerabilities, and as such would be patched if I disclosed them, and (B) were not discovered by me, and as such are not for me to disclose.

[DavidXanatos]

What about patching hvix64.exe/hvax64.exe such that it leaks the address of the loaded securekernel.exe and allows the boot-kit to do modifications? I mean in the end if we have first execution there must be a way to win this.

[Mattiwatti]

This is now fixed as somewhat of a side effect of 2f4a666, which makes it so that VBS (this includes HVCI) will be disabled during boot if the EfiGuard DXE driver was loaded.

[DavidXanatos]

nice thank you