On Wed, Apr 13, 2022 at 09:36:23AM -0400, Cole Robinson wrote: > Hi all, > > SEV-ES and SEV-SNP attestation require a copy of the initial VMSA to > validate the launch measurement. For developers dipping their toe into > SEV-* work, the easiest way to get sample VMSA data for their machine is > to grab it from a running VM. > > There's two techniques I've seen for that: patch some printing into > kernel __sev_launch_update_vmsa, or use systemtap like danpb's script > here: https://gitlab.com/berrange/libvirt/-/blob/lgtm/scripts/sev-vmsa.stp > > Seems like this could be friendlier though. I'd like to work on this if > others agree. > > Some ideas I've seen mentioned in passing: > > - debugfs entry in /sys/kernel/debug/kvm/.../vcpuX/ > - new KVM ioctl > - something with tracepoints > - some kind of dump in dmesg that doesn't require a patch The problem with all the approaches of dumping / extracting a VMSA is that the VMSA contains a register whose value contains CPU model, family, stepping. IOW, over time there are large number of possible valid VMSA blobs, one for each possible CPU variant that is relevant to SEV. Given that, I came to the conclusion that dumping / extracting a VMSA is only useful for the purpose of debugging. We should still have such a mechanism, but it isn't sufficient on its own. For actual launch measurement validation, we need to be able to construct an expected VMSA from technical specs & knowledge of QEMU's SEV impl, such that we can plug in variable field values. 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 :|
