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 :|
