Re: adding 'official' way to dump SEV VMSA

[Dr. David Alan Gilbert]

* Cole Robinson (crobinso@redhat.com) wrote:
> On 4/14/22 4:25 AM, Dr. David Alan Gilbert wrote:
> > * Dov Murik (dovmurik@linux.ibm.com) 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@redhat.com / Manchester, UK