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

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* 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?

Dave

> James
> 
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK