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

[Dr. David Alan Gilbert]

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