On Fri, 2020-11-13 at 18:21 +0000, Dr. David Alan Gilbert wrote: > * 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?
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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
