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

[Daniel Kiper]

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

Cool! Thanks!

Daniel