On Wed, Apr 10, 2024 at 07:10:22AM -0400, Michael S. Tsirkin wrote: > On Wed, Apr 10, 2024 at 12:35:13PM +0200, Gerd Hoffmann wrote: > > On Wed, Apr 10, 2024 at 03:26:29AM -0400, Michael S. Tsirkin wrote: > > > On Wed, Apr 10, 2024 at 09:21:26AM +0200, Gerd Hoffmann wrote: > > > > If the binary loaded via -kernel is *not* a linux kernel (in which > > > > case protocol == 0), do not patch the linux kernel header fields. > > > > > > > > It's (a) pointless and (b) might break binaries by random patching > > > > and (c) changes the binary hash which in turn breaks secure boot > > > > verification. > > > > > > > > Background: OVMF happily loads and runs not only linux kernels but > > > > any efi binary via direct kernel boot. > > > > > > > > Note: Breaking the secure boot verification is a problem for linux > > > > kernels too, but fixed that is left for another day ... > > > > > > Um we kind of care about Linux ;) > > > > > > What's the plan? I suspect we should just add a command line flag > > > to skip patching? And once we do that, it seems safer to just > > > always rely on the flag? > > > > Well, there are more problems to solve here than just the patching. So > > lets have a look at the bigger picture before discussion the details ... > > > > [ Cc'ing Daniel + Cole ] > > > > Current state of affairs is that OVMF supports two ways to boot a linux > > kernel: > > > > (1) Just load it as EFI binary and boot via linux kernel EFI stub, > > which is the modern way to load a linux kernel (which is why you > > can boot not only linux kernels but any efi binary). > > > > (2) Use the old EFI handover protocol. Which is the RHEL-6 era way to > > boot a linux kernel on EFI. > > > > For method (1) secure boot verification must pass. For (2) not. So if > > you try to use direct kernel boot with secure boot enabled OVMF will > > first try (1), which will fail, then go fallback to (2). > > > > The reason for the failure is not only the patching, but also the fact > > that the linux kernel is typically verified by shim.efi (and the distro > > keys compiled into the binary) instead of the firmware. > > > > Going though (2) is not ideal for multiple reasons, so we need some > > strategy how we'll go handle direct kernel load with uefi and secure > > boot in a way that (1) works. > > > > Options I see: > > > > (a) Stop using direct kernel boot, let virt-install & other tools > > create vfat boot media with shim+kernel+initrd instead. > > > > (b) Enroll the distro signing keys in the efi variable store, so > > booting the kernel without shim.efi works. > > > > (c) Add support for loading shim to qemu (and ovmf), for example > > with a new '-shim' command line option which stores shim.efi > > in some new fw_cfg file. > > > > (b) + (c) both require a fix for the patching issue. The options > > I see here are: > > > > (A) Move the patching from qemu to the linuxboot option rom. > > Strictly speaking it belongs there anyway. It doesn't look > > that easy though, for qemu it is easier to gather all > > information needed ... > > > > (B) Provide both patched and unpatched setup header, so the > > guest can choose what it needs. > > > > (C) When implementing (c) above we can piggyback on the -shim > > switch and skip patching in case it is present. > > > > (D) Add a flag to skip the patching. > > > > Comments? Other/better ideas? > > > > take care, > > Gerd > > So if you didn't decide whether to do b or c then I guess D is > easiest and covers both cases?
Easiest if you look at qemu only. Adding a new config option adds burdens elsewhere though. Users and the management stack have to learn to use the new option. Both (A) and (B) work automatically and can be combined with both (b) and (c). (B) is probably much easier to implement, drawback is it requires an firmware update too. take care, Gerd
