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

[Dov Murik <dovmurik@linux.ibm.com>]

On 26/02/2022 10:04, Heinrich Schuchardt wrote:
> 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?
> 

Such documentation appears in the kernel driver we're proposing [1] to
allow userspace programs to read secrets from the same area (similarly
to how grub can read a secret from it).

In that patch [1], look for "Structure of the EFI secret area" in efi_secret.c.

Here's the relevant part:

+/*
+ * Structure of the EFI secret area
+ *
+ * Offset   Length
+ * (bytes)  (bytes)  Usage
+ * -------  -------  -----
+ *       0       16  Secret table header GUID (must be 1e74f542-71dd-4d66-963e-ef4287ff173b)
+ *      16        4  Length of bytes of the entire secret area
+ *
+ *      20       16  First secret entry's GUID
+ *      36        4  First secret entry's length in bytes (= 16 + 4 + x)
+ *      40        x  First secret entry's data
+ *
+ *    40+x       16  Second secret entry's GUID
+ *    56+x        4  Second secret entry's length in bytes (= 16 + 4 + y)
+ *    60+x        y  Second secret entry's data
+ *
+ * (... and so on for additional entries)
+ *
+ * The GUID of each secret entry designates the usage of the secret data.
+ */


Note that grub is looking for one entry from this table: an entry with
GUID 736870e5-84f0-4973-92ec-06879ce3da0b (GRUB_EFI_DISKPASSWD_GUID).


We'll also add similar documentation to kbs-rs [2] (Key Broker Service) which is
one of the options for the Guest Owner server that generates this secret area
(to be securely injected into the guest).


[1] https://lore.kernel.org/linux-coco/20220201124413.1093099-4-dovmurik@linux.ibm.com/#Z31drivers:virt:coco:efi_secret:efi_secret.c

[2] https://github.com/confidential-containers/kbs-rs


-Dov


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