Fernando Cassia writes:
<
URL:https://uefi.org/revocationlistfile>https://uefi.org/revocationlis...
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?