Re: [PATCH 0/3] Add ability to use SEV provisioned secrets for disk decryption

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

On Fri, 2020-11-13 at 17:50 +0000, Dr. David Alan Gilbert wrote:
> * James Bottomley (jejb@linux.ibm.com) wrote:
> > To achieve encrypted disk images in the AMD SEV encrypted virtual
> > machine, we need to add the ability for grub to retrieve the disk
> > passphrase from the SEV launch secret.  To do this, we've modified
> > OVMF to set aside an area for the injected secret and pass up a
> > configuration table for it:
> > 
> > https://edk2.groups.io/g/devel/topic/78198617#67339
> > 
> > The patches in this series modify grub to look for the disk
> > passphrase in the secret configuration table and use it to decrypt
> > any disks in the system if they are found.  This is so an encrypted
> > image with a properly injected password will boot without any user
> > intervention.
> > 
> > The three patches firstly modify the cryptodisk consumers to allow
> > arbitrary password getters instead of the current console based
> > one. The next patch adds a '-s' option to cryptodisk to allow it to
> > use a saved password and the final one adds a sevsecret command to
> > check for the secrets configuration table and provision the disk
> > passphrase from it if an entry is found.  With all this in place,
> > the sequence to boot an encrypted volume without user intervention
> > is:
> > 
> > sevsecret
> > cryptomount -s
> > source (crypto0)/boot/grub.cfg
> 
> I was thinking what happens if the evil admin adds an extra disc; I
> guess the argument here is that:
>   a) Since you specify (crypto0) it can only be a decrypted disc
>   b) And since only the guest owner can supply the keys, it can only
> be there disc image that can be decrypted.
> 
> Right?

Right, cryptomount will mount as (cryptoN) only those devices which can
actually be decrypted by the key.  Since the initial grub.cfg is built
into the grub that executes from the firmware volume only someone who
knows the decryption key can substitute the booted volume.  If you
substitute an unencrypted volume, the grub.cfg script I constructed
simply errors out (because it can't find any encrypted volumes) and
reboots.  The script is more complicated than the simple illustration
above, but it's in this patch:

https://edk2.groups.io/g/devel/message/67341?p=,,,20,0,0,0::Created,,PATCH+2%2F4,20,2,0,78198619

James