* James Bottomley (j...@linux.ibm.com) wrote: > On Fri, 2020-11-13 at 17:50 +0000, Dr. David Alan Gilbert wrote: > > * James Bottomley (j...@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 / dgilb...@redhat.com / Manchester, UK _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel