[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RESEND v3 0/3] use confidential computing provisioned secrets for d
Re: [RESEND v3 0/3] use confidential computing provisioned secrets for disk decryption
Thu, 18 Nov 2021 15:49:01 +0100
Adding Denis, Patrick and Glenn...
James, please add them to the loop next time.
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
> 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.
> 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
 patches. And I want to take  first because it is an important
improvement for GRUB's crypto infrastructure. Additionally, as Glenn
said in , 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  and check if it does not make any troubles for you it would
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.