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

[James Bottomley]

On Fri, 2020-11-13 at 18:21 +0000, Dr. David Alan Gilbert wrote:
> * James Bottomley (jejb@linux.ibm.com) wrote:
> > 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
> 
> Hmm:
> 
> +echo "Entering grub config"
> +sevsecret
> +if [ $? -ne 0 ]; then
> +    echo "Failed to locate anything in the SEV secret area,
> prompting for =
> password"
> +    cryptomount -a
> +else
> +    cryptomount -s
> +    if [ $? -ne 0 ]; then
> +        echo "Failed to mount root securely, retrying with password
> prompt"
> +        cryptomount -a
> +    fi
> +fi
> 
> if Eviladmin can make it fall down the cryptomount -a  paths with one
> of their own discs attached they can decrypt that and boot, and then
> if they can later inject the original secret, then mount the original
> disc. I think Brijesh said that the secret could be changed later; so
> perhaps if the admin just stopped the secret being injected
> initially, or caused the VM to start without waiting for the
> injection, that would happen?

In the current scheme the secret is destroyed after cryptomount -s
fails, so you still wouldn't get access.  But the grub.cfg is designed
to be mutable ... if a distro wants a more secure sequence that doesn't
try a fallback, it can construct one.

James