* James Bottomley (jejb@xxxxxxxxxxxxx) wrote: > 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 (Note that's a private list, while libvir-list cc'd above is public - hello all!) > 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. Hmm yes for SNP; for the simple non-SNP one, it actually becomes easier with Clevis; you ignore Tang altogether and just add a Clevis pin that wires the secret through - it looks like a few lines of shell but fits into Clevis which we already have, and Clevis has the smarts to fall back to letting you put a password in from what I can tell. Although Christophe did just point me to: https://github.com/confidential-containers/attestation-agent which seems to have some wiring for basic SEV and Alibaba's online protocol which I've yet to look at. Dave > James > > -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
