Re: [PATCH v4 0/2] use confidential computing provisioned secrets for disk decryption

[Heinrich Schuchardt]

On 2/7/22 16:29, James Bottomley wrote:
> From: James Bottomley <James.Bottomley@HansenPartnership.com>
>
> v4: Update to new password passing API and fold in review comments
>      original patch 1 (which contained a password passing API) is
>      removed and patch 2 is updated and patch 3 largely unchanged.
>
> 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
>
> (this now needs additional patches to update for the change in flow in v4)
>
> 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 -a
> source (crypto0)/boot/grub.cfg
>
> Assuming there's a standard Linux root partition.
>
> James

Is there a text document that defines the EFI secret table and its contents?

Best regards

Heinrich

> ---
>
> James Bottomley (2):
>    cryptodisk: add OS provided secret support
>    efi: Add API for retrieving the EFI secret for cryptodisk
>
>   grub-core/Makefile.core.def    |   8 ++
>   grub-core/disk/cryptodisk.c    |  56 +++++++++++++-
>   grub-core/disk/efi/efisecret.c | 129 +++++++++++++++++++++++++++++++++
>   include/grub/cryptodisk.h      |  14 ++++
>   include/grub/efi/api.h         |  15 ++++
>   5 files changed, 220 insertions(+), 2 deletions(-)
>   create mode 100644 grub-core/disk/efi/efisecret.c