On 4/14/22 4:25 AM, Dr. David Alan Gilbert wrote: > * Dov Murik (dovmurik@xxxxxxxxxxxxx) wrote: >> Hi Cole, >> >> On 13/04/2022 16:36, 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 >>> >>> Thoughts? >> >> >> Brijesh suggested to me to construct the VMSA without getting any info from >> the host (except number of vcpus), because the initial state of the vcpus >> is standard and known if you use QEMU and OVMF (but that's open for discussion). >> >> I took his approach (thanks Brijesh!) and now it's how we calculate expected >> SNP measurements in sev-snp-measure [1]. The relevant part for VMSA construction >> is in [2]. >> >> I plan to add SEV-ES and SEV measurements calculation to this >> library/program as well. > > Everyone seems to be writing one; you, Dan etc! > Yeah, I should have mentioned Dan's demo tool here: https://gitlab.com/berrange/libvirt/-/blob/lgtm/tools/virt-dom-sev-vmsa-tool.py Tyler Fanelli is looking at adding that functionality to sevctl too FWIW > I think I agree the right way is to build it programmatically rather > than taking a copy from the kernel; it's fairly simple, although the > scripts get increasingly hairy as you deal with more and more VMM's and > firmwares. > Agreed. A nice way to dump VMSA from the kernel will be useful for debugging, or extending these scripts to support different VMMs. > I think I'd like to see a new ioctl to read the initial VMSA, primarily > as a way of debugging so you can see what VMSA you have when something > goes wrong. > debugfs seems simpler for the dev user (accessing a file per CPU vs code to call ioctl), but beyond that I don't have any insight. Is there a reason you think ioctl and not debugfs? Thanks, Cole
