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

[James Bottomley]

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

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