Re: [libvirt PATCH 00/28] Improve firmware autoselection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux