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