[libvirt PATCH 0/5] Support AMD SEV firmware with -bios instead of pflash

[Daniel P. Berrangé]

On Fri, Jan 21, 2022 at 03:40:23PM +0100, Erik Skultety wrote:
> On Fri, Jan 21, 2022 at 02:16:14PM +0000, Daniel P. Berrangé wrote:
> > On Fri, Jan 14, 2022 at 07:07:10PM +0000, Daniel P. Berrangé wrote:
> > > The firmware distros have given people for use with AMD SEV thus far has
> > > just been one of the regular OVMF builds. This is sufficient for booting
> > > a guest with SEV enabled, but is useless if you want to actually
> > > validate the guest measurement. The NVRAM store is untrustworthy since
> > > it is not included in the measurement. We need to supply a dedicated
> > > build of OVMF without NVRAM support enabled. While it is possible to
> > > use with pflash, we then get a problem with firmware selection as there
> > > is no easy way to make it prefer the firmware without NVRAM. Also the
> > > firmware descriptor treats the NVRAM template as a mandatory field
> > > today and libvirt enforces that.
> > > 
> > > While we could invent a new feature flag 'sev-stateless' for the
> > > firmware descriptors, and/or make the NVRAM template path optional,
> > > it makes more sense if the firmware descriptor just reports the SEV
> > > firmware as type=memory instead of type=flash.
> > > 
> > > If the libvirt XML parses the <loader type='rom'/> attribute when
> > > doing firmware auto-selection, we trivially enable a way for a mgmt
> > > app to indicate that it wants the SEV firmware without NVRAM
> > > support.
> > > 
> > > This series does all the plumbing we need.
> > > 
> > > The only minor issue is that QEMU support for -bios with SEV enabled
> > > firmware is broken:
> > > 
> > >   https://lists.gnu.org/archive/html/qemu-devel/2022-01/msg02957.html
> > 
> > Well turns out the concept is unfixably broken on the QEMU side
> > with SEV enabled UEFI firmware. So I'm going to ditch the first
> > docs patch.
> > 
> > I figure it is still possibly useful to be able to controla
> > auto-firmware selection based on 'type', even if it doesn't
> > help my sev use case, so might as well leave keep that now
> > I've implemented it.
> 
> In any case, in context of patch 2/5, shouldn't autoselect haven been left
> untouched and instead pick the type automatically, say in
> qemuValidateDomainDefBoot or similar depending on whether the domain has
> LaunchSecurity SEV defined in the XML?

Well there's already usage of SEV with existing guests with UEFI
split firmware with pflash. I didn't want to change it to prefer
ROM based firmware because that's a significant semantic change
that means you loose persistence of NVRAM variables. THe new
SEV firmware is not necessarily compatible with the currently
use SEV firmware from a guest OS POV, because it uses embedded
grub rather than invoking grub from the guest disk image.

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