On Thu, Nov 18, 2021 at 12:15:55PM -0500, James Bottomley wrote: > 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)?
You can take a look at the MAINTAINERS files. Sadly it only lists core maintainers who should be CC-ed. If you CC them they will tell you if you should add anybody else. I know it is not perfect but... I hope we will improve this at some point. > > 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. Cool! Thanks! Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
