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