On Tue, Apr 19, 2022 at 09:33:21AM -0400, Cole Robinson wrote:
> On 4/14/22 4:25 AM, Dr. David Alan Gilbert wrote:
> > * Dov Murik ([email protected]) wrote:
> >> 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
FYI a bit of explanation of that tool...
Some complications wrt VMSA contents in no particular order
- VMSA contents can vary across firmwares due to reset address
- No current supportable way to extract VMSA from kernel
- VMSA varies across userspace QEMU vs libkrun
- VMSA varies across CPU due to include model/family/stepping
The last point in particular is a big pain, becasue it means that there
are going to be a great many valid VMSA blobs.
Thus I put some time into working on the above tool to build VMSA from
first principles. ie populating register defaults based on the AMD tech
specs for x86/sev, along with examination on what KVM/QEMU does to override
the defaults in places.
The tool does three simple things...
Create a generic VMSA for CPU 0 for QEMU:
$ virt-dom-sev-vmsa-tool.py build --cpu 0 --userspace qemu cpu0.bin
Update the generic VMSA with firmware and CPU details
$ virt-dom-sev-vmsa-tool.py update \
--firmware OVMF.amdsev.fd \
--model 49 --family 23 --stepping 0 cpu0.bin
Note, I split this as I felt it might be interesting for a cloud provider
to publish a known "generic" VMSA, and then let it be customized per boot
depending on what CPU model/family the VM ran on, and/or what firmware
it was booted with. The 'build' command can directly set the firmware
and cpu model/family though, if all-in-one is sufficient.
Display the VMSA register info, skipping fields which are all zero
$ virt-dom-sev-vmsa-tool.py show --zeroes skip cpu0.bin
es_attrib : 0x0093 (10010011 00000000)
es_limit : 0x0000ffff
cs_selector : 0xf000
cs_attrib : 0x009b (10011011 00000000)
cs_limit : 0x0000ffff
cs_base : 0x00000000ffff0000
ss_attrib : 0x0093 (10010011 00000000)
ss_limit : 0x0000ffff
ds_attrib : 0x0093 (10010011 00000000)
ds_limit : 0x0000ffff
fs_attrib : 0x0093 (10010011 00000000)
fs_limit : 0x0000ffff
gs_attrib : 0x0093 (10010011 00000000)
gs_limit : 0x0000ffff
gdtr_limit : 0x0000ffff
ldtr_attrib : 0x0082 (10000010 00000000)
ldtr_limit : 0x0000ffff
idtr_limit : 0x0000ffff
tr_attrib : 0x008b (10001011 00000000)
tr_limit : 0x0000ffff
efer : 0x0000000000001000
cr4 : 0x0000000000000040
cr0 : 0x0000000000000010
dr7 : 0x0000000000000400
dr6 : 0x00000000ffff0ff0
rflags : 0x0000000000000002
rip : 0x000000000000fff0
g_pat : 0x0007040600070406
rdx : 0x0000000000830f10 (00010000 00001111 10000011 00000000
00000000 00000000 00000000 00000000)
xcr0 : 0x0000000000000001
The 'show' command is largely a debugging tool, so you can understand what
unexpectedly changed if you're failing to get a valid match.
If you look at the code, you can see comments on where I found the various
default values. I'm fairly confident about the QEMU source, but I am not
happy with my info sources for libkrun but then I didn't spend much time
exploring its code. Anyway, it can at least spit out a vmsa that matches
what is committed in libkrun's git repo.
I'm not in love with this particular impl of the tool. I wrote it to be
quick & easy, to prove the viability of a 'build from specs' approach
to VMSA. I find this the most satisfactory way out of all the options
we've considered so far. The need for a different VMSA per cpu
family/model/stepping in particular, makes me feel we need a tool like
this, as just publishing known good VMSA is not viable with so many
combinations possible.
> Tyler Fanelli is looking at adding that functionality to sevctl too FWIW
Yes, I think this functionality belongs in sev / sevctl, rather than
my python script, so I'm not intended to submit my python program as
an official solution for anything. It is just there as a historical
curiosity at this point, until sevctl can do the same.
> > 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?
A debugfs entry could be useful for automated data collection tools.
eg sosreport could capture a debugfs file easily for a running VM,
where as using an ioctl will require special code to be written for
sosreport.
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 :|
