Fernando Cassia writes:
<URL:https://uefi.org/revocationlistfile>https://uefi.org/revocationlistfileI 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?
Attachment:
pgpG8r7qeJvYQ.pgp
Description: PGP signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
