Re: REST service for libvirt to simplify SEV(ES) launch measurement

* Tobin Feldman-Fitzthum (tobin(a)linux.ibm.com) wrote: > > On 3/3/22 12:20 PM, Daniel P. Berrangé wrote: > > On Fri, Feb 25, 2022 at 03:10:35PM -0500, Tobin Feldman-Fitzthum > > wrote: > > > > > > On 2/24/22 7:26 AM, Daniel P. Berrangé wrote:

> > > > I can understand if it is harder to achieve commonality with > > > > tech like libkrun though, since that's consuming virt in > > > > quite a different way at the userspace level. > > > Yeah, extending the focus beyond SEV(-ES) with QEMU might make > > > things more difficult. There is some discussion right now about > > > trying to find common ground between SEV-SNP and TDX > > > attestation, but I assume that is all out of scope since > > > libvirt isn't really involved. > > > > I admit I don't know much about TDX, but from what I've > > understood talking to other people, SEV-SNP might not end up > > looking all that different. IIUC the attestation has to be > > initiated from inside the SNP guest after CPUs are running. It is > > going need to be run as early as possible and while you might be > > able todo it in the initrd, it feels likely that it could be put > > into the firmware (OVMF) instead, such that it does the > > validation before even loading the kernel. This would facilitate > > supporting it with arbitrary guest OS, as the firmware is common > > to all. We can't assume the firmware will have direct network > > connectivity to any attestation service needed to verify the > > boot. This implies the firmware might need to talk to the host > > via something like virtio-serial / virtio-vsock, from where > > libvirt or QEMU can proxy the traffic onto the real attestation > > service. Such an architecture might end up aligning quite well > > with SEV/SEV-ES, possible allowing the same protocol to be used > > in both cases, just with differnt ultimate end points (libvirt > > for SEV(-ES) vs guest firmware for SEV-SNP). > > Yeah that is an interesting point. Most SNP approaches that I have > seen so far use the kernel/initrd to handle decryption. There is > potentially a gap if the kernel/initrd are not themselves part of > the measurement that is provided in the attestation report. We have > been using this measured direct boot thing for SEV(-ES) and I think > it can be extended to SEV-SNP as well. This would close that gap > and make it feasible to do the decryption in the kernel. With the direct boot setup, it feels like using 'clevis' in the initrd would be the right way to wire things to disk decryption. [ https://github.com/latchset/clevis ] It would need a 'pin' writing for SNP that then did whatever communication mechanism we settled on. (A clevis pin might also be the way to wire the simple disk key from your EFI/SEV mechanism up to LUKS? )