[libvirt PATCH 00/28] Improve firmware autoselection

[Andrea Bolognani]

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.

> > Not sure yet how to package that up, best is probably as stateless image
> > because that'll reduce the chances of getting it wrong, i.e. something
> > like this:
> >
> > {
> >     "description": "OVMF with secure boot, no persistent vars",
> >     "interface-types": [
> >         "uefi"
> >     ],
> >     "mapping": {
> >         "device": "flash",
> >         "mode": "stateless",
> >         "executable": {
> >             "filename": "/usr/share/edk2/ovmf/OVMF.secboot.fd",

Just to be clear: the firmware build supporting this new, stateless
style of Secure Boot would be a completely separate one from the
existing OVMF.secboot.fd, right?

> > The idea idea should work for aarch64 too and remove the trustzone support
> > requirement.

Yeah, that'd be a pretty great outcome :)

-- 
Andrea Bolognani / Red Hat / Virtualization