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