[Top][All Lists]

[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: Daniel Kiper
Subject: Re: [RESEND v3 0/3] use confidential computing provisioned secrets for disk decryption
Date: Thu, 18 Nov 2021 15:49:01 +0100
User-agent: NeoMutt/20170113 (1.7.2)


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]