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