Gentle ping for this series. (also at https://lore.kernel.org/linux-coco/20211129114251.3741721-1-dovmurik@xxxxxxxxxxxxx/ ) [+cc Gerd, Lenny] Thanks, -Dov On 29/11/2021 13:42, Dov Murik wrote: > Confidential computing (coco) hardware such as AMD SEV (Secure Encrypted > Virtualization) allows guest owners to inject secrets into the VMs > memory without the host/hypervisor being able to read them. In SEV, > secret injection is performed early in the VM launch process, before the > guest starts running. > > OVMF already reserves designated area for secret injection (in its > AmdSev package; see edk2 commit 01726b6d23d4 "OvmfPkg/AmdSev: Expose the > Sev Secret area using a configuration table" [1]), but the secrets were > not available in the guest kernel. > > The patch series keeps the address of the EFI-provided memory for > injected secrets, and exposes the secrets to userspace via securityfs > using a new efi_secret kernel module. The module is autoloaded (by the > EFI driver) if the secret area is populated. > > The first patch in EFI keeps the address of the secret area as passed in > the EFI configuration table. The second patch is a quirk fix for older > firmwares didn't mark the secrets page as EFI_RESERVED_TYPE. The third > patch introduces the new efi_secret module that exposes the content of > the secret entries as securityfs files, and allows clearing out secrets > with a file unlink interface. The fourth patch auto-loads the > efi_secret module during startup if the injected secrets area is > populated. The last patch documents the data flow of confidential > computing secret injection. > > As a usage example, consider a guest performing computations on > encrypted files. The Guest Owner provides the decryption key (= secret) > using the secret injection mechanism. The guest application reads the > secret from the efi_secret filesystem and proceeds to decrypt the files > into memory and then performs the needed computations on the content. > > In this example, the host can't read the files from the disk image > because they are encrypted. Host can't read the decryption key because > it is passed using the secret injection mechanism (= secure channel). > Host can't read the decrypted content from memory because it's a > confidential (memory-encrypted) guest. > > This has been tested with AMD SEV and SEV-ES guests, but the kernel side > of handling the secret area has no SEV-specific dependencies, and > therefore might be usable (perhaps with minor changes) for any > confidential computing hardware that can publish the secret area via the > standard EFI config table entry. > > To enable this functionality, set CONFIG_EFI_SECRET=m when building the > guest kernel. > > Here is a simple example for usage of the efi_secret module in a guest > to which an EFI secret area with 4 secrets was injected during launch: > > # ls -la /sys/kernel/security/coco/efi_secret > total 0 > drwxr-xr-x 2 root root 0 Jun 28 11:54 . > drwxr-xr-x 3 root root 0 Jun 28 11:54 .. > -r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec-06879ce3da0b > -r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e-d3a0b54312c6 > -r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d-ff17f78864d2 > -r--r----- 1 root root 0 Jun 28 11:54 e6f5a162-d67f-4750-a67c-5d065f2a9910 > > # xxd /sys/kernel/security/coco/efi_secret/e6f5a162-d67f-4750-a67c-5d065f2a9910 > 00000000: 7468 6573 652d 6172 652d 7468 652d 6b61 these-are-the-ka > 00000010: 7461 2d73 6563 7265 7473 0001 0203 0405 ta-secrets...... > 00000020: 0607 .. > > # rm /sys/kernel/security/coco/efi_secret/e6f5a162-d67f-4750-a67c-5d065f2a9910 > > # ls -la /sys/kernel/security/coco/efi_secret > total 0 > drwxr-xr-x 2 root root 0 Jun 28 11:55 . > drwxr-xr-x 3 root root 0 Jun 28 11:54 .. > -r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec-06879ce3da0b > -r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e-d3a0b54312c6 > -r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d-ff17f78864d2 > > > [1] https://github.com/tianocore/edk2/commit/01726b6d23d4 > > > --- > > v6 changes: > - Autoload the efi_secret module if the secret area is populated > (thanks Greg KH). > - efi_secret: Depend on X86_64 because we use ioremap_encrypted() which > is only defined for this arch. > - efi_secret.c: Remove unneeded tableheader_guid local variable. > - Documentation fixes. > > v5: https://lore.kernel.org/linux-coco/20211118113359.642571-1-dovmurik@xxxxxxxxxxxxx/ > v5 changes: > - Simplify EFI code: instead of copying the secret area, the firmware > marks the secret area as EFI_RESERVED_TYPE, and then the uefi_init() > code just keeps the pointer as it appears in the EFI configuration > table. The use of reserved pages is similar to the AMD SEV-SNP > patches for handling SNP-Secrets and SNP-CPUID pages. > - In order to handle OVMF releases out there which mark the > confidential computing secrets page as EFI_BOOT_SERVICES_DATA, add > efi/libstub code that detects this and fixes the E820 map to reserve > this page. > - In the efi_secret module code, map the secrets page using > ioremap_encrypted (again, similar to the AMD SEV-SNP guest patches > for accessing SNP-Secrets and SNP-CPUID pages). > - Add documentation in Documentation/security/coco/efi_secret. > > v4: https://lore.kernel.org/linux-coco/20211020061408.3447533-1-dovmurik@xxxxxxxxxxxxx/ > v4 changes: > - Guard all the new EFI and efi-stub code (patches 1+2) with #ifdef > CONFIG_EFI_COCO_SECRET (thanks Greg KH). Selecting > CONFIG_EFI_SECRET=m (patch 3) will enable the EFI parts as well. > - Guard call to clflush_cache_range() with #ifdef CONFIG_X86 > (Reported-by: kernel test robot <lkp@xxxxxxxxx>) > > v3: https://lore.kernel.org/linux-coco/20211014130848.592611-1-dovmurik@xxxxxxxxxxxxx/ > v3 changes: > - Rename the module to efi_secret > - Remove the exporting of clean_cache_range > - Use clflush_cache_range in wipe_memory > - Document function wipe_memory > - Initialize efi.coco_secret to EFI_INVALID_TABLE_ADDR to correctly detect > when there's no secret area published in the EFI configuration tables > > v2: https://lore.kernel.org/linux-coco/20211007061838.1381129-1-dovmurik@xxxxxxxxxxxxx > v2 changes: > - Export clean_cache_range() > - When deleteing a secret, call clean_cache_range() after explicit_memzero > - Add Documentation/ABI/testing/securityfs-coco-sev_secret > > v1: https://lore.kernel.org/linux-coco/20210809190157.279332-1-dovmurik@xxxxxxxxxxxxx/ > > RFC: https://lore.kernel.org/linux-coco/20210628183431.953934-1-dovmurik@xxxxxxxxxxxxx/ > > > Dov Murik (5): > efi: Save location of EFI confidential computing area > efi/libstub: Reserve confidential computing secret area > virt: Add efi_secret module to expose confidential computing secrets > efi: Load efi_secret module if EFI secret area is populated > docs: security: Add coco/efi_secret documentation > > .../ABI/testing/securityfs-coco-efi_secret | 51 +++ > Documentation/security/coco/efi_secret.rst | 102 ++++++ > Documentation/security/coco/index.rst | 9 + > Documentation/security/index.rst | 1 + > arch/x86/platform/efi/efi.c | 3 + > drivers/firmware/efi/Kconfig | 16 + > drivers/firmware/efi/Makefile | 1 + > drivers/firmware/efi/coco.c | 58 +++ > drivers/firmware/efi/efi.c | 6 + > drivers/firmware/efi/libstub/x86-stub.c | 28 ++ > drivers/virt/Kconfig | 3 + > drivers/virt/Makefile | 1 + > drivers/virt/coco/efi_secret/Kconfig | 14 + > drivers/virt/coco/efi_secret/Makefile | 2 + > drivers/virt/coco/efi_secret/efi_secret.c | 337 ++++++++++++++++++ > include/linux/efi.h | 10 + > 16 files changed, 642 insertions(+) > create mode 100644 Documentation/ABI/testing/securityfs-coco-efi_secret > create mode 100644 Documentation/security/coco/efi_secret.rst > create mode 100644 Documentation/security/coco/index.rst > create mode 100644 drivers/firmware/efi/coco.c > create mode 100644 drivers/virt/coco/efi_secret/Kconfig > create mode 100644 drivers/virt/coco/efi_secret/Makefile > create mode 100644 drivers/virt/coco/efi_secret/efi_secret.c > > > base-commit: 42eb8fdac2fc5d62392dcfcf0253753e821a97b0