On Thu, 2021-11-18 at 15:49 +0100, Daniel Kiper wrote: > Hey, > > Adding Denis, Patrick and Glenn... > > James, please add them to the loop next time.
Sure ... is there some way of telling who should be cc'd (I'm not a fan of the kernel get_maintainer.pl but it gives you a list you can trim)? > > On Tue, Nov 09, 2021 at 08:53:53AM -0500, James Bottomley wrote: > > From: James Bottomley <james.bottom...@hansenpartnership.com> > > > > v3: make password getter specify prompt requirement. Update for > > TDX: > > Make name more generic and expand size of secret area > > > > > > https://github.com/tianocore/edk2/commit/96201ae7bf97c3a2c0ef386110bb93d25e9af1ba > > > > https://github.com/tianocore/edk2/commit/caf8b3872ae2ac961c9fdf4d1d2c5d072c207299 > > > > Redo the cryptodisk secret handler to make it completely > > generic > > and pluggable using a list of named secret providers. Also > > allow an optional additional argument for secret providers that may > > have more than one secret. > > > > v2: update geli.c to use conditional prompt and add callback for > > variable message printing and secret destruction > > > > To achieve encrypted disk images in the AMD SEV and other > > confidential computing encrypted virtual machines, we need to add > > the ability for grub to retrieve the disk passphrase from an OVMF > > provisioned > > configuration table. > > > > https://github.com/tianocore/edk2/commit/01726b6d23d4c8a870dbd5b96c0b9e3caf38ef3c > > > > 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 module [id]' option to cryptodisk > > to allow it to use plugin provided passwords 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: > > > > cryptomount -s efisecret > > source (crypto0)/boot/grub.cfg > > > > Assuming there's a standard Linux root partition. > > Thank you for posting this patch series. Unfortunately it conflicts > with [1] patches. And I want to take [1] first because it is an > important improvement for GRUB's crypto infrastructure. Additionally, > as Glenn said in [1], this crypto infra change should simplify your > code too. > > I have just finished reviewing Glenn's patches and waiting for v4. > I hope we will be able to merge it soon. If you could take a look at > the [1] and check if it does not make any troubles for you it would > be perfect. > > I will drop you a line when Glenn's patches are in the tree and you > can rebase your patch set on top of it. Yes, the rebase looks trivial. I'll do it and repost as soon as the patches are upstream. Regards, James _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
