Re: [libvirt PATCH 00/28] Improve firmware autoselection
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.
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
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",
"format": "raw"
}
},
"targets": [
{
"architecture": "x86_64",
"machines": [
"pc-i440fx-*"
"pc-q35-*"
]
}
],
"features": [
"secure-boot",
"enrolled-keys",
]
}
This looks reasonable.
The idea idea should work for aarch64 too and remove the trustzone support
requirement.
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 :|