[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 0/2] use confidential computing provisioned secrets for di
From: |
Dov Murik |
Subject: |
Re: [PATCH v4 0/2] use confidential computing provisioned secrets for disk decryption |
Date: |
Sun, 27 Feb 2022 16:12:52 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 |
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
>>
>