Re: [libvirt PATCH 00/28] Improve firmware autoselection

On Mon, Jun 27, 2022 at 11:07:35AM +0100, Daniel P. Berrangé wrote: > On Mon, Jun 27, 2022 at 12:00:59PM +0200, Gerd Hoffmann wrote: > > On Thu, Jun 23, 2022 at 06:14:12PM +0200, Andrea Bolognani wrote: > > > The main motivation behind this series was making it as simple as > > > possible ("one click") to enable Secure Boot for a VM. > > > > Heads up, and sort-of follow-up to the recent secure boot and smm (x86) > > and tz (arm) discussion. Thanks for the heads up, Gerd! > > We'll most likely get a new secure boot variant soon. This will not > > require smm, but it will also not support persistent variables. The > > underlying idea is to simply re-initialize the variable store from > > known-good ROM on each boot to compensate for the varstore not being > > protected against the guest OS tampering with it. > > > > Which of course implies some drawbacks: The guest can't add keys (via > > mokutil) for example, and turning off secure boot in firmware setup > > wouldn't work either. There are enough use cases (like just booting > > cloud images in secure boot mode) where this doesn't matter, so I > > consider this useful nevertheless, but maybe a separate feature flag > > like 'stateless-secure-boot' makes sense for that. > > Since the use case will be virt related, there's always the possibility > of using host side tools to inject a custom key into the default varstore > before the guest OS runs. That doesn't cover all possible mokutil > scenarios, but at least addresses the big one of providing a firmware > that trusts the user's keys, instead of the OS vendor keys. > > I don't think we need a 'stateles-secure-boot' flag, as thats > implicit from mapping.mode=statusless and features.secure-boot We don't currently offer a way to filter firmware builds based on their mode. So on a machine where this new firmware is available, a VM configuration like <os firmware='efi'> <firmware> <feature enabled='yes' name='secure-boot'/> <feature enabled='yes' name='enrolled-keys'/> </firmware> </os> might result in either a firmware with writable variables or a stateless one being selected. If the user's expectation is that they will be able to use mokutil inside the VM, the latter will not make them happy. If we had a separate feature, one could use <os firmware='efi'> <firmware> <feature enabled='no' name='stateless'/> <feature enabled='yes' name='secure-boot'/> <feature enabled='yes' name='enrolled-keys'/> </firmware> </os> to ensure mokutils can be used. Maybe we can make the mode filterable instead? Like <os firmware='efi'> <firmware> <mode name='split'/> <feature enabled='yes' name='secure-boot'/> <feature enabled='yes' name='enrolled-keys'/> </firmware> </os> or something along those lines.