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
