[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) |
Hey,
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
>
>
> 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.
Daniel
[1] https://lists.gnu.org/archive/html/grub-devel/2021-10/msg00107.html