Confidential computing 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.
Support for secret injection is already available in OVMF (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 copies the secrets from the EFI-provided memory to
kernel reserved memory, and optionally exposes them to userspace via
securityfs using a new sev_secret kernel module.
The first patch in efi/libstub copies the secret area from the EFI
memory to specially allocated memory; the second patch reserves that
memory block; and the third patch introduces the new sev_secret module
that exposes the content of the secret entries as securityfs files, and
allows clearing out secrets with a file unlink interface.
This has been tested with AMD SEV guests, but the kernel side of
handling the secret area has no SEV-specific dependencies, and therefore
should be usable for any confidential computing hardware that can
publish the secret area via the standard EFI config table entry.
Here is a simple example for usage of the sev_secret module in a guest to which
secrets were injected during launch:
# modprobe sev_secret
# ls -la /sys/kernel/security/sev_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/sev_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/sev_secret/e6f5a162-d67f-4750-a67c-5d065f2a9910
# ls -la /sys/kernel/security/sev_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
v2 changes:
- Add unlink support in sev_secret securityfs.
Dov Murik (3):
efi/libstub: Copy confidential computing secret area
efi: Reserve confidential computing secret area
virt: Add sev_secret module to expose confidential computing secrets
drivers/firmware/efi/Makefile | 2 +-
drivers/firmware/efi/confidential-computing.c | 41 +++
drivers/firmware/efi/efi.c | 5 +
drivers/firmware/efi/libstub/Makefile | 3 +-
.../efi/libstub/confidential-computing.c | 68 ++++
drivers/firmware/efi/libstub/efi-stub.c | 2 +
drivers/firmware/efi/libstub/efistub.h | 2 +
drivers/firmware/efi/libstub/x86-stub.c | 2 +
drivers/virt/Kconfig | 2 +
drivers/virt/Makefile | 1 +
drivers/virt/sev_secret/Kconfig | 11 +
drivers/virt/sev_secret/Makefile | 2 +
drivers/virt/sev_secret/sev_secret.c | 298 ++++++++++++++++++
include/linux/efi.h | 11 +
14 files changed, 448 insertions(+), 2 deletions(-)
create mode 100644 drivers/firmware/efi/confidential-computing.c
create mode 100644 drivers/firmware/efi/libstub/confidential-computing.c
create mode 100644 drivers/virt/sev_secret/Kconfig
create mode 100644 drivers/virt/sev_secret/Makefile
create mode 100644 drivers/virt/sev_secret/sev_secret.c
base-commit: 62fb9874f5da54fdb243003b386128037319b219
--
2.25.1
Confidential computing hardware such as AMD SEV (Secure Encrypted
Virtualization) allows a guest owner to inject secrets into the VMs
memory without the host/hypervisor being able to read them.
Firmware support for secret injection is available in OVMF, which
reserves a memory area for secret injection and includes a pointer to it
the in EFI config table entry
LINUX_EFI_CONFIDENTIAL_COMPUTING_SECRET_TABLE_GUID. However, OVMF
doesn't force the guest OS to keep this memory area reserved.
If EFI exposes such a table entry, efi/libstub will copy this area to a
reserved memory for future use inside the kernel.
A pointer to the new copy is kept in the EFI table under
LINUX_EFI_CONFIDENTIAL_COMPUTING_SECRET_AREA_GUID.
Signed-off-by: Dov Murik <redacted>
---
drivers/firmware/efi/libstub/Makefile | 3 +-
.../efi/libstub/confidential-computing.c | 68 +++++++++++++++++++
drivers/firmware/efi/libstub/efi-stub.c | 2 +
drivers/firmware/efi/libstub/efistub.h | 2 +
drivers/firmware/efi/libstub/x86-stub.c | 2 +
include/linux/efi.h | 7 ++
6 files changed, 83 insertions(+), 1 deletion(-)
create mode 100644 drivers/firmware/efi/libstub/confidential-computing.c
@@ -55,7 +55,8 @@ KCOV_INSTRUMENT := nlib-y:=efi-stub-helper.ogop.osecureboot.otpm.o\file.omem.orandom.orandomalloc.opci.o\skip_spaces.olib-cmdline.olib-ctype.o\-alignedmem.orelocate.ovsprintf.o+alignedmem.orelocate.ovsprintf.o\+confidential-computing.o# include the stub's generic dependencies from lib/ when building for ARM/arm64efi-deps-y:=fdt_rw.cfdt_ro.cfdt_wip.cfdt.cfdt_empty_tree.cfdt_sw.c
@@ -0,0 +1,68 @@+// SPDX-License-Identifier: GPL-2.0+/*+*Confidentialcomputingsecretareahandling+*+*Copyright(C)2021IBMCorporation+*Author:DovMurik<dovmurik@linux.ibm.com>+*/++#include<linux/efi.h>+#include<linux/sizes.h>+#include<asm/efi.h>++#include"efistub.h"++#define LINUX_EFI_CONFIDENTIAL_COMPUTING_SECRET_TABLE_GUID \+EFI_GUID(0xadf956ad,0xe98c,0x484c,0xae,0x11,0xb5,0x1c,0x7d,0x33,0x64,0x47)++/**+*structefi_confidential_computing_secret_table-EFIconfigtablethat+*pointstotheconfidentialcomputingsecretarea.Theguid+*LINUX_EFI_CONFIDENTIAL_COMPUTING_SECRET_TABLE_GUIDholdsthistable.+*@base:PhysicaladdressoftheEFIsecretarea+*@size:Size(inbytes)oftheEFIsecretarea+*/+structefi_confidential_computing_secret_table{+u64base;+u64size;+}__attribute((packed));++/*+*CreateacopyofEFI'sconfidentialcomputingsecretarea(ifavailable)so+*thatthesecretsareaccessibleinthekernelafterExitBootServices.+*/+voidefi_copy_confidential_computing_secret_area(void)+{+efi_guid_tlinux_secret_area_guid=LINUX_EFI_CONFIDENTIAL_COMPUTING_SECRET_AREA_GUID;+efi_status_tstatus;+structefi_confidential_computing_secret_table*secret_table;+structlinux_efi_confidential_computing_secret_area*secret_area;++secret_table=get_efi_config_table(LINUX_EFI_CONFIDENTIAL_COMPUTING_SECRET_TABLE_GUID);+if(!secret_table)+return;++if(secret_table->size==0||secret_table->size>=SZ_4G)+return;++/* Allocate space for the secret area and copy it */+status=efi_bs_call(allocate_pool,EFI_LOADER_DATA,+sizeof(*secret_area)+secret_table->size,(void**)&secret_area);++if(status!=EFI_SUCCESS){+efi_err("Unable to allocate memory for confidential computing secret area copy\n");+return;+}++secret_area->size=secret_table->size;+memcpy(secret_area->area,(void*)(unsignedlong)secret_table->base,secret_table->size);++status=efi_bs_call(install_configuration_table,&linux_secret_area_guid,secret_area);+if(status!=EFI_SUCCESS)+gotoerr_free;++return;++err_free:+efi_bs_call(free_pool,secret_area);+}
The new sev_secret module exposes the confidential computing secret area
via securityfs interface.
When the module is loaded (and securityfs is mounted, typically under
/sys/kernel/security), an "sev_secret" directory is created in
securityfs. In it, a file is created for each secret entry. The name
of each such file is the GUID of the secret entry, and its content is
the secret data.
This allows applications running in a confidential computing setting to
read secrets provided by the guest owner via a secure secret injection
mechanism (such as AMD SEV's LAUNCH_SECRET command).
Removing (unlinking) files in the "sev_secret" directory will zero out
the secret in memory, and remove the filesystem entry. If the module
is removed and loaded again, that secret will not appear in the
filesystem.
Signed-off-by: Dov Murik <redacted>
---
drivers/virt/Kconfig | 2 +
drivers/virt/Makefile | 1 +
drivers/virt/sev_secret/Kconfig | 11 +
drivers/virt/sev_secret/Makefile | 2 +
drivers/virt/sev_secret/sev_secret.c | 298 +++++++++++++++++++++++++++
5 files changed, 314 insertions(+)
create mode 100644 drivers/virt/sev_secret/Kconfig
create mode 100644 drivers/virt/sev_secret/Makefile
create mode 100644 drivers/virt/sev_secret/sev_secret.c
@@ -0,0 +1,298 @@+// SPDX-License-Identifier: GPL-2.0+/*+*sev_secretmodule+*+*Copyright(C)2021IBMCorporation+*Author:DovMurik<dovmurik@linux.ibm.com>+*/++#include<linux/seq_file.h>+#include<linux/fs.h>+#include<linux/kernel.h>+#include<linux/init.h>+#include<linux/module.h>+#include<linux/io.h>+#include<linux/security.h>+#include<linux/efi.h>++/**+*sev_secret:Allowreadingconfidentialcomputingsecretareaviasecurityfs+*interface.+*+*Whenthemoduleisloaded(andsecurityfsismounted,typicallyunder+*/sys/kernel/security),an"sev_secret"directoryiscreatedinsecurityfs.+*Init,afileiscreatedforeachsecretentry.Thenameofeachsuchfile+*istheGUIDofthesecretentry,anditscontentisthesecretdata.+*/++#define SEV_SECRET_NUM_FILES 64++#define EFI_SEVSECRET_TABLE_HEADER_GUID \+EFI_GUID(0x1e74f542,0x71dd,0x4d66,0x96,0x3e,0xef,0x42,0x87,0xff,0x17,0x3b)++structsev_secret{+structdentry*fs_dir;+structdentry*fs_files[SEV_SECRET_NUM_FILES];+structlinux_efi_confidential_computing_secret_area*secret_area;+};++/*+*StructureoftheSEVsecretarea+*+*OffsetLength+*(bytes)(bytes)Usage+*-------------------+*016SecrettableheaderGUID(mustbe1e74f542-71dd-4d66-963e-ef4287ff173b)+*164Lengthofbytesoftheentiresecretarea+*+*2016Firstsecretentry'sGUID+*364Firstsecretentry'slengthinbytes(=16+4+x)+*40xFirstsecretentry'sdata+*+*40+x16Secondsecretentry'sGUID+*56+x4Secondsecretentry'slengthinbytes(=16+4+y)+*60+xySecondsecretentry'sdata+*+*(...andsoonforadditionalentries)+*+*TheGUIDofeachsecretentrydesignatestheusageofthesecretdata.+*/++/**+*structsecret_header-Headerofentiresecretarea;thisshouldbefollowed+*byinstancesofstructsecret_entry.+*@guid:MustbeEFI_SEVSECRET_TABLE_HEADER_GUID+*@len:Lengthinbytesofentiresecretarea,includingheader+*/+structsecret_header{+efi_guid_tguid;+u32len;+}__attribute((packed));++/**+*structsecret_entry-Holdsonesecretentry+*@guid:Secret-specificGUID(orNULL_GUIDifthissecretentrywasdeleted)+*@len:Lengthofsecretentry,includingitsguidandlenfields+*@data:Thesecretdata(fullofzerosifthissecretentrywasdeleted)+*/+structsecret_entry{+efi_guid_tguid;+u32len;+u8data[];+}__attribute((packed));++staticsize_tsecret_entry_data_len(structsecret_entry*e)+{+returne->len-sizeof(*e);+}++staticstructsev_secretthe_sev_secret;++staticinlinestructsev_secret*sev_secret_get(void)+{+return&the_sev_secret;+}++staticintsev_secret_bin_file_show(structseq_file*file,void*data)+{+structsecret_entry*e=file->private;++if(e)+seq_write(file,e->data,secret_entry_data_len(e));++return0;+}+DEFINE_SHOW_ATTRIBUTE(sev_secret_bin_file);++staticintsev_secret_unlink(structinode*dir,structdentry*dentry)+{+structsev_secret*s=sev_secret_get();+structinode*inode=d_inode(dentry);+structsecret_entry*e=(structsecret_entry*)inode->i_private;+inti;++if(e){+/* Zero out the secret data */+memzero_explicit(e->data,secret_entry_data_len(e));+e->guid=NULL_GUID;+}++inode->i_private=NULL;++for(i=0;i<SEV_SECRET_NUM_FILES;i++)+if(s->fs_files[i]==dentry)+s->fs_files[i]=NULL;++/* securityfs_remove tries to lock the directory's inode, but we reach+*theunlinkcallbackwhenit'salreadylocked*/+inode_unlock(dir);+securityfs_remove(dentry);+inode_lock(dir);++return0;+}++staticconststructinode_operationssev_secret_dir_inode_operations={+.lookup=simple_lookup,+.unlink=sev_secret_unlink,+};++staticintsev_secret_map_area(void)+{+structsev_secret*s=sev_secret_get();+structlinux_efi_confidential_computing_secret_area*secret_area;+u32secret_area_size;++if(efi.confidential_computing_secret==EFI_INVALID_TABLE_ADDR){+pr_err("Secret area address is not available\n");+return-EINVAL;+}++secret_area=+memremap(efi.confidential_computing_secret,sizeof(*secret_area),MEMREMAP_WB);+if(secret_area==NULL){+pr_err("Could not map secret area header\n");+return-ENOMEM;+}++secret_area_size=sizeof(*secret_area)+secret_area->size;+memunmap(secret_area);++secret_area=memremap(efi.confidential_computing_secret,secret_area_size,MEMREMAP_WB);+if(secret_area==NULL){+pr_err("Could not map secret area\n");+return-ENOMEM;+}++s->secret_area=secret_area;+return0;+}++staticvoidsev_secret_securityfs_teardown(void)+{+structsev_secret*s=sev_secret_get();+inti;++for(i=(SEV_SECRET_NUM_FILES-1);i>=0;i--){+securityfs_remove(s->fs_files[i]);+s->fs_files[i]=NULL;+}++securityfs_remove(s->fs_dir);+s->fs_dir=NULL;++pr_debug("Removed sev_secret securityfs entries\n");+}++staticintsev_secret_securityfs_setup(void)+{+efi_guid_ttableheader_guid=EFI_SEVSECRET_TABLE_HEADER_GUID;+structsev_secret*s=sev_secret_get();+intret=0,i=0,bytes_left;+unsignedchar*ptr;+structsecret_header*h;+structsecret_entry*e;+structdentry*dent;+charguid_str[EFI_VARIABLE_GUID_LEN+1];++s->fs_dir=NULL;+memset(s->fs_files,0,sizeof(s->fs_files));++dent=securityfs_create_dir("sev_secret",NULL);+if(IS_ERR(dent)){+pr_err("Error creating SEV secret securityfs directory entry err=%ld",PTR_ERR(dent));+returnPTR_ERR(dent);+}+d_inode(dent)->i_op=&sev_secret_dir_inode_operations;+s->fs_dir=dent;++ptr=s->secret_area->area;+h=(structsecret_header*)ptr;+if(memcmp(&h->guid,&tableheader_guid,sizeof(h->guid))){+pr_err("SEV secret area does not start with correct GUID\n");+ret=-EINVAL;+gotoerr_cleanup;+}+if(h->len<sizeof(*h)){+pr_err("SEV secret area reported length is too small\n");+ret=-EINVAL;+gotoerr_cleanup;+}++bytes_left=h->len-sizeof(*h);+ptr+=sizeof(*h);+while(bytes_left>=(int)sizeof(*e)&&i<SEV_SECRET_NUM_FILES){+e=(structsecret_entry*)ptr;+if(e->len<sizeof(*e)||e->len>(unsignedint)bytes_left){+pr_err("SEV secret area is corrupted\n");+ret=-EINVAL;+gotoerr_cleanup;+}++/* Skip deleted entries (which will have NULL_GUID) */+if(efi_guidcmp(e->guid,NULL_GUID)){+efi_guid_to_str(&e->guid,guid_str);++dent=securityfs_create_file(guid_str,0440,s->fs_dir,(void*)e,+&sev_secret_bin_file_fops);+if(IS_ERR(dent)){+pr_err("Error creating SEV secret securityfs entry\n");+ret=PTR_ERR(dent);+gotoerr_cleanup;+}++s->fs_files[i++]=dent;+}+ptr+=e->len;+bytes_left-=e->len;+}++pr_debug("Created %d entries in sev_secret securityfs\n",i);+return0;++err_cleanup:+sev_secret_securityfs_teardown();+returnret;+}++staticvoidsev_secret_unmap_area(void)+{+structsev_secret*s=sev_secret_get();++if(s->secret_area){+memunmap(s->secret_area);+s->secret_area=NULL;+}+}++staticint__initsev_secret_init(void)+{+intret;++ret=sev_secret_map_area();+if(ret)+returnret;++ret=sev_secret_securityfs_setup();+if(ret)+gotoerr_unmap;++returnret;++err_unmap:+sev_secret_unmap_area();+returnret;+}++staticvoid__exitsev_secret_exit(void)+{+sev_secret_securityfs_teardown();+sev_secret_unmap_area();+}++module_init(sev_secret_init);+module_exit(sev_secret_exit);++MODULE_DESCRIPTION("AMD SEV confidential computing secret area access");+MODULE_AUTHOR("IBM");+MODULE_LICENSE("GPL");
Just a couple of notes below:
On Mon, Jun 28, 2021 at 06:34:28PM +0000, Dov Murik wrote:
Confidential computing 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.
Support for secret injection is already available in OVMF (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 copies the secrets from the EFI-provided memory to
kernel reserved memory, and optionally exposes them to userspace via
securityfs using a new sev_secret kernel module.
The first patch in efi/libstub copies the secret area from the EFI
memory to specially allocated memory; the second patch reserves that
memory block; and the third patch introduces the new sev_secret module
that exposes the content of the secret entries as securityfs files, and
allows clearing out secrets with a file unlink interface.
This has been tested with AMD SEV guests, but the kernel side of
handling the secret area has no SEV-specific dependencies, and therefore
should be usable for any confidential computing hardware that can
publish the secret area via the standard EFI config table entry.
Here is a simple example for usage of the sev_secret module in a guest to which
secrets were injected during launch:
That's all fine and good but I miss the "why" in this explanation. I.e.,
a proper use case of a guest owner providing those sekrits to the guest
would be good.
# modprobe sev_secret
# ls -la /sys/kernel/security/sev_secret/
So that sysfs URL becomes an ABI. Shouldn't this be:
/sys/kernel/security/coco/
instead which stands for "confidential computing" and contains all kinds
of protected guest things. TDX might wanna do something similar there,
for example.
Those "confidential-computing.c" filenames are too long. I'd vote for
coco.c.
Same for your naming: efi_copy_confidential_computing_secret_area() -
that is a wow and doesn't look like kernel code to me. :)
Another example why it is too long:
+ {LINUX_EFI_CONFIDENTIAL_COMPUTING_SECRET_AREA_GUID,
+ &efi.confidential_computing_secret,
+ "ConfCompSecret"},
I'd do
{ LINUX_EFI_COCO_SECRET_AREA_GUID, &efi.coco_secret, "ConfCompSecret" },
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
On Mon, Jun 28, 2021 at 06:34:31PM +0000, Dov Murik wrote:
The new sev_secret module exposes the confidential computing secret area
via securityfs interface.
When the module is loaded (and securityfs is mounted, typically under
/sys/kernel/security), an "sev_secret" directory is created in
securityfs. In it, a file is created for each secret entry. The name
of each such file is the GUID of the secret entry, and its content is
the secret data.
This allows applications running in a confidential computing setting to
read secrets provided by the guest owner via a secure secret injection
mechanism (such as AMD SEV's LAUNCH_SECRET command).
Removing (unlinking) files in the "sev_secret" directory will zero out
the secret in memory, and remove the filesystem entry. If the module
is removed and loaded again, that secret will not appear in the
filesystem.
Signed-off-by: Dov Murik <redacted>
---
drivers/virt/Kconfig | 2 +
drivers/virt/Makefile | 1 +
drivers/virt/sev_secret/Kconfig | 11 +
drivers/virt/sev_secret/Makefile | 2 +
drivers/virt/sev_secret/sev_secret.c | 298 +++++++++++++++++++++++++++
5 files changed, 314 insertions(+)
create mode 100644 drivers/virt/sev_secret/Kconfig
create mode 100644 drivers/virt/sev_secret/Makefile
create mode 100644 drivers/virt/sev_secret/sev_secret.c
Same question here: maybe have
drivers/virt/coco/
and put all coco guest stuff in there.
@@ -0,0 +1,11 @@+# SPDX-License-Identifier: GPL-2.0-only+configAMD_SEV_SECRET_SECURITYFS+tristate"AMD SEV secret area securityfs support"+depends onEFI
That probably needs to depend on CONFIG_AMD_MEM_ENCRYPT - otherwise
what's the point for it.
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
If there is any possibility that someone could reuse a form of this
confidential computing secret table in a bare metal system, then this
table needs to be added to the efi_tables[] array in
arch/x86/platform/efi/efi.c. Otherwise, it will be mapped improperly on a
system with SME active.
Thanks,
Tom
@@ -1190,6 +1192,8 @@ extern int efi_tpm_final_log_size; extern unsigned long rci2_table_phys;+extern int efi_confidential_computing_secret_area_reserve(void);+ /* * efi_runtime_service() function identifiers. * "NONE" is used by efi_recover_from_page_fault() to check if the page
If there is any possibility that someone could reuse a form of this
confidential computing secret table in a bare metal system, then this
table needs to be added to the efi_tables[] array in
arch/x86/platform/efi/efi.c. Otherwise, it will be mapped improperly on a
system with SME active.
Good catch, thanks. I see that all existing table addresses from
struct efi are added to the efi_tables[] array, so for completeness it
makes sense to add efi.confidential_computing_secret as well (even
though currently bare metal firmware doesn't have this table).
Thanks,
-Dov
@@ -1190,6 +1192,8 @@ extern int efi_tpm_final_log_size; extern unsigned long rci2_table_phys;+extern int efi_confidential_computing_secret_area_reserve(void);+ /* * efi_runtime_service() function identifiers. * "NONE" is used by efi_recover_from_page_fault() to check if the page
Hi Boris,
On 28/06/2021 22:28, Borislav Petkov wrote:
Just a couple of notes below:
On Mon, Jun 28, 2021 at 06:34:28PM +0000, Dov Murik wrote:
quoted
Confidential computing 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.
Support for secret injection is already available in OVMF (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 copies the secrets from the EFI-provided memory to
kernel reserved memory, and optionally exposes them to userspace via
securityfs using a new sev_secret kernel module.
The first patch in efi/libstub copies the secret area from the EFI
memory to specially allocated memory; the second patch reserves that
memory block; and the third patch introduces the new sev_secret module
that exposes the content of the secret entries as securityfs files, and
allows clearing out secrets with a file unlink interface.
This has been tested with AMD SEV guests, but the kernel side of
handling the secret area has no SEV-specific dependencies, and therefore
should be usable for any confidential computing hardware that can
publish the secret area via the standard EFI config table entry.
Here is a simple example for usage of the sev_secret module in a guest to which
secrets were injected during launch:
That's all fine and good but I miss the "why" in this explanation. I.e.,
a proper use case of a guest owner providing those sekrits to the guest
would be good.
OK, I'll add it in the cover letter; something along the lines of:
An example would be 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
sev_secret filesystem and proceeds to decrypt the files into memory and
then performs the needed computations on the content.
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.
quoted
# modprobe sev_secret
# ls -la /sys/kernel/security/sev_secret/
So that sysfs URL becomes an ABI. Shouldn't this be:
/sys/kernel/security/coco/
instead which stands for "confidential computing" and contains all kinds
of protected guest things. TDX might wanna do something similar there,
for example.
On one hand, I agree. This entire series has no SEV-specific code (but
I tested it only on SEV).
On the other hand, secret injection mechanisms in SEV-SNP and TDX are
different beasts than the one used here (SEV). In SEV the secrets must
be injected at VM launch time; so when OVMF runs and kernel efistub runs
the secrets are already there (patches 1+2). However, in SNP there's no
secret injection at launch; (/me hand-waving) the guest can securely
talk with the PSP hardware, check the attestation, and if OK then
securely contact some Guest Owner secret provider to get the required
secrets. Not sure it makes sense for the kernel to be part of this
"getting secrets from secret provider and exposing them in securityfs".
So maybe for regular SEV we'll use this sev_secret module to get one
secret which will allow the guest to contact to the Guest Owner secret
provider (and from here continue like SNP or TDX). Brijesh (AMD) also
suggested collapsing the proposed sev_secret module into the new
sev-guest module ("[PATCH Part1 RFC v3 22/22] virt: Add SEV-SNP guest
driver", sent 2021-06-02), and the logic suggested here will be used
when SNP is not active.
Or taking a step back: Maybe the kernel should not try to unify
SEV/SEV-SNP/TDX/PEF/s390x-SE. Each should have its own API. A
userspace process will have to understand what is available and get the
required info to run the application in a confidential environment.
Or maybe we can find an API that fits all these confidential computing
mechanisms and expose a unified API that hides the underlying
implementation.
(I'm not really sure - that's the reason this is an RFC series.)
Those "confidential-computing.c" filenames are too long. I'd vote for
coco.c.
When I wrote this I didn't yet encounter "coco" as an abbreviation. Now
there's a linux-coco mailing list, but I saw no other mentions of it in
the kernel (as an abbreviation for confidential computing).
I agree that the full term is too long; I considered conf-comp (but in
my mind "conf" is short for "configuration"). I used it in one place:
"ConfCompSecret" in patch 2/3.
If as a community we settle on coco / CoCo / COCO then I agree these
should be renamed.
(in QEMU they use CGS = Confidential Guest Support [1].)
[1]
https://lore.kernel.org/qemu-devel/20210202041315.196530-3-david@gibson.dropbear.id.au/
Same for your naming: efi_copy_confidential_computing_secret_area() -
that is a wow and doesn't look like kernel code to me. :)
Another example why it is too long:
+ {LINUX_EFI_CONFIDENTIAL_COMPUTING_SECRET_AREA_GUID,
+ &efi.confidential_computing_secret,
+ "ConfCompSecret"},
I'd do
{ LINUX_EFI_COCO_SECRET_AREA_GUID, &efi.coco_secret, "ConfCompSecret" },
On Mon, Jun 28, 2021 at 06:34:31PM +0000, Dov Murik wrote:
quoted
The new sev_secret module exposes the confidential computing secret area
via securityfs interface.
When the module is loaded (and securityfs is mounted, typically under
/sys/kernel/security), an "sev_secret" directory is created in
securityfs. In it, a file is created for each secret entry. The name
of each such file is the GUID of the secret entry, and its content is
the secret data.
This allows applications running in a confidential computing setting to
read secrets provided by the guest owner via a secure secret injection
mechanism (such as AMD SEV's LAUNCH_SECRET command).
Removing (unlinking) files in the "sev_secret" directory will zero out
the secret in memory, and remove the filesystem entry. If the module
is removed and loaded again, that secret will not appear in the
filesystem.
Signed-off-by: Dov Murik <redacted>
---
drivers/virt/Kconfig | 2 +
drivers/virt/Makefile | 1 +
drivers/virt/sev_secret/Kconfig | 11 +
drivers/virt/sev_secret/Makefile | 2 +
drivers/virt/sev_secret/sev_secret.c | 298 +++++++++++++++++++++++++++
5 files changed, 314 insertions(+)
create mode 100644 drivers/virt/sev_secret/Kconfig
create mode 100644 drivers/virt/sev_secret/Makefile
create mode 100644 drivers/virt/sev_secret/sev_secret.c
Same question here: maybe have
drivers/virt/coco/
and put all coco guest stuff in there.
I agree, according to what comes up of the conversation we have in
replies to the cover letter.
@@ -0,0 +1,11 @@+# SPDX-License-Identifier: GPL-2.0-only+configAMD_SEV_SECRET_SECURITYFS+tristate"AMD SEV secret area securityfs support"+depends onEFI
That probably needs to depend on CONFIG_AMD_MEM_ENCRYPT - otherwise
what's the point for it.
But not if it's a generic driver that is useful for other confidential
computing implementations. Consider some non-encrypting guest memory
isolation mechanism where the host can't read most guest pages; this
module might be useful there too.
Also, isn't it a bit weird to depend on CONFIG_AMD_MEM_ENCRYPT but not
use any of its APIs?
-Dov
On Tue, Jun 29, 2021 at 10:16:22AM +0300, Dov Murik wrote:
OK, I'll add it in the cover letter; something along the lines of:
An example would be 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
sev_secret filesystem and proceeds to decrypt the files into memory and
then performs the needed computations on the content.
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.
Yap, much better, thanks!
And that whole deal with the providing the secret this way is because
you want to be starting the same guest image in the cloud over and over
again but each guest owner would have their own decryption key which
they would supply this way.
Yap, good.
On one hand, I agree. This entire series has no SEV-specific code (but
I tested it only on SEV).
On the other hand, secret injection mechanisms in SEV-SNP and TDX are
different beasts than the one used here (SEV). In SEV the secrets must
be injected at VM launch time; so when OVMF runs and kernel efistub runs
the secrets are already there (patches 1+2). However, in SNP there's no
secret injection at launch; (/me hand-waving) the guest can securely
talk with the PSP hardware, check the attestation, and if OK then
securely contact some Guest Owner secret provider to get the required
secrets. Not sure it makes sense for the kernel to be part of this
"getting secrets from secret provider and exposing them in securityfs".
Which begs the question: why are you even doing this for only SEV
instead of supporting SEV-SNP/TDX only?
I'm under the impression that people should run only SNP and the
equivalent of that in TDX, guests but not those earlier technologies
which are lacking in some situations.
So maybe for regular SEV we'll use this sev_secret module to get one
secret which will allow the guest to contact to the Guest Owner secret
provider (and from here continue like SNP or TDX). Brijesh (AMD) also
suggested collapsing the proposed sev_secret module into the new
sev-guest module ("[PATCH Part1 RFC v3 22/22] virt: Add SEV-SNP guest
driver", sent 2021-06-02),
Which reminds me - I still need to take a look at that one.
and the logic suggested here will be used when SNP is not active.
Or taking a step back: Maybe the kernel should not try to unify
SEV/SEV-SNP/TDX/PEF/s390x-SE. Each should have its own API. A
userspace process will have to understand what is available and get the
required info to run the application in a confidential environment.
Or maybe we can find an API that fits all these confidential computing
mechanisms and expose a unified API that hides the underlying
implementation.
(I'm not really sure - that's the reason this is an RFC series.)
I'm gravitating towards a common API so that userspace doesn't have to
care. But that comes at the price of having to define that API properly
so that it fits them all. And we all know how that bikeshedding works.
:-\
When I wrote this I didn't yet encounter "coco" as an abbreviation. Now
there's a linux-coco mailing list, but I saw no other mentions of it in
the kernel (as an abbreviation for confidential computing).
That's what Joerg and me came up with - "coco" :-)
I agree that the full term is too long; I considered conf-comp (but in
my mind "conf" is short for "configuration"). I used it in one place:
"ConfCompSecret" in patch 2/3.
If as a community we settle on coco / CoCo / COCO then I agree these
should be renamed.
(in QEMU they use CGS = Confidential Guest Support [1].)
That's not bad too.
Thx.
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
On Tue, Jun 29, 2021 at 10:23:49AM +0300, Dov Murik wrote:
But not if it's a generic driver that is useful for other confidential
computing implementations. Consider some non-encrypting guest memory
isolation mechanism where the host can't read most guest pages; this
module might be useful there too.
Anything concrete or just hypothetical?
In any case, if this thing is generic, it should not have "AMD" and
"SEV" in the strings.
Also, isn't it a bit weird to depend on CONFIG_AMD_MEM_ENCRYPT but not
use any of its APIs?
Yeah, see above.
Thx.
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg