* Cole Robinson (crobinso@xxxxxxxxxx) wrote: > 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? I'm not sure how easy it is to cook up a VMSA when you ask for it; where as following the normal route for vCPU creation and then taking a copy of the VMSA it was about to use sounds easy. (Although I've tried neither). Dave > Thanks, > Cole > -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
