[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RESEND v3 0/3] use confidential computing provisioned secrets for d
From: |
James Bottomley |
Subject: |
Re: [RESEND v3 0/3] use confidential computing provisioned secrets for disk decryption |
Date: |
Thu, 18 Nov 2021 12:15:55 -0500 |
User-agent: |
Evolution 3.34.4 |
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