It is possible to run qemu VMs that emulate EFI and secureboot well enough for Windows to boot.
This is still true, technically. Windows will boot. But it will not update reliably anymore. Microsoft broke it, ostensibly for "security reasons".
Microsoft released a Windows update that will not install on qemu EFI VMs: https://www.bleepingcomputer.com/news/security/windows-kb5012170-secure-boot... dbx-update-may-fail-with-0x800f0922-error/
I was scratching my head, trying to figure out why this update won't install. A search on the cryptic error code brought up some random crap that wasted a ton of my time, doing things like resizing my system partition, almost bricking my VM (typical MS-Windows noise). Only after I got the bright idea of searching for both the error code and the update code itself did I find this article, and digging further found this:
https://github.com/tianocore/edk2/discussions/3221
There's still a lot of things I don't understand. What is being blacklisted, exactly, here. The OVMF RPM – to the best of my understanding – is emulated hardware. How does running some PowerShell voodoo end up updating (emulated) hardware? And if it's not a magical hardware update, yammers about an update to the bootloader on the EFI system partition. Except that (at least in my case), the bootloader should be Microsoft's own bootloader, since I used Micorosoft's own tools to convert my BIOS Windows VM to an EFI one (mbr2gpt, that's how I was able to get a working EFI Windows VM).
But the bottom line: this is now broken. Just an FYI…
On Sun, Sep 18, 2022, 01:32 Sam Varshavchik mrsam@courier-mta.com wrote:
But the bottom line: this is now broken. Just an FYI…
/// Microsoft does not represent that the UEFI Revocation List is error free and you bear the entire risk of using it. NEITHER MICROSOFT NOR UEFI MAKES ANY WARRANTIES, EXPRESS OR IMPLIED, WITH RESPECT TO THE UEFI REVOCATION LIST, AND MICROSOFT AND UEFI EACH EXPRESSLY DISCLAIMS ALL OTHER EXPRESS, IMPLIED, OR STATUTORY WARRANTIES. THIS INCLUDES THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. ///
https://uefi.org/revocationlistfile
I am not a lawyer, but I'm sure lawyers can have a field day with the above statement. Specially if your machine - real or virtual - stops booting after a revocation list update.
FC
On Sun, 2022-09-18 at 02:30 -0300, Fernando Cassia wrote:
I am not a lawyer, but I'm sure lawyers can have a field day with the above statement. Specially if your machine - real or virtual - stops booting after a revocation list update.
Curiosity makes me wonder why something gets listed there. Manufacturers refused to pay some fee? Stolen code being built into knock-off hardware? How to cancel the fraudulent ones without wrecking the original they cloned?
If I had a legitimately bought PC and it suddenly stopped working I'd be pissed. I don't think I've ever regretted ditching windows over two decades ago.
Fernando Cassia writes:
URL:https://uefi.org/revocationlistfilehttps://uefi.org/revocationlistfile
I am not a lawyer, but I'm sure lawyers can have a field day with the above statement. Specially if your machine - real or virtual - stops booting after a revocation list update.
I defy anyone to produce a logical explanation for the following sequence of events:
1. A bunch of holes were found in a small number of EFI bootloaders (according to the article link I posted).
2. The article I linked to state the following:
"Bootloaders are typically stored in the EFI System Partition, which can be mounted on both Windows and Linux to inspect their version and learn if they are vulnerable or not."
3. I should not have any third-party loaders of any kind in the VM's EFI system partition. The EFI system partition was creating using Windows' internal tool, mbr2gp, that I used to migrate my BIOS-based VM to an EFI one.
4. Microsoft releases an update that, ostensibly, blacklists them.
5. The update chokes on qemu VMs that use this OVMF EFI firmware.
6. I'm told to jump through my arsehole in order to execute some arkane process for installing an updated revocation list.
7. Additionally, the article I linked to states the following:
About the only thing that's clear to me is that in qemu's case, the EFI bootloader must not be on the system partition (it can't be), but in the OVMF firmware image.
None of this makes any sense:
* the list of vulnerable EFI bootloaders, listed in the article, doesn't sound like they anything have to do with OVMF
* Microsoft release an update that blacklists some EFI bootloaders
* but, hey, no big deal, just install some cockamamie update that, allegedly, fixes this
Pardon, but on which planet does a security update, of this nature, is used to – allegedly – blacklist vulnerable firmware but then gets remedied by installing an "update"?
Either the OVMF's EFI firmware is vulnerable or it is not. There is no middle ground. If it's not, why did it get blacklisted. If it is, how does installing an update in the guest VM fix a security vulnerable in the host VM's firmware image?
users@lists.stg.fedoraproject.org