| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <98309335-1dac-f4c5-42a0-131af991b396@linux.ibm.com>
Date: Tue, 12 Apr 2022 14:18:32 +0300
From: Dov Murik <dovmurik@...ux.ibm.com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: linux-efi <linux-efi@...r.kernel.org>,
Borislav Petkov <bp@...e.de>,
Ashish Kalra <ashish.kalra@....com>,
Brijesh Singh <brijesh.singh@....com>,
Tom Lendacky <thomas.lendacky@....com>,
James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Andi Kleen <ak@...ux.intel.com>,
Greg KH <gregkh@...uxfoundation.org>,
Andrew Scull <ascull@...gle.com>,
Dave Hansen <dave.hansen@...el.com>,
"Dr. David Alan Gilbert" <dgilbert@...hat.com>,
Gerd Hoffmann <kraxel@...hat.com>,
Lenny Szubowicz <lszubowi@...hat.com>,
Peter Gonda <pgonda@...gle.com>,
Matthew Garrett <mjg59@...f.ucam.org>,
James Bottomley <jejb@...ux.ibm.com>,
Tobin Feldman-Fitzthum <tobin@...ux.ibm.com>,
Jim Cadden <jcadden@....com>,
Daniele Buono <dbuono@...ux.vnet.ibm.com>,
linux-coco@...ts.linux.dev, linux-security-module@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Dov Murik <dovmurik@...ux.ibm.com>
Subject: Re: [PATCH v9 0/4] Allow guest access to EFI confidential computing
secret area
On 12/04/2022 13:04, Ard Biesheuvel wrote:
> On Tue, 12 Apr 2022 at 12:03, Dov Murik <dovmurik@...ux.ibm.com> wrote:
>>
>>
>>
>> On 01/04/2022 0:56, 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 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 third 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:
>>>
>>> ...
>>> [ 0.000000] efi: EFI v2.70 by EDK II
>>> [ 0.000000] efi: CocoSecret=0x7f222680 SMBIOS=0x7f541000 ACPI=0x7f77e000 ACPI 2.0=0x7f77e014 MEMATTR=0x7ea16418
>>> ...
>>> [ 1.127627] Run /init as init process
>>> Loading, please wait...
>>> Starting version 245.4-4ubuntu3.15
>>> ...
>>> [ 0.763204] efi_secret efi_secret.0: Created 4 entries in securityfs secrets/coco
>>> ...
>>>
>>> # ls -la /sys/kernel/security/secrets/coco
>>> 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
>>>
>>> # hd /sys/kernel/security/secrets/coco/e6f5a162-d67f-4750-a67c-5d065f2a9910
>>> 00000000 74 68 65 73 65 2d 61 72 65 2d 74 68 65 2d 6b 61 |these-are-the-ka|
>>> 00000010 74 61 2d 73 65 63 72 65 74 73 00 01 02 03 04 05 |ta-secrets......|
>>> 00000020 06 07 |..|
>>> 00000022
>>>
>>> # rm /sys/kernel/security/secrets/coco/e6f5a162-d67f-4750-a67c-5d065f2a9910
>>>
>>> # ls -la /sys/kernel/security/secrets/coco
>>> 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
>>>
>>>
>>> ---
>>>
>>> v9 changes:
>>> - Change the module into a platform driver (thanks Ard)
>>> - Remove special auto-loading code in efi; instead register a platform
>>> device (udev will load the efi_secret module) (thanks Ard)
>>> - Change logging in the efi_secret module to dev_err() etc.
>>> - efi_secret: first check that the secret area header is valid; only then start
>>> creating securityfs dirs.
>>>
>>> v8: https://lore.kernel.org/linux-coco/20220228114254.1099945-1-dovmurik@linux.ibm.com/
>>> v8 changes:
>>> - Change path of filesystem to <securityfs>/secrets/coco and fix the
>>> documentation accordingly (Thanks Gerd, Matthew)
>>> - Remove patch 2/5 (of v7) because the latest OVMF release (edk2-stable202202)
>>> already contains the fix to mark the launch secret page as EFI_RESERVED_TYPE.
>>>
>>> v7: https://lore.kernel.org/linux-coco/20220201124413.1093099-1-dovmurik@linux.ibm.com/
>>> v7 changes:
>>> - Improve description of efi_secret module in Kconfig.
>>> - Fix sparse warnings on pointer address space mismatch
>>> (Reported-by: kernel test robot <lkp@...el.com>)
>>>
>>> v6: https://lore.kernel.org/linux-coco/20211129114251.3741721-1-dovmurik@linux.ibm.com/
>>> 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@linux.ibm.com/
>>> 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@linux.ibm.com/
>>> 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@...el.com>)
>>>
>>> v3: https://lore.kernel.org/linux-coco/20211014130848.592611-1-dovmurik@linux.ibm.com/
>>> 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@linux.ibm.com
>>> 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@linux.ibm.com/
>>>
>>> RFC: https://lore.kernel.org/linux-coco/20210628183431.953934-1-dovmurik@linux.ibm.com/
>>>
>>>
>>>
>>> Dov Murik (4):
>>> efi: Save location of EFI confidential computing area
>>> virt: Add efi_secret module to expose confidential computing secrets
>>> efi: Register efi_secret platform device if EFI secret area is
>>> declared
>>> docs: security: Add secrets/coco documentation
>>>
>>
>>
>> This series has Reviewed-by tags on all patches (though, as I mentioned,
>> there's a missing #ifdef in patch 3).
>>
>> Ard, are you going to take this through the EFI tree?
>>
>> Should I resend the series with the fix for patch 3?
>>
>
> Yes, please send a final version with all tags in place etc, and I
> will queue it up.
>
Great! Thank you, I'll do that shortly.
-Dov
Powered by blists - more mailing lists