[libvirt PATCH 00/28] Improve firmware autoselection

[Daniel P. Berrangé]

On Mon, Jun 27, 2022 at 09:04:02AM -0700, Andrea Bolognani wrote:
> 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.

This is the wrong place to be configuring it, as this is actually
a guest ABI issue.  What we need is to express that a given VM
configuration must not have NVRAM present, and this is independant
of firmware feature selection

IOW, we need

   <os ...>
      ....
      <nvram present="yes|no"/>
      ...
   </os>

this is something I have a PoC for for AMD SEV, but still have some
tidying up to do. Essentially if NVRAM is set as not present, then
we would only match firmware descriptors with mode=stateless


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|