On Wed, 2022-03-09 at 16:42 +0000, Dr. David Alan Gilbert wrote: > * Tobin Feldman-Fitzthum (tobin@xxxxxxxxxxxxx) 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? ) We did a write up about this a while ago on the virt list: https://listman.redhat.com/mailman/private/ibm-virt-security/2021-December/000498.html Dimitri Pal is on the reply suggesting effectively the above and we had quite a discussion about it, the upshot of which was that we might get it to work for -SNP and TDX, but it couldn't work for plain SEV and -ES. What we were looking at above is a mechanism for unifying all the flavours of boot. James
