linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH v2 0/3] Allow access to confidential computing secret area
@ 2021-06-28 18:34 Dov Murik
  2021-06-28 18:34 ` [RFC PATCH v2 1/3] efi/libstub: Copy " Dov Murik
                   ` (3 more replies)
  0 siblings, 4 replies; 12+ messages in thread
From: Dov Murik @ 2021-06-28 18:34 UTC (permalink / raw)
  To: linux-efi
  Cc: Dov Murik, Laszlo Ersek, Ashish Kalra, Brijesh Singh,
	Tom Lendacky, Ard Biesheuvel, James Morris, Serge E. Hallyn,
	Andi Kleen, Dr. David Alan Gilbert, James Bottomley,
	Tobin Feldman-Fitzthum, Jim Cadden, linux-coco,
	linux-security-module, linux-kernel

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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [RFC PATCH v2 1/3] efi/libstub: Copy confidential computing secret area
  2021-06-28 18:34 [RFC PATCH v2 0/3] Allow access to confidential computing secret area Dov Murik
@ 2021-06-28 18:34 ` Dov Murik
  2021-06-28 18:34 ` [RFC PATCH v2 2/3] efi: Reserve " Dov Murik
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 12+ messages in thread
From: Dov Murik @ 2021-06-28 18:34 UTC (permalink / raw)
  To: linux-efi
  Cc: Dov Murik, Laszlo Ersek, Ashish Kalra, Brijesh Singh,
	Tom Lendacky, Ard Biesheuvel, James Morris, Serge E. Hallyn,
	Andi Kleen, Dr. David Alan Gilbert, James Bottomley,
	Tobin Feldman-Fitzthum, Jim Cadden, linux-coco,
	linux-security-module, linux-kernel

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 <dovmurik@linux.ibm.com>
---
 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

diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index d0537573501e..938ed23dd135 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -55,7 +55,8 @@ KCOV_INSTRUMENT			:= n
 lib-y				:= efi-stub-helper.o gop.o secureboot.o tpm.o \
 				   file.o mem.o random.o randomalloc.o pci.o \
 				   skip_spaces.o lib-cmdline.o lib-ctype.o \
-				   alignedmem.o relocate.o vsprintf.o
+				   alignedmem.o relocate.o vsprintf.o \
+				   confidential-computing.o
 
 # include the stub's generic dependencies from lib/ when building for ARM/arm64
 efi-deps-y := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c
diff --git a/drivers/firmware/efi/libstub/confidential-computing.c b/drivers/firmware/efi/libstub/confidential-computing.c
new file mode 100644
index 000000000000..96b97ff5d503
--- /dev/null
+++ b/drivers/firmware/efi/libstub/confidential-computing.c
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Confidential computing secret area handling
+ *
+ * Copyright (C) 2021 IBM Corporation
+ * Author: Dov Murik <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)
+
+/**
+ * struct efi_confidential_computing_secret_table - EFI config table that
+ * points to the confidential computing secret area. The guid
+ * LINUX_EFI_CONFIDENTIAL_COMPUTING_SECRET_TABLE_GUID holds this table.
+ * @base:	Physical address of the EFI secret area
+ * @size:	Size (in bytes) of the EFI secret area
+ */
+struct efi_confidential_computing_secret_table {
+	u64 base;
+	u64 size;
+} __attribute((packed));
+
+/*
+ * Create a copy of EFI's confidential computing secret area (if available) so
+ * that the secrets are accessible in the kernel after ExitBootServices.
+ */
+void efi_copy_confidential_computing_secret_area(void)
+{
+	efi_guid_t linux_secret_area_guid = LINUX_EFI_CONFIDENTIAL_COMPUTING_SECRET_AREA_GUID;
+	efi_status_t status;
+	struct efi_confidential_computing_secret_table *secret_table;
+	struct linux_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 *)(unsigned long)secret_table->base, secret_table->size);
+
+	status = efi_bs_call(install_configuration_table, &linux_secret_area_guid, secret_area);
+	if (status != EFI_SUCCESS)
+		goto err_free;
+
+	return;
+
+err_free:
+	efi_bs_call(free_pool, secret_area);
+}
diff --git a/drivers/firmware/efi/libstub/efi-stub.c b/drivers/firmware/efi/libstub/efi-stub.c
index 26e69788f27a..56bcd94a387e 100644
--- a/drivers/firmware/efi/libstub/efi-stub.c
+++ b/drivers/firmware/efi/libstub/efi-stub.c
@@ -205,6 +205,8 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 
 	efi_retrieve_tpm2_eventlog();
 
+	efi_copy_confidential_computing_secret_area();
+
 	/* Ask the firmware to clear memory on unclean shutdown */
 	efi_enable_reset_attack_mitigation();
 
diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index cde0a2ef507d..1c02658042ea 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -858,4 +858,6 @@ efi_enable_reset_attack_mitigation(void) { }
 
 void efi_retrieve_tpm2_eventlog(void);
 
+void efi_copy_confidential_computing_secret_area(void);
+
 #endif
diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index f14c4ff5839f..c663bf47370a 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -793,6 +793,8 @@ unsigned long efi_main(efi_handle_t handle,
 
 	efi_retrieve_tpm2_eventlog();
 
+	efi_copy_confidential_computing_secret_area();
+
 	setup_graphics(boot_params);
 
 	setup_efi_pci(boot_params);
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 6b5d36babfcc..4f647f1ee298 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -359,6 +359,8 @@ void efi_native_runtime_setup(void);
 #define LINUX_EFI_MEMRESERVE_TABLE_GUID		EFI_GUID(0x888eb0c6, 0x8ede, 0x4ff5,  0xa8, 0xf0, 0x9a, 0xee, 0x5c, 0xb9, 0x77, 0xc2)
 #define LINUX_EFI_INITRD_MEDIA_GUID		EFI_GUID(0x5568e427, 0x68fc, 0x4f3d,  0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68)
 #define LINUX_EFI_MOK_VARIABLE_TABLE_GUID	EFI_GUID(0xc451ed2b, 0x9694, 0x45d3,  0xba, 0xba, 0xed, 0x9f, 0x89, 0x88, 0xa3, 0x89)
+#define LINUX_EFI_CONFIDENTIAL_COMPUTING_SECRET_AREA_GUID \
+						EFI_GUID(0x940ed1e9, 0xd3da, 0x408b,  0xb3, 0x07, 0xe3, 0x2d, 0x25, 0x4a, 0x65, 0x16)
 
 /* OEM GUIDs */
 #define DELLEMC_EFI_RCI2_TABLE_GUID		EFI_GUID(0x2d9f28a2, 0xa886, 0x456a,  0x97, 0xa8, 0xf1, 0x1e, 0xf2, 0x4f, 0xf4, 0x55)
@@ -1282,4 +1284,9 @@ static inline struct efi_mokvar_table_entry *efi_mokvar_entry_find(
 }
 #endif
 
+struct linux_efi_confidential_computing_secret_area {
+	u32	size;
+	u8	area[];
+};
+
 #endif /* _LINUX_EFI_H */
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* [RFC PATCH v2 2/3] efi: Reserve confidential computing secret area
  2021-06-28 18:34 [RFC PATCH v2 0/3] Allow access to confidential computing secret area Dov Murik
  2021-06-28 18:34 ` [RFC PATCH v2 1/3] efi/libstub: Copy " Dov Murik
@ 2021-06-28 18:34 ` Dov Murik
  2021-06-28 20:40   ` Tom Lendacky
  2021-06-28 18:34 ` [RFC PATCH v2 3/3] virt: Add sev_secret module to expose confidential computing secrets Dov Murik
  2021-06-28 19:28 ` [RFC PATCH v2 0/3] Allow access to confidential computing secret area Borislav Petkov
  3 siblings, 1 reply; 12+ messages in thread
From: Dov Murik @ 2021-06-28 18:34 UTC (permalink / raw)
  To: linux-efi
  Cc: Dov Murik, Laszlo Ersek, Ashish Kalra, Brijesh Singh,
	Tom Lendacky, Ard Biesheuvel, James Morris, Serge E. Hallyn,
	Andi Kleen, Dr. David Alan Gilbert, James Bottomley,
	Tobin Feldman-Fitzthum, Jim Cadden, linux-coco,
	linux-security-module, linux-kernel

When efi-stub copies an EFI-provided confidential computing secret area,
reserve that memory block for future use within the kernel.

Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
---
 drivers/firmware/efi/Makefile                 |  2 +-
 drivers/firmware/efi/confidential-computing.c | 41 +++++++++++++++++++
 drivers/firmware/efi/efi.c                    |  5 +++
 include/linux/efi.h                           |  4 ++
 4 files changed, 51 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/efi/confidential-computing.c

diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 467e94259679..63f21f7351da 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -12,7 +12,7 @@ KASAN_SANITIZE_runtime-wrappers.o	:= n
 
 obj-$(CONFIG_ACPI_BGRT) 		+= efi-bgrt.o
 obj-$(CONFIG_EFI)			+= efi.o vars.o reboot.o memattr.o tpm.o
-obj-$(CONFIG_EFI)			+= memmap.o
+obj-$(CONFIG_EFI)			+= memmap.o confidential-computing.o
 ifneq ($(CONFIG_EFI_CAPSULE_LOADER),)
 obj-$(CONFIG_EFI)			+= capsule.o
 endif
diff --git a/drivers/firmware/efi/confidential-computing.c b/drivers/firmware/efi/confidential-computing.c
new file mode 100644
index 000000000000..e6bb4d1e8f17
--- /dev/null
+++ b/drivers/firmware/efi/confidential-computing.c
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Confidential computing secret area handling
+ *
+ * Copyright (C) 2021 IBM Corporation
+ * Author: Dov Murik <dovmurik@linux.ibm.com>
+ */
+
+#define pr_fmt(fmt) "efi: " fmt
+
+#include <linux/efi.h>
+#include <linux/init.h>
+#include <linux/memblock.h>
+#include <asm/early_ioremap.h>
+
+/*
+ * Reserve the confidential computing secret area memory
+ */
+int __init efi_confidential_computing_secret_area_reserve(void)
+{
+	struct linux_efi_confidential_computing_secret_area *secret_area;
+	unsigned long secret_area_size;
+
+	if (efi.confidential_computing_secret == EFI_INVALID_TABLE_ADDR)
+		return 0;
+
+	secret_area = early_memremap(efi.confidential_computing_secret, sizeof(*secret_area));
+	if (!secret_area) {
+		pr_err("Failed to map confidential computing secret area\n");
+		efi.confidential_computing_secret = EFI_INVALID_TABLE_ADDR;
+		return -ENOMEM;
+	}
+
+	secret_area_size = sizeof(*secret_area) + secret_area->size;
+	memblock_reserve(efi.confidential_computing_secret, secret_area_size);
+
+	pr_info("Reserved memory of EFI-provided confidential computing secret area");
+
+	early_memunmap(secret_area, sizeof(*secret_area));
+	return 0;
+}
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 4b7ee3fa9224..da36333e5c9f 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -526,6 +526,9 @@ static const efi_config_table_type_t common_tables[] __initconst = {
 #ifdef CONFIG_LOAD_UEFI_KEYS
 	{LINUX_EFI_MOK_VARIABLE_TABLE_GUID,	&efi.mokvar_table,	"MOKvar"	},
 #endif
+	{LINUX_EFI_CONFIDENTIAL_COMPUTING_SECRET_AREA_GUID,
+						&efi.confidential_computing_secret,
+									"ConfCompSecret"},
 	{},
 };
 
@@ -613,6 +616,8 @@ int __init efi_config_parse_tables(const efi_config_table_t *config_tables,
 
 	efi_tpm_eventlog_init();
 
+	efi_confidential_computing_secret_area_reserve();
+
 	if (mem_reserve != EFI_INVALID_TABLE_ADDR) {
 		unsigned long prsv = mem_reserve;
 
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 4f647f1ee298..e9740bd16db0 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -551,6 +551,8 @@ extern struct efi {
 	unsigned long			tpm_log;		/* TPM2 Event Log table */
 	unsigned long			tpm_final_log;		/* TPM2 Final Events Log table */
 	unsigned long			mokvar_table;		/* MOK variable config table */
+	unsigned long			confidential_computing_secret;	/* Confidential computing */
+									/* secret table           */
 
 	efi_get_time_t			*get_time;
 	efi_set_time_t			*set_time;
@@ -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
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* [RFC PATCH v2 3/3] virt: Add sev_secret module to expose confidential computing secrets
  2021-06-28 18:34 [RFC PATCH v2 0/3] Allow access to confidential computing secret area Dov Murik
  2021-06-28 18:34 ` [RFC PATCH v2 1/3] efi/libstub: Copy " Dov Murik
  2021-06-28 18:34 ` [RFC PATCH v2 2/3] efi: Reserve " Dov Murik
@ 2021-06-28 18:34 ` Dov Murik
  2021-06-28 19:30   ` Borislav Petkov
  2021-06-28 19:28 ` [RFC PATCH v2 0/3] Allow access to confidential computing secret area Borislav Petkov
  3 siblings, 1 reply; 12+ messages in thread
From: Dov Murik @ 2021-06-28 18:34 UTC (permalink / raw)
  To: linux-efi
  Cc: Dov Murik, Laszlo Ersek, Ashish Kalra, Brijesh Singh,
	Tom Lendacky, Ard Biesheuvel, James Morris, Serge E. Hallyn,
	Andi Kleen, Dr. David Alan Gilbert, James Bottomley,
	Tobin Feldman-Fitzthum, Jim Cadden, linux-coco,
	linux-security-module, linux-kernel

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 <dovmurik@linux.ibm.com>
---
 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

diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
index 8061e8ef449f..c222cc625891 100644
--- a/drivers/virt/Kconfig
+++ b/drivers/virt/Kconfig
@@ -36,4 +36,6 @@ source "drivers/virt/vboxguest/Kconfig"
 source "drivers/virt/nitro_enclaves/Kconfig"
 
 source "drivers/virt/acrn/Kconfig"
+
+source "drivers/virt/sev_secret/Kconfig"
 endif
diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile
index 3e272ea60cd9..0765e5418d1d 100644
--- a/drivers/virt/Makefile
+++ b/drivers/virt/Makefile
@@ -8,3 +8,4 @@ obj-y				+= vboxguest/
 
 obj-$(CONFIG_NITRO_ENCLAVES)	+= nitro_enclaves/
 obj-$(CONFIG_ACRN_HSM)		+= acrn/
+obj-y				+= sev_secret/
diff --git a/drivers/virt/sev_secret/Kconfig b/drivers/virt/sev_secret/Kconfig
new file mode 100644
index 000000000000..4505526b8ef1
--- /dev/null
+++ b/drivers/virt/sev_secret/Kconfig
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config AMD_SEV_SECRET_SECURITYFS
+	tristate "AMD SEV secret area securityfs support"
+	depends on EFI
+	select SECURITYFS
+	help
+	  This is a driver for accessing the AMD SEV secret area via
+	  securityfs.
+
+	  To compile this driver as a module, choose M here.
+	  The module will be called sev_secret.
diff --git a/drivers/virt/sev_secret/Makefile b/drivers/virt/sev_secret/Makefile
new file mode 100644
index 000000000000..9671f7bb3941
--- /dev/null
+++ b/drivers/virt/sev_secret/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_AMD_SEV_SECRET_SECURITYFS) += sev_secret.o
diff --git a/drivers/virt/sev_secret/sev_secret.c b/drivers/virt/sev_secret/sev_secret.c
new file mode 100644
index 000000000000..11a2d41f4711
--- /dev/null
+++ b/drivers/virt/sev_secret/sev_secret.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * sev_secret module
+ *
+ * Copyright (C) 2021 IBM Corporation
+ * Author: Dov Murik <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: Allow reading 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.
+ */
+
+#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)
+
+struct sev_secret {
+	struct dentry *fs_dir;
+	struct dentry *fs_files[SEV_SECRET_NUM_FILES];
+	struct linux_efi_confidential_computing_secret_area *secret_area;
+};
+
+/*
+ * Structure of the SEV 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.
+ */
+
+/**
+ * struct secret_header - Header of entire secret area; this should be followed
+ * by instances of struct secret_entry.
+ * @guid:	Must be EFI_SEVSECRET_TABLE_HEADER_GUID
+ * @len:	Length in bytes of entire secret area, including header
+ */
+struct secret_header {
+	efi_guid_t guid;
+	u32 len;
+} __attribute((packed));
+
+/**
+ * struct secret_entry - Holds one secret entry
+ * @guid:	Secret-specific GUID (or NULL_GUID if this secret entry was deleted)
+ * @len:	Length of secret entry, including its guid and len fields
+ * @data:	The secret data (full of zeros if this secret entry was deleted)
+ */
+struct secret_entry {
+	efi_guid_t guid;
+	u32 len;
+	u8 data[];
+} __attribute((packed));
+
+static size_t secret_entry_data_len(struct secret_entry *e)
+{
+	return e->len - sizeof(*e);
+}
+
+static struct sev_secret the_sev_secret;
+
+static inline struct sev_secret *sev_secret_get(void)
+{
+	return &the_sev_secret;
+}
+
+static int sev_secret_bin_file_show(struct seq_file *file, void *data)
+{
+	struct secret_entry *e = file->private;
+
+	if (e)
+		seq_write(file, e->data, secret_entry_data_len(e));
+
+	return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(sev_secret_bin_file);
+
+static int sev_secret_unlink(struct inode *dir, struct dentry *dentry)
+{
+	struct sev_secret *s = sev_secret_get();
+	struct inode *inode = d_inode(dentry);
+	struct secret_entry *e = (struct secret_entry *)inode->i_private;
+        int i;
+
+        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
+         * the unlink callback when it's already locked */
+	inode_unlock(dir);
+	securityfs_remove(dentry);
+	inode_lock(dir);
+
+	return 0;
+}
+
+static const struct inode_operations sev_secret_dir_inode_operations = {
+	.lookup         = simple_lookup,
+	.unlink         = sev_secret_unlink,
+};
+
+static int sev_secret_map_area(void)
+{
+	struct sev_secret *s = sev_secret_get();
+	struct linux_efi_confidential_computing_secret_area *secret_area;
+	u32 secret_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;
+	return 0;
+}
+
+static void sev_secret_securityfs_teardown(void)
+{
+	struct sev_secret *s = sev_secret_get();
+	int i;
+
+	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");
+}
+
+static int sev_secret_securityfs_setup(void)
+{
+	efi_guid_t tableheader_guid = EFI_SEVSECRET_TABLE_HEADER_GUID;
+	struct sev_secret *s = sev_secret_get();
+	int ret = 0, i = 0, bytes_left;
+	unsigned char *ptr;
+	struct secret_header *h;
+	struct secret_entry *e;
+	struct dentry *dent;
+	char guid_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));
+		return PTR_ERR(dent);
+	}
+	d_inode(dent)->i_op = &sev_secret_dir_inode_operations;
+	s->fs_dir = dent;
+
+	ptr = s->secret_area->area;
+	h = (struct secret_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;
+		goto err_cleanup;
+	}
+	if (h->len < sizeof(*h)) {
+		pr_err("SEV secret area reported length is too small\n");
+		ret = -EINVAL;
+		goto err_cleanup;
+	}
+
+	bytes_left = h->len - sizeof(*h);
+	ptr += sizeof(*h);
+	while (bytes_left >= (int)sizeof(*e) && i < SEV_SECRET_NUM_FILES) {
+		e = (struct secret_entry *)ptr;
+		if (e->len < sizeof(*e) || e->len > (unsigned int)bytes_left) {
+			pr_err("SEV secret area is corrupted\n");
+			ret = -EINVAL;
+			goto err_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);
+				goto err_cleanup;
+			}
+
+			s->fs_files[i++] = dent;
+		}
+		ptr += e->len;
+		bytes_left -= e->len;
+	}
+
+	pr_debug("Created %d entries in sev_secret securityfs\n", i);
+	return 0;
+
+err_cleanup:
+	sev_secret_securityfs_teardown();
+	return ret;
+}
+
+static void sev_secret_unmap_area(void)
+{
+	struct sev_secret *s = sev_secret_get();
+
+	if (s->secret_area) {
+		memunmap(s->secret_area);
+		s->secret_area = NULL;
+	}
+}
+
+static int __init sev_secret_init(void)
+{
+	int ret;
+
+	ret = sev_secret_map_area();
+	if (ret)
+		return ret;
+
+	ret = sev_secret_securityfs_setup();
+	if (ret)
+		goto err_unmap;
+
+	return ret;
+
+err_unmap:
+	sev_secret_unmap_area();
+	return ret;
+}
+
+static void __exit sev_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");
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH v2 0/3] Allow access to confidential computing secret area
  2021-06-28 18:34 [RFC PATCH v2 0/3] Allow access to confidential computing secret area Dov Murik
                   ` (2 preceding siblings ...)
  2021-06-28 18:34 ` [RFC PATCH v2 3/3] virt: Add sev_secret module to expose confidential computing secrets Dov Murik
@ 2021-06-28 19:28 ` Borislav Petkov
  2021-06-29  7:16   ` Dov Murik
  3 siblings, 1 reply; 12+ messages in thread
From: Borislav Petkov @ 2021-06-28 19:28 UTC (permalink / raw)
  To: Dov Murik
  Cc: linux-efi, Laszlo Ersek, Ashish Kalra, Brijesh Singh,
	Tom Lendacky, Ard Biesheuvel, James Morris, Serge E. Hallyn,
	Andi Kleen, Dr. David Alan Gilbert, James Bottomley,
	Tobin Feldman-Fitzthum, Jim Cadden, linux-coco,
	linux-security-module, linux-kernel

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.

> 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

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH v2 3/3] virt: Add sev_secret module to expose confidential computing secrets
  2021-06-28 18:34 ` [RFC PATCH v2 3/3] virt: Add sev_secret module to expose confidential computing secrets Dov Murik
@ 2021-06-28 19:30   ` Borislav Petkov
  2021-06-29  7:23     ` Dov Murik
  0 siblings, 1 reply; 12+ messages in thread
From: Borislav Petkov @ 2021-06-28 19:30 UTC (permalink / raw)
  To: Dov Murik
  Cc: linux-efi, Laszlo Ersek, Ashish Kalra, Brijesh Singh,
	Tom Lendacky, Ard Biesheuvel, James Morris, Serge E. Hallyn,
	Andi Kleen, Dr. David Alan Gilbert, James Bottomley,
	Tobin Feldman-Fitzthum, Jim Cadden, linux-coco,
	linux-security-module, linux-kernel

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 <dovmurik@linux.ibm.com>
> ---
>  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.

> diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
> index 8061e8ef449f..c222cc625891 100644
> --- a/drivers/virt/Kconfig
> +++ b/drivers/virt/Kconfig
> @@ -36,4 +36,6 @@ source "drivers/virt/vboxguest/Kconfig"
>  source "drivers/virt/nitro_enclaves/Kconfig"
>  
>  source "drivers/virt/acrn/Kconfig"
> +
> +source "drivers/virt/sev_secret/Kconfig"
>  endif
> diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile
> index 3e272ea60cd9..0765e5418d1d 100644
> --- a/drivers/virt/Makefile
> +++ b/drivers/virt/Makefile
> @@ -8,3 +8,4 @@ obj-y				+= vboxguest/
>  
>  obj-$(CONFIG_NITRO_ENCLAVES)	+= nitro_enclaves/
>  obj-$(CONFIG_ACRN_HSM)		+= acrn/
> +obj-y				+= sev_secret/
> diff --git a/drivers/virt/sev_secret/Kconfig b/drivers/virt/sev_secret/Kconfig
> new file mode 100644
> index 000000000000..4505526b8ef1
> --- /dev/null
> +++ b/drivers/virt/sev_secret/Kconfig
> @@ -0,0 +1,11 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config AMD_SEV_SECRET_SECURITYFS
> +	tristate "AMD SEV secret area securityfs support"
> +	depends on EFI

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH v2 2/3] efi: Reserve confidential computing secret area
  2021-06-28 18:34 ` [RFC PATCH v2 2/3] efi: Reserve " Dov Murik
@ 2021-06-28 20:40   ` Tom Lendacky
  2021-06-29  6:04     ` Dov Murik
  0 siblings, 1 reply; 12+ messages in thread
From: Tom Lendacky @ 2021-06-28 20:40 UTC (permalink / raw)
  To: Dov Murik, linux-efi
  Cc: Laszlo Ersek, Ashish Kalra, Brijesh Singh, Ard Biesheuvel,
	James Morris, Serge E. Hallyn, Andi Kleen,
	Dr. David Alan Gilbert, James Bottomley, Tobin Feldman-Fitzthum,
	Jim Cadden, linux-coco, linux-security-module, linux-kernel

On 6/28/21 1:34 PM, Dov Murik wrote:
> When efi-stub copies an EFI-provided confidential computing secret area,
> reserve that memory block for future use within the kernel.
> 
> Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
> ---
>  drivers/firmware/efi/Makefile                 |  2 +-
>  drivers/firmware/efi/confidential-computing.c | 41 +++++++++++++++++++
>  drivers/firmware/efi/efi.c                    |  5 +++
>  include/linux/efi.h                           |  4 ++
>  4 files changed, 51 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/firmware/efi/confidential-computing.c
> 
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 4f647f1ee298..e9740bd16db0 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -551,6 +551,8 @@ extern struct efi {
>  	unsigned long			tpm_log;		/* TPM2 Event Log table */
>  	unsigned long			tpm_final_log;		/* TPM2 Final Events Log table */
>  	unsigned long			mokvar_table;		/* MOK variable config table */
> +	unsigned long			confidential_computing_secret;	/* Confidential computing */
> +									/* secret table           */

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

>  
>  	efi_get_time_t			*get_time;
>  	efi_set_time_t			*set_time;
> @@ -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
> 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH v2 2/3] efi: Reserve confidential computing secret area
  2021-06-28 20:40   ` Tom Lendacky
@ 2021-06-29  6:04     ` Dov Murik
  0 siblings, 0 replies; 12+ messages in thread
From: Dov Murik @ 2021-06-29  6:04 UTC (permalink / raw)
  To: Tom Lendacky, linux-efi
  Cc: Laszlo Ersek, Ashish Kalra, Brijesh Singh, Ard Biesheuvel,
	James Morris, Serge E. Hallyn, Andi Kleen,
	Dr. David Alan Gilbert, James Bottomley, Tobin Feldman-Fitzthum,
	Jim Cadden, linux-coco, linux-security-module, linux-kernel

Hi Tom,

On 28/06/2021 23:40, Tom Lendacky wrote:
> On 6/28/21 1:34 PM, Dov Murik wrote:
>> When efi-stub copies an EFI-provided confidential computing secret area,
>> reserve that memory block for future use within the kernel.
>>
>> Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
>> ---
>>  drivers/firmware/efi/Makefile                 |  2 +-
>>  drivers/firmware/efi/confidential-computing.c | 41 +++++++++++++++++++
>>  drivers/firmware/efi/efi.c                    |  5 +++
>>  include/linux/efi.h                           |  4 ++
>>  4 files changed, 51 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/firmware/efi/confidential-computing.c
>>
>> diff --git a/include/linux/efi.h b/include/linux/efi.h
>> index 4f647f1ee298..e9740bd16db0 100644
>> --- a/include/linux/efi.h
>> +++ b/include/linux/efi.h
>> @@ -551,6 +551,8 @@ extern struct efi {
>>  	unsigned long			tpm_log;		/* TPM2 Event Log table */
>>  	unsigned long			tpm_final_log;		/* TPM2 Final Events Log table */
>>  	unsigned long			mokvar_table;		/* MOK variable config table */
>> +	unsigned long			confidential_computing_secret;	/* Confidential computing */
>> +									/* secret table           */
> 
> 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


> 
> Thanks,
> Tom
> 
>>  
>>  	efi_get_time_t			*get_time;
>>  	efi_set_time_t			*set_time;
>> @@ -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
>>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH v2 0/3] Allow access to confidential computing secret area
  2021-06-28 19:28 ` [RFC PATCH v2 0/3] Allow access to confidential computing secret area Borislav Petkov
@ 2021-06-29  7:16   ` Dov Murik
  2021-06-29 17:33     ` Borislav Petkov
  0 siblings, 1 reply; 12+ messages in thread
From: Dov Murik @ 2021-06-29  7:16 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: linux-efi, Laszlo Ersek, Ashish Kalra, Brijesh Singh,
	Tom Lendacky, Ard Biesheuvel, James Morris, Serge E. Hallyn,
	Andi Kleen, Dr. David Alan Gilbert, James Bottomley,
	Tobin Feldman-Fitzthum, Jim Cadden, linux-coco,
	linux-security-module, linux-kernel, Dov Murik

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:
>> 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.



>>
>> # 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.)


>> 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
> 
> 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" },
> 
> 

I agree.

Thanks,
-Dov

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH v2 3/3] virt: Add sev_secret module to expose confidential computing secrets
  2021-06-28 19:30   ` Borislav Petkov
@ 2021-06-29  7:23     ` Dov Murik
  2021-06-29 22:48       ` Borislav Petkov
  0 siblings, 1 reply; 12+ messages in thread
From: Dov Murik @ 2021-06-29  7:23 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: linux-efi, Laszlo Ersek, Ashish Kalra, Brijesh Singh,
	Tom Lendacky, Ard Biesheuvel, James Morris, Serge E. Hallyn,
	Andi Kleen, Dr. David Alan Gilbert, James Bottomley,
	Tobin Feldman-Fitzthum, Jim Cadden, linux-coco,
	linux-security-module, linux-kernel, Dov Murik



On 28/06/2021 22:30, Borislav Petkov wrote:
> 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 <dovmurik@linux.ibm.com>
>> ---
>>  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.


>> diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
>> index 8061e8ef449f..c222cc625891 100644
>> --- a/drivers/virt/Kconfig
>> +++ b/drivers/virt/Kconfig
>> @@ -36,4 +36,6 @@ source "drivers/virt/vboxguest/Kconfig"
>>  source "drivers/virt/nitro_enclaves/Kconfig"
>>  
>>  source "drivers/virt/acrn/Kconfig"
>> +
>> +source "drivers/virt/sev_secret/Kconfig"
>>  endif
>> diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile
>> index 3e272ea60cd9..0765e5418d1d 100644
>> --- a/drivers/virt/Makefile
>> +++ b/drivers/virt/Makefile
>> @@ -8,3 +8,4 @@ obj-y				+= vboxguest/
>>  
>>  obj-$(CONFIG_NITRO_ENCLAVES)	+= nitro_enclaves/
>>  obj-$(CONFIG_ACRN_HSM)		+= acrn/
>> +obj-y				+= sev_secret/
>> diff --git a/drivers/virt/sev_secret/Kconfig b/drivers/virt/sev_secret/Kconfig
>> new file mode 100644
>> index 000000000000..4505526b8ef1
>> --- /dev/null
>> +++ b/drivers/virt/sev_secret/Kconfig
>> @@ -0,0 +1,11 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +config AMD_SEV_SECRET_SECURITYFS
>> +	tristate "AMD SEV secret area securityfs support"
>> +	depends on EFI
> 
> 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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH v2 0/3] Allow access to confidential computing secret area
  2021-06-29  7:16   ` Dov Murik
@ 2021-06-29 17:33     ` Borislav Petkov
  0 siblings, 0 replies; 12+ messages in thread
From: Borislav Petkov @ 2021-06-29 17:33 UTC (permalink / raw)
  To: Dov Murik
  Cc: linux-efi, Laszlo Ersek, Ashish Kalra, Brijesh Singh,
	Tom Lendacky, Ard Biesheuvel, James Morris, Serge E. Hallyn,
	Andi Kleen, Dr. David Alan Gilbert, James Bottomley,
	Tobin Feldman-Fitzthum, Jim Cadden, linux-coco,
	linux-security-module, linux-kernel

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH v2 3/3] virt: Add sev_secret module to expose confidential computing secrets
  2021-06-29  7:23     ` Dov Murik
@ 2021-06-29 22:48       ` Borislav Petkov
  0 siblings, 0 replies; 12+ messages in thread
From: Borislav Petkov @ 2021-06-29 22:48 UTC (permalink / raw)
  To: Dov Murik
  Cc: linux-efi, Laszlo Ersek, Ashish Kalra, Brijesh Singh,
	Tom Lendacky, Ard Biesheuvel, James Morris, Serge E. Hallyn,
	Andi Kleen, Dr. David Alan Gilbert, James Bottomley,
	Tobin Feldman-Fitzthum, Jim Cadden, linux-coco,
	linux-security-module, linux-kernel

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2021-06-29 22:49 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-28 18:34 [RFC PATCH v2 0/3] Allow access to confidential computing secret area Dov Murik
2021-06-28 18:34 ` [RFC PATCH v2 1/3] efi/libstub: Copy " Dov Murik
2021-06-28 18:34 ` [RFC PATCH v2 2/3] efi: Reserve " Dov Murik
2021-06-28 20:40   ` Tom Lendacky
2021-06-29  6:04     ` Dov Murik
2021-06-28 18:34 ` [RFC PATCH v2 3/3] virt: Add sev_secret module to expose confidential computing secrets Dov Murik
2021-06-28 19:30   ` Borislav Petkov
2021-06-29  7:23     ` Dov Murik
2021-06-29 22:48       ` Borislav Petkov
2021-06-28 19:28 ` [RFC PATCH v2 0/3] Allow access to confidential computing secret area Borislav Petkov
2021-06-29  7:16   ` Dov Murik
2021-06-29 17:33     ` Borislav Petkov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).