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

[Ashish Kalra <ashish.kalra@amd.com>]

On Thu, Nov 12, 2020 at 09:07:11AM -0800, James Bottomley wrote:
> 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
> 
> 

Thanks James and Dave for the detailed explanations, i get the picture.

Also after discussion with Brijesh, i understand that this is fixing a
known gap in the SEV s/w stack.

Ashish