* James Bottomley (jejb@linux.ibm.com) wrote:
On Wed, 2022-03-09 at 16:42 +0000, Dr. David Alan Gilbert wrote:
* Tobin Feldman-Fitzthum (tobin@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? )
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/0...
(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@redhat.com / Manchester, UK