Re: adding 'official' way to dump SEV VMSA

[Cole Robinson]

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?

Thanks,
Cole