grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RESEND v3 0/3] use confidential computing provisioned secrets for disk


From: James Bottomley
Subject: [RESEND v3 0/3] use confidential computing provisioned secrets for disk decryption
Date: Tue, 9 Nov 2021 08:53:53 -0500

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.

James

---

James Bottomley (3):
  cryptodisk: make the password getter and additional argument to
    recover_key
  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        |  77 +++++++++++++++++-
 grub-core/disk/efi/efisecret.c     | 125 +++++++++++++++++++++++++++++
 grub-core/disk/geli.c              |  12 +--
 grub-core/disk/luks.c              |  12 +--
 grub-core/disk/luks2.c             |  12 +--
 grub-core/lib/crypto.c             |   4 +
 grub-core/osdep/unix/password.c    |   4 +
 grub-core/osdep/windows/password.c |   4 +
 include/grub/cryptodisk.h          |  20 ++++-
 include/grub/efi/api.h             |  15 ++++
 11 files changed, 273 insertions(+), 20 deletions(-)
 create mode 100644 grub-core/disk/efi/efisecret.c

-- 
2.26.2




reply via email to

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