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

[Daniel P. Berrangé]

On Fri, Jan 21, 2022 at 03:51:51PM +0100, Erik Skultety wrote:
> On Fri, Jan 21, 2022 at 02:44:02PM +0000, Daniel P. Berrangé wrote:
> > 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.
> 
> Hmm, so let me ask if I understand correctly: You want to keep firmware
> autoselection with SEV as is even though you won't be able to do measurements
> and instead let the user provide an explicit type 'rom' setting hinting libvirt
> to pick the right firmware build complying with the confidentiality rules for
> SEV measurements?

That's what this series did at least.

My new approach is to express the different ypes of 'pflash' build

 - 'split' - traditional CODE & VARS files separated
 - 'combined' -  CODE & VARS merged in a single file
 - 'stateless' - CODE only, no VARS


so a user wanting a measurable SEV launch would request a 'stateless'
firmware to be found.

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