Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf

[James Bottomley <jejb@linux.ibm.com>]

On Thu, 2020-11-12 at 16:34 +0000, Dr. David Alan Gilbert wrote:
> * Ashish Kalra (ashish.kalra@amd.com) wrote:
> > On Wed, Nov 11, 2020 at 04:13:12PM -0800, James Bottomley wrote:
> > > From: James Bottomley <James.Bottomley@HansenPartnership.com>
> > > 
> > > This patch series is modelled on the structure of the Bhyve
> > > patches for Ovmf, since it does somewhat similar things.  This
> > > patch series creates a separate build for an AmdSev OVMF.fd that
> > > does nothing except combine with grub and boot straight through
> > > the internal grub to try to mount an encrypted volume.
> > > 
> > > Concept: SEV Secure Encrypted Images
> > > ====================================
> > > 
> > > The SEV patches in Linux and OVMF allow for the booting of SEV
> > > VMs in an encrypted state, but don't really show how this could
> > > be done with an encrypted image.  
> > 
> > A basic question here ... the SEV usage model in which the firmware
> > is encrypted and loaded into VM using LAUNCH_UPDATA_DATA and then
> > measurement is provided and attestation is done with the VM owner
> > and after VM owner verifies measurement, the VM owner encrypts the
> > disk encryption key and sends it to the guest and it is injected
> > into the guest using the LAUNCH_SECRET API, which is then used to
> > decrypt the OS encrypted image, won't this work to start the SEV VM
> > with an encrypted image ?
> 
> That's still what James system does, but the problem is maintaining a
> chain of trust from the set of measured binaries to the point at
> which you can use the injected secret.
> 
> On the current OVMF world we end up measuring the OVMF binary, but
> not the stored variable flash; but then what? Who would read the
> injected secret?  Because SEV/SEV-ES has no way of performing a later
> attestation, or updating the measurements, we have no way of
> following the path from OVMF (possibly via variables) to a boot
> loader, to a filesystem.

Right, the specific problem is our current linux boot sequence goes 

OVMF->grub->linux

But OVMF can only execute things on an unencrypted vFAT filesytem, so
if grub is on vFAT there's no way to prevent a cloud admin substituting
the grub binary after attestation is done and the key released if we
only attest OVMF, so the bogus grub binary could simply capture the key
and transmit it to a hacker.

Pulling grub inside OVMF allows us to attest both OVMF and grub as one
entity and also prevents the boot going via the unencrypted vFAT
filesystem, eliminating the potential interception point.

James