Re: [RESEND v3 0/3] use confidential computing provisioned secrets for disk decryption

[James Bottomley]

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.Bottomley@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