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

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.