linux-coco.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM
@ 2024-03-25 22:26 Tom Lendacky
  2024-03-25 22:26 ` [PATCH v3 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file Tom Lendacky
                   ` (13 more replies)
  0 siblings, 14 replies; 61+ messages in thread
From: Tom Lendacky @ 2024-03-25 22:26 UTC (permalink / raw)
  To: linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra, Joel Becker, Christoph Hellwig

This series adds SEV-SNP support for running Linux under an Secure VM
Service Module (SVSM) at a less privileged VM Privilege Level (VMPL).
By running at a less priviledged VMPL, the SVSM can be used to provide
services, e.g. a virtual TPM, for Linux within the SEV-SNP confidential
VM (CVM) rather than trust such services from the hypervisor.

Currently, a Linux guest expects to run at the highest VMPL, VMPL0, and
there are certain SNP related operations that require that VMPL level.
Specifically, the PVALIDATE instruction and the RMPADJUST instruction
when setting the VMSA attribute of a page (used when starting APs).

If Linux is to run at a less privileged VMPL, e.g. VMPL2, then it must
use an SVSM (which is running at VMPL0) to perform the operations that
it is no longer able to perform.

How Linux interacts with and uses the SVSM is documented in the SVSM
specification [1] and the GHCB specification [2].

This series introduces support to run Linux under an SVSM. It consists
of:
  - Detecting the presence of an SVSM
  - When not running at VMPL0, invoking the SVSM for page validation and
    VMSA page creation/deletion
  - Adding a sysfs entry that specifies the Linux VMPL
  - Modifying the sev-guest driver to use the VMPCK key associated with
    the Linux VMPL
  - Expanding the config-fs TSM support to request attestation reports
    from the SVSM
  - Detecting and allowing Linux to run in a VMPL other than 0 when an
    SVSM is present

The series is based off of and tested against the tip tree:
  https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master

  4e2b6e891aae ("Merge branch into tip/master: 'x86/shstk'")

[1] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
[2] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf

Cc: Joel Becker <jlbec@evilplan.org>
Cc: Christoph Hellwig <hch@lst.de>

---

Changes in v3:
- Rename decompresor snp_setup() to early_snp_setup() to better indicate
  when it is called.
- Rename the "svsm" config-fs attribute into the more generic
  "service_provider" attribute that takes a name as input.
- Change config-fs visibility function to be a simple bool return type
  instead of returning the mode.
- Switch to using new RIP_REL_REF() macro and __head notation where
  appropriate.

Changes in v2:
- Define X86_FEATURE_SVSM_PRESENT and set the bit in the CPUID table,
  removing the need to set the CPUID bit in the #VC handler.
- Rename the TSM service_version attribute to service_manifest_version.
- Add support to config-fs to hide attributes and hide the SVSM attributes
  when an SVSM is not present.


Tom Lendacky (14):
  x86/sev: Rename snp_init() in the boot/compressed/sev.c file
  x86/sev: Make the VMPL0 checking function more generic
  x86/sev: Check for the presence of an SVSM in the SNP Secrets page
  x86/sev: Use kernel provided SVSM Calling Areas
  x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0
  x86/sev: Use the SVSM to create a vCPU when not in VMPL0
  x86/sev: Provide SVSM discovery support
  x86/sev: Provide guest VMPL level to userspace
  virt: sev-guest: Choose the VMPCK key based on executing VMPL
  configfs-tsm: Allow the privlevel_floor attribute to be updated
  x86/sev: Extend the config-fs attestation support for an SVSM
  fs/configfs: Add a callback to determine attribute visibility
  x86/sev: Hide SVSM attestation entries if not running under an SVSM
  x86/sev: Allow non-VMPL0 execution when an SVSM is present

 Documentation/ABI/testing/configfs-tsm  |  69 ++++
 arch/x86/boot/compressed/sev.c          | 256 ++++++++------
 arch/x86/coco/core.c                    |   4 +
 arch/x86/include/asm/cpufeatures.h      |   1 +
 arch/x86/include/asm/msr-index.h        |   2 +
 arch/x86/include/asm/sev-common.h       |  18 +
 arch/x86/include/asm/sev.h              | 114 ++++++-
 arch/x86/include/uapi/asm/svm.h         |   1 +
 arch/x86/kernel/sev-shared.c            | 345 ++++++++++++++++++-
 arch/x86/kernel/sev.c                   | 424 +++++++++++++++++++++---
 arch/x86/mm/mem_encrypt_amd.c           |   8 +-
 drivers/virt/coco/sev-guest/sev-guest.c | 166 +++++++++-
 drivers/virt/coco/tsm.c                 |  99 +++++-
 fs/configfs/file.c                      |   7 +
 include/linux/cc_platform.h             |   8 +
 include/linux/configfs.h                | 111 +++++--
 include/linux/tsm.h                     |  13 +-
 17 files changed, 1442 insertions(+), 204 deletions(-)

-- 
2.43.2


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

* [PATCH v3 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file
  2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
@ 2024-03-25 22:26 ` Tom Lendacky
  2024-04-09 17:09   ` Borislav Petkov
  2024-04-12 16:19   ` Gupta, Pankaj
  2024-03-25 22:26 ` [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic Tom Lendacky
                   ` (12 subsequent siblings)
  13 siblings, 2 replies; 61+ messages in thread
From: Tom Lendacky @ 2024-03-25 22:26 UTC (permalink / raw)
  To: linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

The snp_init() in boot/compressed/sev.c is local to that file and is not
called from outside of the file. Change the name so that it is not tied
to the function definition in arch/x86/include/asm/sev.h. Move the renamed
snp_init() and related functions up in the file to avoid having to add a
forward declaration and make the function static, too.

This will allow the snp_init() function in arch/x86/kernel/sev.c to be
changed without having to make the same change in boot/compressed/sev.c.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/boot/compressed/sev.c | 162 ++++++++++++++++-----------------
 1 file changed, 81 insertions(+), 81 deletions(-)

diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
index ec71846d28c9..5ad0ff4664f1 100644
--- a/arch/x86/boot/compressed/sev.c
+++ b/arch/x86/boot/compressed/sev.c
@@ -413,6 +413,85 @@ void snp_check_features(void)
 	}
 }
 
+/* Search for Confidential Computing blob in the EFI config table. */
+static struct cc_blob_sev_info *find_cc_blob_efi(struct boot_params *bp)
+{
+	unsigned long cfg_table_pa;
+	unsigned int cfg_table_len;
+	int ret;
+
+	ret = efi_get_conf_table(bp, &cfg_table_pa, &cfg_table_len);
+	if (ret)
+		return NULL;
+
+	return (struct cc_blob_sev_info *)efi_find_vendor_table(bp, cfg_table_pa,
+								cfg_table_len,
+								EFI_CC_BLOB_GUID);
+}
+
+/*
+ * Initial set up of SNP relies on information provided by the
+ * Confidential Computing blob, which can be passed to the boot kernel
+ * by firmware/bootloader in the following ways:
+ *
+ * - via an entry in the EFI config table
+ * - via a setup_data structure, as defined by the Linux Boot Protocol
+ *
+ * Scan for the blob in that order.
+ */
+static struct cc_blob_sev_info *find_cc_blob(struct boot_params *bp)
+{
+	struct cc_blob_sev_info *cc_info;
+
+	cc_info = find_cc_blob_efi(bp);
+	if (cc_info)
+		goto found_cc_info;
+
+	cc_info = find_cc_blob_setup_data(bp);
+	if (!cc_info)
+		return NULL;
+
+found_cc_info:
+	if (cc_info->magic != CC_BLOB_SEV_HDR_MAGIC)
+		sev_es_terminate(SEV_TERM_SET_GEN, GHCB_SNP_UNSUPPORTED);
+
+	return cc_info;
+}
+
+/*
+ * Indicate SNP based on presence of SNP-specific CC blob. Subsequent checks
+ * will verify the SNP CPUID/MSR bits.
+ */
+static bool early_snp_init(struct boot_params *bp)
+{
+	struct cc_blob_sev_info *cc_info;
+
+	if (!bp)
+		return false;
+
+	cc_info = find_cc_blob(bp);
+	if (!cc_info)
+		return false;
+
+	/*
+	 * If a SNP-specific Confidential Computing blob is present, then
+	 * firmware/bootloader have indicated SNP support. Verifying this
+	 * involves CPUID checks which will be more reliable if the SNP
+	 * CPUID table is used. See comments over snp_setup_cpuid_table() for
+	 * more details.
+	 */
+	setup_cpuid_table(cc_info);
+
+	/*
+	 * Pass run-time kernel a pointer to CC info via boot_params so EFI
+	 * config table doesn't need to be searched again during early startup
+	 * phase.
+	 */
+	bp->cc_blob_address = (u32)(unsigned long)cc_info;
+
+	return true;
+}
+
 /*
  * sev_check_cpu_support - Check for SEV support in the CPU capabilities
  *
@@ -463,7 +542,7 @@ void sev_enable(struct boot_params *bp)
 		bp->cc_blob_address = 0;
 
 	/*
-	 * Do an initial SEV capability check before snp_init() which
+	 * Do an initial SEV capability check before early_snp_init() which
 	 * loads the CPUID page and the same checks afterwards are done
 	 * without the hypervisor and are trustworthy.
 	 *
@@ -478,7 +557,7 @@ void sev_enable(struct boot_params *bp)
 	 * Setup/preliminary detection of SNP. This will be sanity-checked
 	 * against CPUID/MSR values later.
 	 */
-	snp = snp_init(bp);
+	snp = early_snp_init(bp);
 
 	/* Now repeat the checks with the SNP CPUID table. */
 
@@ -535,85 +614,6 @@ u64 sev_get_status(void)
 	return m.q;
 }
 
-/* Search for Confidential Computing blob in the EFI config table. */
-static struct cc_blob_sev_info *find_cc_blob_efi(struct boot_params *bp)
-{
-	unsigned long cfg_table_pa;
-	unsigned int cfg_table_len;
-	int ret;
-
-	ret = efi_get_conf_table(bp, &cfg_table_pa, &cfg_table_len);
-	if (ret)
-		return NULL;
-
-	return (struct cc_blob_sev_info *)efi_find_vendor_table(bp, cfg_table_pa,
-								cfg_table_len,
-								EFI_CC_BLOB_GUID);
-}
-
-/*
- * Initial set up of SNP relies on information provided by the
- * Confidential Computing blob, which can be passed to the boot kernel
- * by firmware/bootloader in the following ways:
- *
- * - via an entry in the EFI config table
- * - via a setup_data structure, as defined by the Linux Boot Protocol
- *
- * Scan for the blob in that order.
- */
-static struct cc_blob_sev_info *find_cc_blob(struct boot_params *bp)
-{
-	struct cc_blob_sev_info *cc_info;
-
-	cc_info = find_cc_blob_efi(bp);
-	if (cc_info)
-		goto found_cc_info;
-
-	cc_info = find_cc_blob_setup_data(bp);
-	if (!cc_info)
-		return NULL;
-
-found_cc_info:
-	if (cc_info->magic != CC_BLOB_SEV_HDR_MAGIC)
-		sev_es_terminate(SEV_TERM_SET_GEN, GHCB_SNP_UNSUPPORTED);
-
-	return cc_info;
-}
-
-/*
- * Indicate SNP based on presence of SNP-specific CC blob. Subsequent checks
- * will verify the SNP CPUID/MSR bits.
- */
-bool snp_init(struct boot_params *bp)
-{
-	struct cc_blob_sev_info *cc_info;
-
-	if (!bp)
-		return false;
-
-	cc_info = find_cc_blob(bp);
-	if (!cc_info)
-		return false;
-
-	/*
-	 * If a SNP-specific Confidential Computing blob is present, then
-	 * firmware/bootloader have indicated SNP support. Verifying this
-	 * involves CPUID checks which will be more reliable if the SNP
-	 * CPUID table is used. See comments over snp_setup_cpuid_table() for
-	 * more details.
-	 */
-	setup_cpuid_table(cc_info);
-
-	/*
-	 * Pass run-time kernel a pointer to CC info via boot_params so EFI
-	 * config table doesn't need to be searched again during early startup
-	 * phase.
-	 */
-	bp->cc_blob_address = (u32)(unsigned long)cc_info;
-
-	return true;
-}
-
 void sev_prep_identity_maps(unsigned long top_level_pgt)
 {
 	/*
-- 
2.43.2


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

* [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic
  2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
  2024-03-25 22:26 ` [PATCH v3 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file Tom Lendacky
@ 2024-03-25 22:26 ` Tom Lendacky
  2024-04-12 16:41   ` Gupta, Pankaj
  2024-04-17 11:46   ` Borislav Petkov
  2024-03-25 22:26 ` [PATCH v3 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page Tom Lendacky
                   ` (11 subsequent siblings)
  13 siblings, 2 replies; 61+ messages in thread
From: Tom Lendacky @ 2024-03-25 22:26 UTC (permalink / raw)
  To: linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

Currently, the enforce_vmpl0() function uses a set argument when testing
for VMPL0 and terminates the guest if the guest is not running at VMPL0.

Make the function more generic by moving it into the common code, renaming
it, allowing it to take an argument for use in the VMPL0 check (RMPADJUST
instruction) and return the result of the check, allowing the caller to
determine the action taken based on the result.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/boot/compressed/sev.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
index 5ad0ff4664f1..49dc9661176d 100644
--- a/arch/x86/boot/compressed/sev.c
+++ b/arch/x86/boot/compressed/sev.c
@@ -335,10 +335,9 @@ void do_boot_stage2_vc(struct pt_regs *regs, unsigned long exit_code)
 		sev_es_terminate(SEV_TERM_SET_GEN, GHCB_SEV_ES_GEN_REQ);
 }
 
-static void enforce_vmpl0(void)
+static bool running_at_vmpl0(void *va)
 {
 	u64 attrs;
-	int err;
 
 	/*
 	 * RMPADJUST modifies RMP permissions of a lesser-privileged (numerically
@@ -347,12 +346,11 @@ static void enforce_vmpl0(void)
 	 *
 	 * If the guest is running at VMPL0, it will succeed. Even if that operation
 	 * modifies permission bits, it is still ok to do so currently because Linux
-	 * SNP guests are supported only on VMPL0 so VMPL1 or higher permission masks
-	 * changing is a don't-care.
+	 * SNP guests running at VMPL0 only run at VMPL0, so VMPL1 or higher
+	 * permission mask changes are a don't-care.
 	 */
 	attrs = 1;
-	if (rmpadjust((unsigned long)&boot_ghcb_page, RMP_PG_SIZE_4K, attrs))
-		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_NOT_VMPL0);
+	return !rmpadjust((unsigned long)va, RMP_PG_SIZE_4K, attrs);
 }
 
 /*
@@ -588,7 +586,8 @@ void sev_enable(struct boot_params *bp)
 		if (!(get_hv_features() & GHCB_HV_FT_SNP))
 			sev_es_terminate(SEV_TERM_SET_GEN, GHCB_SNP_UNSUPPORTED);
 
-		enforce_vmpl0();
+		if (!running_at_vmpl0(&boot_ghcb_page))
+			sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_NOT_VMPL0);
 	}
 
 	if (snp && !(sev_status & MSR_AMD64_SEV_SNP_ENABLED))
-- 
2.43.2


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

* [PATCH v3 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page
  2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
  2024-03-25 22:26 ` [PATCH v3 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file Tom Lendacky
  2024-03-25 22:26 ` [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic Tom Lendacky
@ 2024-03-25 22:26 ` Tom Lendacky
  2024-04-12 17:03   ` Gupta, Pankaj
  2024-04-17 20:40   ` Borislav Petkov
  2024-03-25 22:26 ` [PATCH v3 04/14] x86/sev: Use kernel provided SVSM Calling Areas Tom Lendacky
                   ` (10 subsequent siblings)
  13 siblings, 2 replies; 61+ messages in thread
From: Tom Lendacky @ 2024-03-25 22:26 UTC (permalink / raw)
  To: linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

During early boot phases, check for the presence of an SVSM when running
as an SEV-SNP guest.

An SVSM is present if the 64-bit value at offset 0x148 into the secrets
page is non-zero. If an SVSM is present, save the SVSM Calling Area
address (CAA), located at offset 0x150 into the secrets page, and set
the VMPL level of the guest, which should be non-zero, to indicate the
presence of an SVSM.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/boot/compressed/sev.c    | 35 ++++++++---------
 arch/x86/include/asm/sev-common.h |  4 ++
 arch/x86/include/asm/sev.h        | 25 +++++++++++-
 arch/x86/kernel/sev-shared.c      | 64 +++++++++++++++++++++++++++++++
 arch/x86/kernel/sev.c             | 16 ++++++++
 5 files changed, 125 insertions(+), 19 deletions(-)

diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
index 49dc9661176d..fe61ff630c7e 100644
--- a/arch/x86/boot/compressed/sev.c
+++ b/arch/x86/boot/compressed/sev.c
@@ -12,6 +12,7 @@
  */
 #include "misc.h"
 
+#include <linux/mm.h>
 #include <asm/bootparam.h>
 #include <asm/pgtable_types.h>
 #include <asm/sev.h>
@@ -29,6 +30,15 @@
 static struct ghcb boot_ghcb_page __aligned(PAGE_SIZE);
 struct ghcb *boot_ghcb;
 
+/*
+ * SVSM related information:
+ *   When running under an SVSM, the VMPL that Linux is executing at must be
+ *   non-zero. The VMPL is therefore used to indicate the presence of an SVSM.
+ */
+static u8 vmpl __section(".data");
+static u64 boot_svsm_caa_pa __section(".data");
+static struct svsm_ca *boot_svsm_caa __section(".data");
+
 /*
  * Copy a version of this function here - insn-eval.c can't be used in
  * pre-decompression code.
@@ -335,24 +345,6 @@ void do_boot_stage2_vc(struct pt_regs *regs, unsigned long exit_code)
 		sev_es_terminate(SEV_TERM_SET_GEN, GHCB_SEV_ES_GEN_REQ);
 }
 
-static bool running_at_vmpl0(void *va)
-{
-	u64 attrs;
-
-	/*
-	 * RMPADJUST modifies RMP permissions of a lesser-privileged (numerically
-	 * higher) privilege level. Here, clear the VMPL1 permission mask of the
-	 * GHCB page. If the guest is not running at VMPL0, this will fail.
-	 *
-	 * If the guest is running at VMPL0, it will succeed. Even if that operation
-	 * modifies permission bits, it is still ok to do so currently because Linux
-	 * SNP guests running at VMPL0 only run at VMPL0, so VMPL1 or higher
-	 * permission mask changes are a don't-care.
-	 */
-	attrs = 1;
-	return !rmpadjust((unsigned long)va, RMP_PG_SIZE_4K, attrs);
-}
-
 /*
  * SNP_FEATURES_IMPL_REQ is the mask of SNP features that will need
  * guest side implementation for proper functioning of the guest. If any
@@ -480,6 +472,13 @@ static bool early_snp_init(struct boot_params *bp)
 	 */
 	setup_cpuid_table(cc_info);
 
+	/*
+	 * Record the SVSM Calling Area address (CAA) if the guest is not
+	 * running at VMPL0. The CA will be used to communicate with the
+	 * SVSM to perform the SVSM services.
+	 */
+	setup_svsm_ca(cc_info);
+
 	/*
 	 * Pass run-time kernel a pointer to CC info via boot_params so EFI
 	 * config table doesn't need to be searched again during early startup
diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h
index b463fcbd4b90..68a8cdf6fd6a 100644
--- a/arch/x86/include/asm/sev-common.h
+++ b/arch/x86/include/asm/sev-common.h
@@ -159,6 +159,10 @@ struct snp_psc_desc {
 #define GHCB_TERM_NOT_VMPL0		3	/* SNP guest is not running at VMPL-0 */
 #define GHCB_TERM_CPUID			4	/* CPUID-validation failure */
 #define GHCB_TERM_CPUID_HV		5	/* CPUID failure during hypervisor fallback */
+#define GHCB_TERM_SECRETS_PAGE		6	/* Secrets page failure */
+#define GHCB_TERM_NO_SVSM		7	/* SVSM is not advertised in the secrets page */
+#define GHCB_TERM_SVSM_VMPL0		8	/* SVSM is present but has set VMPL to 0 */
+#define GHCB_TERM_SVSM_CAA		9	/* SVSM is present but the CA is not page aligned */
 
 #define GHCB_RESP_CODE(v)		((v) & GHCB_MSR_INFO_MASK)
 
diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index 9477b4053bce..891e7d9a1f66 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -152,9 +152,32 @@ struct snp_secrets_page_layout {
 	u8 vmpck2[VMPCK_KEY_LEN];
 	u8 vmpck3[VMPCK_KEY_LEN];
 	struct secrets_os_area os_area;
-	u8 rsvd3[3840];
+
+	u8 vmsa_tweak_bitmap[64];
+
+	/* SVSM fields */
+	u64 svsm_base;
+	u64 svsm_size;
+	u64 svsm_caa;
+	u32 svsm_max_version;
+	u8 svsm_guest_vmpl;
+	u8 rsvd3[3];
+
+	/* Remainder of page */
+	u8 rsvd4[3744];
 } __packed;
 
+/*
+ * The SVSM Calling Area (CA) related structures.
+ */
+struct svsm_ca {
+	u8 call_pending;
+	u8 mem_available;
+	u8 rsvd1[6];
+
+	u8 svsm_buffer[PAGE_SIZE - 8];
+};
+
 #ifdef CONFIG_AMD_MEM_ENCRYPT
 extern void __sev_es_ist_enter(struct pt_regs *regs);
 extern void __sev_es_ist_exit(void);
diff --git a/arch/x86/kernel/sev-shared.c b/arch/x86/kernel/sev-shared.c
index 8b04958da5e7..66d33292eb78 100644
--- a/arch/x86/kernel/sev-shared.c
+++ b/arch/x86/kernel/sev-shared.c
@@ -111,6 +111,24 @@ sev_es_terminate(unsigned int set, unsigned int reason)
 		asm volatile("hlt\n" : : : "memory");
 }
 
+static bool running_at_vmpl0(void *va)
+{
+	u64 attrs;
+
+	/*
+	 * RMPADJUST modifies RMP permissions of a lesser-privileged (numerically
+	 * higher) privilege level. Here, clear the VMPL1 permission mask of the
+	 * GHCB page. If the guest is not running at VMPL0, this will fail.
+	 *
+	 * If the guest is running at VMPL0, it will succeed. Even if that operation
+	 * modifies permission bits, it is still ok to do so currently because Linux
+	 * SNP guests running at VMPL0 only run at VMPL0, so VMPL1 or higher
+	 * permission mask changes are a don't-care.
+	 */
+	attrs = 1;
+	return !rmpadjust((unsigned long)va, RMP_PG_SIZE_4K, attrs);
+}
+
 /*
  * The hypervisor features are available from GHCB version 2 onward.
  */
@@ -1267,3 +1285,49 @@ static enum es_result vc_check_opcode_bytes(struct es_em_ctxt *ctxt,
 
 	return ES_UNSUPPORTED;
 }
+
+/*
+ * Maintain the GPA of the SVSM Calling Area (CA) in order to utilize the SVSM
+ * services needed when not running in VMPL0.
+ */
+static void __head setup_svsm_ca(const struct cc_blob_sev_info *cc_info)
+{
+	struct snp_secrets_page_layout *secrets_page;
+	u64 caa;
+
+	BUILD_BUG_ON(sizeof(*secrets_page) != PAGE_SIZE);
+
+	/*
+	 * Use __pa() since this routine is running identity mapped when
+	 * called, both by the decompressor code and the early kernel code.
+	 */
+	if (running_at_vmpl0((void *)__pa(&boot_ghcb_page)))
+		return;
+
+	/*
+	 * Not running at VMPL0, ensure everything has been properly supplied
+	 * for running under an SVSM.
+	 */
+	if (!cc_info || !cc_info->secrets_phys || cc_info->secrets_len != PAGE_SIZE)
+		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_SECRETS_PAGE);
+
+	secrets_page = (struct snp_secrets_page_layout *)cc_info->secrets_phys;
+	if (!secrets_page->svsm_size)
+		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_NO_SVSM);
+
+	if (!secrets_page->svsm_guest_vmpl)
+		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_SVSM_VMPL0);
+
+	vmpl = secrets_page->svsm_guest_vmpl;
+
+	caa = secrets_page->svsm_caa;
+	if (!PAGE_ALIGNED(caa))
+		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_SVSM_CAA);
+
+	/*
+	 * The CA is identity mapped when this routine is called, both by the
+	 * decompressor code and the early kernel code.
+	 */
+	boot_svsm_caa = (struct svsm_ca *)caa;
+	boot_svsm_caa_pa = caa;
+}
diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index b59b09c2f284..64799a04feb4 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -135,6 +135,15 @@ struct ghcb_state {
 static DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data);
 static DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa);
 
+/*
+ * SVSM related information:
+ *   When running under an SVSM, the VMPL that Linux is executing at must be
+ *   non-zero. The VMPL is therefore used to indicate the presence of an SVSM.
+ */
+static u8 vmpl __ro_after_init;
+static struct svsm_ca *boot_svsm_caa __ro_after_init;
+static u64 boot_svsm_caa_pa __ro_after_init;
+
 struct sev_config {
 	__u64 debug		: 1,
 
@@ -2122,6 +2131,13 @@ bool __head snp_init(struct boot_params *bp)
 
 	setup_cpuid_table(cc_info);
 
+	/*
+	 * Record the SVSM Calling Area address (CAA) if the guest is not
+	 * running at VMPL0. The CA will be used to communicate with the
+	 * SVSM to perform the SVSM services.
+	 */
+	setup_svsm_ca(cc_info);
+
 	/*
 	 * The CC blob will be used later to access the secrets page. Cache
 	 * it here like the boot kernel does.
-- 
2.43.2


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

* [PATCH v3 04/14] x86/sev: Use kernel provided SVSM Calling Areas
  2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
                   ` (2 preceding siblings ...)
  2024-03-25 22:26 ` [PATCH v3 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page Tom Lendacky
@ 2024-03-25 22:26 ` Tom Lendacky
  2024-04-12 16:04   ` Gupta, Pankaj
  2024-03-25 22:26 ` [PATCH v3 05/14] x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0 Tom Lendacky
                   ` (9 subsequent siblings)
  13 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-03-25 22:26 UTC (permalink / raw)
  To: linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

The SVSM Calling Area (CA) is used to communicate between Linux and the
SVSM. Since the firmware supplied CA for the BSP is likely to be in
reserved memory, switch off that CA to a kernel provided CA so that access
and use of the CA is available during boot. The CA switch is done using
the SVSM core protocol SVSM_CORE_REMAP_CA call.

An SVSM call is executed by filling out the SVSM CA and setting the proper
register state as documented by the SVSM protocol. The SVSM is invoked by
by requesting the hypervisor to run VMPL0.

Once it is safe to allocate/reserve memory, allocate a CA for each CPU.
After allocating the new CAs, the BSP will switch from the boot CA to the
per-CPU CA. The CA for an AP is identified to the SVSM when creating the
VMSA in preparation for booting the AP.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/include/asm/sev-common.h |  13 ++
 arch/x86/include/asm/sev.h        |  32 +++++
 arch/x86/include/uapi/asm/svm.h   |   1 +
 arch/x86/kernel/sev-shared.c      |  94 +++++++++++++-
 arch/x86/kernel/sev.c             | 205 +++++++++++++++++++++++++-----
 arch/x86/mm/mem_encrypt_amd.c     |   8 +-
 6 files changed, 318 insertions(+), 35 deletions(-)

diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h
index 68a8cdf6fd6a..71db5ba020b9 100644
--- a/arch/x86/include/asm/sev-common.h
+++ b/arch/x86/include/asm/sev-common.h
@@ -96,6 +96,19 @@ enum psc_op {
 	/* GHCBData[63:32] */				\
 	(((u64)(val) & GENMASK_ULL(63, 32)) >> 32)
 
+/* GHCB Run at VMPL Request/Response */
+#define GHCB_MSR_VMPL_REQ		0x016
+#define GHCB_MSR_VMPL_REQ_LEVEL(v)			\
+	/* GHCBData[39:32] */				\
+	(((u64)(v) & GENMASK_ULL(7, 0) << 32) |		\
+	/* GHCBDdata[11:0] */				\
+	GHCB_MSR_VMPL_REQ)
+
+#define GHCB_MSR_VMPL_RESP		0x017
+#define GHCB_MSR_VMPL_RESP_VAL(v)			\
+	/* GHCBData[63:32] */				\
+	(((u64)(v) & GENMASK_ULL(63, 32)) >> 32)
+
 /* GHCB Hypervisor Feature Request/Response */
 #define GHCB_MSR_HV_FT_REQ		0x080
 #define GHCB_MSR_HV_FT_RESP		0x081
diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index 891e7d9a1f66..4aa36905b047 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -178,6 +178,36 @@ struct svsm_ca {
 	u8 svsm_buffer[PAGE_SIZE - 8];
 };
 
+#define SVSM_SUCCESS				0
+#define SVSM_ERR_INCOMPLETE			0x80000000
+#define SVSM_ERR_UNSUPPORTED_PROTOCOL		0x80000001
+#define SVSM_ERR_UNSUPPORTED_CALL		0x80000002
+#define SVSM_ERR_INVALID_ADDRESS		0x80000003
+#define SVSM_ERR_INVALID_FORMAT			0x80000004
+#define SVSM_ERR_INVALID_PARAMETER		0x80000005
+#define SVSM_ERR_INVALID_REQUEST		0x80000006
+#define SVSM_ERR_BUSY				0x80000007
+
+/*
+ * SVSM protocol structure
+ */
+struct svsm_call {
+	struct svsm_ca *caa;
+	u64 rax;
+	u64 rcx;
+	u64 rdx;
+	u64 r8;
+	u64 r9;
+	u64 rax_out;
+	u64 rcx_out;
+	u64 rdx_out;
+	u64 r8_out;
+	u64 r9_out;
+};
+
+#define SVSM_CORE_CALL(x)		((0ULL << 32) | (x))
+#define SVSM_CORE_REMAP_CA		0
+
 #ifdef CONFIG_AMD_MEM_ENCRYPT
 extern void __sev_es_ist_enter(struct pt_regs *regs);
 extern void __sev_es_ist_exit(void);
@@ -253,6 +283,7 @@ u64 snp_get_unsupported_features(u64 status);
 u64 sev_get_status(void);
 void kdump_sev_callback(void);
 void sev_show_status(void);
+void snp_remap_svsm_ca(void);
 #else
 static inline void sev_es_ist_enter(struct pt_regs *regs) { }
 static inline void sev_es_ist_exit(void) { }
@@ -283,6 +314,7 @@ static inline u64 snp_get_unsupported_features(u64 status) { return 0; }
 static inline u64 sev_get_status(void) { return 0; }
 static inline void kdump_sev_callback(void) { }
 static inline void sev_show_status(void) { }
+static inline void snp_remap_svsm_ca(void) { }
 #endif
 
 #ifdef CONFIG_KVM_AMD_SEV
diff --git a/arch/x86/include/uapi/asm/svm.h b/arch/x86/include/uapi/asm/svm.h
index 80e1df482337..1814b413fd57 100644
--- a/arch/x86/include/uapi/asm/svm.h
+++ b/arch/x86/include/uapi/asm/svm.h
@@ -115,6 +115,7 @@
 #define SVM_VMGEXIT_AP_CREATE_ON_INIT		0
 #define SVM_VMGEXIT_AP_CREATE			1
 #define SVM_VMGEXIT_AP_DESTROY			2
+#define SVM_VMGEXIT_SNP_RUN_VMPL		0x80000018
 #define SVM_VMGEXIT_HV_FEATURES			0x8000fffd
 #define SVM_VMGEXIT_TERM_REQUEST		0x8000fffe
 #define SVM_VMGEXIT_TERM_REASON(reason_set, reason_code)	\
diff --git a/arch/x86/kernel/sev-shared.c b/arch/x86/kernel/sev-shared.c
index 66d33292eb78..78d2b9f570de 100644
--- a/arch/x86/kernel/sev-shared.c
+++ b/arch/x86/kernel/sev-shared.c
@@ -18,9 +18,11 @@
 #define sev_printk_rtl(fmt, ...)	printk_ratelimited(fmt, ##__VA_ARGS__)
 #else
 #undef WARN
-#define WARN(condition, format...) (!!(condition))
+#define WARN(condition, format...)	(!!(condition))
 #define sev_printk(fmt, ...)
 #define sev_printk_rtl(fmt, ...)
+#undef vc_forward_exception
+#define vc_forward_exception(c)		panic("SNP: Hypervisor requested exception\n")
 #endif
 
 /* I/O parameters for CPUID-related helpers */
@@ -247,6 +249,96 @@ static enum es_result verify_exception_info(struct ghcb *ghcb, struct es_em_ctxt
 	return ES_VMM_ERROR;
 }
 
+static __always_inline void issue_svsm_call(struct svsm_call *call, u8 *pending)
+{
+	/*
+	 * Issue the VMGEXIT to run the SVSM:
+	 *   - Load the SVSM register state (RAX, RCX, RDX, R8 and R9)
+	 *   - Set the CA call pending field to 1
+	 *   - Issue VMGEXIT
+	 *   - Save the SVSM return register state (RAX, RCX, RDX, R8 and R9)
+	 *   - Perform atomic exchange of the CA call pending field
+	 */
+	asm volatile("mov %9, %%r8\n\t"
+		     "mov %10, %%r9\n\t"
+		     "movb $1, %11\n\t"
+		     "rep; vmmcall\n\t"
+		     "mov %%r8, %3\n\t"
+		     "mov %%r9, %4\n\t"
+		     "xchgb %5, %11\n\t"
+		     : "=a" (call->rax_out), "=c" (call->rcx_out), "=d" (call->rdx_out),
+		       "=m" (call->r8_out), "=m" (call->r9_out),
+		       "+r" (*pending)
+		     : "a" (call->rax), "c" (call->rcx), "d" (call->rdx),
+		       "r" (call->r8), "r" (call->r9),
+		       "m" (call->caa->call_pending)
+		     : "r8", "r9", "memory");
+}
+
+static int __svsm_msr_protocol(struct svsm_call *call)
+{
+	u64 val, resp;
+	u8 pending;
+
+	val = sev_es_rd_ghcb_msr();
+
+	sev_es_wr_ghcb_msr(GHCB_MSR_VMPL_REQ_LEVEL(0));
+
+	pending = 0;
+	issue_svsm_call(call, &pending);
+
+	resp = sev_es_rd_ghcb_msr();
+
+	sev_es_wr_ghcb_msr(val);
+
+	if (pending)
+		return -EINVAL;
+
+	if (GHCB_RESP_CODE(resp) != GHCB_MSR_VMPL_RESP)
+		return -EINVAL;
+
+	if (GHCB_MSR_VMPL_RESP_VAL(resp) != 0)
+		return -EINVAL;
+
+	return call->rax_out;
+}
+
+static int __svsm_ghcb_protocol(struct ghcb *ghcb, struct svsm_call *call)
+{
+	struct es_em_ctxt ctxt;
+	u8 pending;
+
+	vc_ghcb_invalidate(ghcb);
+
+	/* Fill in protocol and format specifiers */
+	ghcb->protocol_version = ghcb_version;
+	ghcb->ghcb_usage       = GHCB_DEFAULT_USAGE;
+
+	ghcb_set_sw_exit_code(ghcb, SVM_VMGEXIT_SNP_RUN_VMPL);
+	ghcb_set_sw_exit_info_1(ghcb, 0);
+	ghcb_set_sw_exit_info_2(ghcb, 0);
+
+	sev_es_wr_ghcb_msr(__pa(ghcb));
+
+	pending = 0;
+	issue_svsm_call(call, &pending);
+
+	if (pending)
+		return -EINVAL;
+
+	switch (verify_exception_info(ghcb, &ctxt)) {
+	case ES_OK:
+		break;
+	case ES_EXCEPTION:
+		vc_forward_exception(&ctxt);
+		fallthrough;
+	default:
+		return -EINVAL;
+	}
+
+	return call->rax_out;
+}
+
 static enum es_result sev_es_ghcb_hv_call(struct ghcb *ghcb,
 					  struct es_em_ctxt *ctxt,
 					  u64 exit_code, u64 exit_info_1,
diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index 64799a04feb4..af5017ab9746 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -134,6 +134,8 @@ struct ghcb_state {
 
 static DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data);
 static DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa);
+static DEFINE_PER_CPU(struct svsm_ca *, svsm_caa);
+static DEFINE_PER_CPU(u64, svsm_caa_pa);
 
 /*
  * SVSM related information:
@@ -141,6 +143,7 @@ static DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa);
  *   non-zero. The VMPL is therefore used to indicate the presence of an SVSM.
  */
 static u8 vmpl __ro_after_init;
+static struct svsm_ca boot_svsm_ca_page __aligned(PAGE_SIZE);
 static struct svsm_ca *boot_svsm_caa __ro_after_init;
 static u64 boot_svsm_caa_pa __ro_after_init;
 
@@ -158,11 +161,26 @@ struct sev_config {
 	       */
 	      ghcbs_initialized	: 1,
 
+	      /*
+	       * A flag used to indicate when the per-CPU SVSM CA is to be
+	       * used instead of the boot SVSM CA.
+	       *
+	       * For APs, the per-CPU SVSM CA is created as part of the AP
+	       * bringup, so this flag can be used globally for the BSP and APs.
+	       */
+	      cas_initialized	: 1,
+
 	      __reserved	: 62;
 };
 
 static struct sev_config sev_cfg __read_mostly;
 
+static struct svsm_ca *__svsm_get_caa(void)
+{
+	return sev_cfg.cas_initialized ? this_cpu_read(svsm_caa)
+				       : boot_svsm_caa;
+}
+
 static __always_inline bool on_vc_stack(struct pt_regs *regs)
 {
 	unsigned long sp = regs->sp;
@@ -580,6 +598,33 @@ static enum es_result vc_ioio_check(struct es_em_ctxt *ctxt, u16 port, size_t si
 	return ES_EXCEPTION;
 }
 
+static __always_inline void vc_forward_exception(struct es_em_ctxt *ctxt)
+{
+	long error_code = ctxt->fi.error_code;
+	int trapnr = ctxt->fi.vector;
+
+	ctxt->regs->orig_ax = ctxt->fi.error_code;
+
+	switch (trapnr) {
+	case X86_TRAP_GP:
+		exc_general_protection(ctxt->regs, error_code);
+		break;
+	case X86_TRAP_UD:
+		exc_invalid_op(ctxt->regs);
+		break;
+	case X86_TRAP_PF:
+		write_cr2(ctxt->fi.cr2);
+		exc_page_fault(ctxt->regs, error_code);
+		break;
+	case X86_TRAP_AC:
+		exc_alignment_check(ctxt->regs, error_code);
+		break;
+	default:
+		pr_emerg("Unsupported exception in #VC instruction emulation - can't continue\n");
+		BUG();
+	}
+}
+
 /* Include code shared with pre-decompression boot stage */
 #include "sev-shared.c"
 
@@ -608,6 +653,42 @@ static noinstr void __sev_put_ghcb(struct ghcb_state *state)
 	}
 }
 
+static int svsm_protocol(struct svsm_call *call)
+{
+	struct ghcb_state state;
+	unsigned long flags;
+	struct ghcb *ghcb;
+	int ret;
+
+	/*
+	 * This can be called very early in the boot, use native functions in
+	 * order to avoid paravirt issues.
+	 */
+	flags = native_save_fl();
+	if (flags & X86_EFLAGS_IF)
+		native_irq_disable();
+
+	if (sev_cfg.ghcbs_initialized)
+		ghcb = __sev_get_ghcb(&state);
+	else if (boot_ghcb)
+		ghcb = boot_ghcb;
+	else
+		ghcb = NULL;
+
+	do {
+		ret = ghcb ? __svsm_ghcb_protocol(ghcb, call)
+			   : __svsm_msr_protocol(call);
+	} while (ret == SVSM_ERR_BUSY);
+
+	if (sev_cfg.ghcbs_initialized)
+		__sev_put_ghcb(&state);
+
+	if (flags & X86_EFLAGS_IF)
+		native_irq_enable();
+
+	return ret;
+}
+
 void noinstr __sev_es_nmi_complete(void)
 {
 	struct ghcb_state state;
@@ -1369,6 +1450,18 @@ static void __init alloc_runtime_data(int cpu)
 		panic("Can't allocate SEV-ES runtime data");
 
 	per_cpu(runtime_data, cpu) = data;
+
+	if (vmpl) {
+		struct svsm_ca *caa;
+
+		/* Allocate the SVSM CA page if an SVSM is present */
+		caa = memblock_alloc(sizeof(*caa), PAGE_SIZE);
+		if (!caa)
+			panic("Can't allocate SVSM CA page\n");
+
+		per_cpu(svsm_caa, cpu) = caa;
+		per_cpu(svsm_caa_pa, cpu) = __pa(caa);
+	}
 }
 
 static void __init init_ghcb(int cpu)
@@ -1418,6 +1511,31 @@ void __init sev_es_init_vc_handling(void)
 		init_ghcb(cpu);
 	}
 
+	/* If running under an SVSM, switch to the per-cpu CA */
+	if (vmpl) {
+		struct svsm_call call = {};
+		unsigned long flags;
+		int ret;
+
+		local_irq_save(flags);
+
+		/*
+		 * SVSM_CORE_REMAP_CA call:
+		 *   RAX = 0 (Protocol=0, CallID=0)
+		 *   RCX = New CA GPA
+		 */
+		call.caa = __svsm_get_caa();
+		call.rax = SVSM_CORE_CALL(SVSM_CORE_REMAP_CA);
+		call.rcx = this_cpu_read(svsm_caa_pa);
+		ret = svsm_protocol(&call);
+		if (ret != SVSM_SUCCESS)
+			panic("Can't remap the SVSM CA, ret=%#x (%d)\n", ret, ret);
+
+		sev_cfg.cas_initialized = true;
+
+		local_irq_restore(flags);
+	}
+
 	sev_es_setup_play_dead();
 
 	/* Secondary CPUs use the runtime #VC handler */
@@ -1842,33 +1960,6 @@ static enum es_result vc_handle_exitcode(struct es_em_ctxt *ctxt,
 	return result;
 }
 
-static __always_inline void vc_forward_exception(struct es_em_ctxt *ctxt)
-{
-	long error_code = ctxt->fi.error_code;
-	int trapnr = ctxt->fi.vector;
-
-	ctxt->regs->orig_ax = ctxt->fi.error_code;
-
-	switch (trapnr) {
-	case X86_TRAP_GP:
-		exc_general_protection(ctxt->regs, error_code);
-		break;
-	case X86_TRAP_UD:
-		exc_invalid_op(ctxt->regs);
-		break;
-	case X86_TRAP_PF:
-		write_cr2(ctxt->fi.cr2);
-		exc_page_fault(ctxt->regs, error_code);
-		break;
-	case X86_TRAP_AC:
-		exc_alignment_check(ctxt->regs, error_code);
-		break;
-	default:
-		pr_emerg("Unsupported exception in #VC instruction emulation - can't continue\n");
-		BUG();
-	}
-}
-
 static __always_inline bool is_vc2_stack(unsigned long sp)
 {
 	return (sp >= __this_cpu_ist_bottom_va(VC2) && sp < __this_cpu_ist_top_va(VC2));
@@ -2118,6 +2209,50 @@ static __head struct cc_blob_sev_info *find_cc_blob(struct boot_params *bp)
 	return cc_info;
 }
 
+static __head void setup_svsm(struct cc_blob_sev_info *cc_info)
+{
+	struct svsm_call call = {};
+	int ret;
+	u64 pa;
+
+	/*
+	 * Record the SVSM Calling Area address (CAA) if the guest is not
+	 * running at VMPL0. The CA will be used to communicate with the
+	 * SVSM to perform the SVSM services.
+	 */
+	setup_svsm_ca(cc_info);
+
+	/* Nothing to do if not running under an SVSM. */
+	if (!vmpl)
+		return;
+
+	/*
+	 * It is very early in the boot and the kernel is running identity
+	 * mapped but without having adjusted the pagetables to where the
+	 * kernel was loaded (physbase), so the get the CA address using
+	 * RIP-relative addressing.
+	 */
+	pa = (u64)&RIP_REL_REF(boot_svsm_ca_page);
+
+	/*
+	 * Switch over to the boot SVSM CA while the current CA is still
+	 * addressable. There is no GHCB at this point so use the MSR protocol.
+	 *
+	 * SVSM_CORE_REMAP_CA call:
+	 *   RAX = 0 (Protocol=0, CallID=0)
+	 *   RCX = New CA GPA
+	 */
+	call.caa = __svsm_get_caa();
+	call.rax = SVSM_CORE_CALL(SVSM_CORE_REMAP_CA);
+	call.rcx = pa;
+	ret = svsm_protocol(&call);
+	if (ret != SVSM_SUCCESS)
+		panic("Can't remap the SVSM CA, ret=%#x (%d)\n", ret, ret);
+
+	boot_svsm_caa = (struct svsm_ca *)pa;
+	boot_svsm_caa_pa = pa;
+}
+
 bool __head snp_init(struct boot_params *bp)
 {
 	struct cc_blob_sev_info *cc_info;
@@ -2131,12 +2266,7 @@ bool __head snp_init(struct boot_params *bp)
 
 	setup_cpuid_table(cc_info);
 
-	/*
-	 * Record the SVSM Calling Area address (CAA) if the guest is not
-	 * running at VMPL0. The CA will be used to communicate with the
-	 * SVSM to perform the SVSM services.
-	 */
-	setup_svsm_ca(cc_info);
+	setup_svsm(cc_info);
 
 	/*
 	 * The CC blob will be used later to access the secrets page. Cache
@@ -2328,3 +2458,12 @@ void sev_show_status(void)
 	}
 	pr_cont("\n");
 }
+
+void __init snp_remap_svsm_ca(void)
+{
+	if (!vmpl)
+		return;
+
+	/* Update the CAA to a proper kernel address */
+	boot_svsm_caa = &boot_svsm_ca_page;
+}
diff --git a/arch/x86/mm/mem_encrypt_amd.c b/arch/x86/mm/mem_encrypt_amd.c
index 70b91de2e053..8943286f9fdc 100644
--- a/arch/x86/mm/mem_encrypt_amd.c
+++ b/arch/x86/mm/mem_encrypt_amd.c
@@ -2,7 +2,7 @@
 /*
  * AMD Memory Encryption Support
  *
- * Copyright (C) 2016 Advanced Micro Devices, Inc.
+ * Copyright (C) 2016-2024 Advanced Micro Devices, Inc.
  *
  * Author: Tom Lendacky <thomas.lendacky@amd.com>
  */
@@ -492,6 +492,12 @@ void __init sme_early_init(void)
 	 */
 	if (sev_status & MSR_AMD64_SEV_ENABLED)
 		ia32_disable();
+
+	/*
+	 * Switch the SVSM CA mapping (if active) from identity mapped to
+	 * kernel mapped.
+	 */
+	snp_remap_svsm_ca();
 }
 
 void __init mem_encrypt_free_decrypted_mem(void)
-- 
2.43.2


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

* [PATCH v3 05/14] x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0
  2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
                   ` (3 preceding siblings ...)
  2024-03-25 22:26 ` [PATCH v3 04/14] x86/sev: Use kernel provided SVSM Calling Areas Tom Lendacky
@ 2024-03-25 22:26 ` Tom Lendacky
  2024-03-25 22:26 ` [PATCH v3 06/14] x86/sev: Use the SVSM to create a vCPU when not in VMPL0 Tom Lendacky
                   ` (8 subsequent siblings)
  13 siblings, 0 replies; 61+ messages in thread
From: Tom Lendacky @ 2024-03-25 22:26 UTC (permalink / raw)
  To: linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

The PVALIDATE instruction can only be performed at VMPL0. An SVSM will
be present when running at VMPL1 or a lower privilege level.

When an SVSM is present, use the SVSM_CORE_PVALIDATE call to perform
memory validation instead of issuing the PVALIDATE instruction directly.

The validation of a single 4K page is now explicitly identified as such
in the function name, pvalidate_4k_page(). The pvalidate_pages() function
is used for validating 1 or more pages at either 4K or 2M in size. Each
function, however, determines whether it can issue the PVALIDATE directly
or whether the SVSM needs to be invoked.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/boot/compressed/sev.c |  45 ++++++++-
 arch/x86/include/asm/sev.h     |  22 +++++
 arch/x86/kernel/sev-shared.c   | 176 ++++++++++++++++++++++++++++++++-
 arch/x86/kernel/sev.c          |  25 +++--
 4 files changed, 250 insertions(+), 18 deletions(-)

diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
index fe61ff630c7e..f8407ee83ac8 100644
--- a/arch/x86/boot/compressed/sev.c
+++ b/arch/x86/boot/compressed/sev.c
@@ -39,6 +39,16 @@ static u8 vmpl __section(".data");
 static u64 boot_svsm_caa_pa __section(".data");
 static struct svsm_ca *boot_svsm_caa __section(".data");
 
+static struct svsm_ca *__svsm_get_caa(void)
+{
+	return boot_svsm_caa;
+}
+
+static u64 __svsm_get_caa_pa(void)
+{
+	return boot_svsm_caa_pa;
+}
+
 /*
  * Copy a version of this function here - insn-eval.c can't be used in
  * pre-decompression code.
@@ -139,6 +149,24 @@ static bool fault_in_kernel_space(unsigned long address)
 /* Include code for early handlers */
 #include "../../kernel/sev-shared.c"
 
+static int svsm_protocol(struct svsm_call *call)
+{
+	struct ghcb *ghcb;
+	int ret;
+
+	if (boot_ghcb)
+		ghcb = boot_ghcb;
+	else
+		ghcb = NULL;
+
+	do {
+		ret = ghcb ? __svsm_ghcb_protocol(ghcb, call)
+			   : __svsm_msr_protocol(call);
+	} while (ret == SVSM_ERR_BUSY);
+
+	return ret;
+}
+
 bool sev_snp_enabled(void)
 {
 	return sev_status & MSR_AMD64_SEV_SNP_ENABLED;
@@ -155,8 +183,8 @@ static void __page_state_change(unsigned long paddr, enum psc_op op)
 	 * If private -> shared then invalidate the page before requesting the
 	 * state change in the RMP table.
 	 */
-	if (op == SNP_PAGE_STATE_SHARED && pvalidate(paddr, RMP_PG_SIZE_4K, 0))
-		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_PVALIDATE);
+	if (op == SNP_PAGE_STATE_SHARED)
+		pvalidate_4k_page(paddr, paddr, 0);
 
 	/* Issue VMGEXIT to change the page state in RMP table. */
 	sev_es_wr_ghcb_msr(GHCB_MSR_PSC_REQ_GFN(paddr >> PAGE_SHIFT, op));
@@ -171,8 +199,8 @@ static void __page_state_change(unsigned long paddr, enum psc_op op)
 	 * Now that page state is changed in the RMP table, validate it so that it is
 	 * consistent with the RMP entry.
 	 */
-	if (op == SNP_PAGE_STATE_PRIVATE && pvalidate(paddr, RMP_PG_SIZE_4K, 1))
-		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_PVALIDATE);
+	if (op == SNP_PAGE_STATE_PRIVATE)
+		pvalidate_4k_page(paddr, paddr, 1);
 }
 
 void snp_set_page_private(unsigned long paddr)
@@ -265,6 +293,15 @@ void sev_es_shutdown_ghcb(void)
 	if (!sev_es_check_cpu_features())
 		error("SEV-ES CPU Features missing.");
 
+	/*
+	 * The boot_ghcb value is used to determine whether to use the GHCB MSR
+	 * protocol or the GHCB shared page to perform a GHCB request. Since the
+	 * GHCB page is being changed to encrypted, it can't be used to perform
+	 * GHCB requests. Clear the boot_ghcb variable so that the GHCB MSR
+	 * protocol is used to change the GHCB page over to an encrypted page.
+	 */
+	boot_ghcb = NULL;
+
 	/*
 	 * GHCB Page must be flushed from the cache and mapped encrypted again.
 	 * Otherwise the running kernel will see strange cache effects when
diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index 4aa36905b047..204f0a4857d6 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -187,6 +187,27 @@ struct svsm_ca {
 #define SVSM_ERR_INVALID_PARAMETER		0x80000005
 #define SVSM_ERR_INVALID_REQUEST		0x80000006
 #define SVSM_ERR_BUSY				0x80000007
+#define SVSM_PVALIDATE_FAIL_SIZEMISMATCH	0x80001006
+
+/*
+ * The SVSM PVALIDATE related structures
+ */
+struct svsm_pvalidate_entry {
+	u64 page_size		: 2,
+	    action		: 1,
+	    ignore_cf		: 1,
+	    rsvd		: 8,
+	    pfn			: 52;
+};
+
+struct svsm_pvalidate_call {
+	u16 entries;
+	u16 next;
+
+	u8 rsvd1[4];
+
+	struct svsm_pvalidate_entry entry[];
+};
 
 /*
  * SVSM protocol structure
@@ -207,6 +228,7 @@ struct svsm_call {
 
 #define SVSM_CORE_CALL(x)		((0ULL << 32) | (x))
 #define SVSM_CORE_REMAP_CA		0
+#define SVSM_CORE_PVALIDATE		1
 
 #ifdef CONFIG_AMD_MEM_ENCRYPT
 extern void __sev_es_ist_enter(struct pt_regs *regs);
diff --git a/arch/x86/kernel/sev-shared.c b/arch/x86/kernel/sev-shared.c
index 78d2b9f570de..e63c0a6eccd6 100644
--- a/arch/x86/kernel/sev-shared.c
+++ b/arch/x86/kernel/sev-shared.c
@@ -87,6 +87,8 @@ static u32 cpuid_std_range_max __ro_after_init;
 static u32 cpuid_hyp_range_max __ro_after_init;
 static u32 cpuid_ext_range_max __ro_after_init;
 
+static int svsm_protocol(struct svsm_call *call);
+
 static bool __init sev_es_check_cpu_features(void)
 {
 	if (!has_cpuflag(X86_FEATURE_RDRAND)) {
@@ -1189,7 +1191,65 @@ static void __head setup_cpuid_table(const struct cc_blob_sev_info *cc_info)
 	}
 }
 
-static void pvalidate_pages(struct snp_psc_desc *desc)
+static int base_pvalidate_4k_page(unsigned long vaddr, bool validate)
+{
+	return pvalidate(vaddr, RMP_PG_SIZE_4K, validate);
+}
+
+static int svsm_pvalidate_4k_page(unsigned long paddr, bool validate)
+{
+	struct svsm_pvalidate_call *pvalidate_call;
+	struct svsm_call call = {};
+	u64 pvalidate_call_pa;
+	unsigned long flags;
+	int ret;
+
+	/*
+	 * This can be called very early in the boot, use native functions in
+	 * order to avoid paravirt issues.
+	 */
+	flags = native_save_fl();
+	if (flags & X86_EFLAGS_IF)
+		native_irq_disable();
+
+	call.caa = __svsm_get_caa();
+
+	pvalidate_call = (struct svsm_pvalidate_call *)call.caa->svsm_buffer;
+	pvalidate_call_pa = __svsm_get_caa_pa() + offsetof(struct svsm_ca, svsm_buffer);
+
+	pvalidate_call->entries = 1;
+	pvalidate_call->next    = 0;
+	pvalidate_call->entry[0].page_size = RMP_PG_SIZE_4K;
+	pvalidate_call->entry[0].action    = validate;
+	pvalidate_call->entry[0].ignore_cf = 0;
+	pvalidate_call->entry[0].pfn       = paddr >> PAGE_SHIFT;
+
+	/* Protocol 0, Call ID 1 */
+	call.rax = SVSM_CORE_CALL(SVSM_CORE_PVALIDATE);
+	call.rcx = pvalidate_call_pa;
+
+	ret = svsm_protocol(&call);
+
+	if (flags & X86_EFLAGS_IF)
+		native_irq_enable();
+
+	return ret;
+}
+
+static void pvalidate_4k_page(unsigned long vaddr, unsigned long paddr, bool validate)
+{
+	int ret;
+
+	ret = vmpl ? svsm_pvalidate_4k_page(paddr, validate)
+		   : base_pvalidate_4k_page(vaddr, validate);
+
+	if (ret) {
+		WARN(1, "Failed to validate address 0x%lx ret %d", vaddr, ret);
+		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_PVALIDATE);
+	}
+}
+
+static void base_pvalidate_pages(struct snp_psc_desc *desc)
 {
 	struct psc_entry *e;
 	unsigned long vaddr;
@@ -1223,6 +1283,120 @@ static void pvalidate_pages(struct snp_psc_desc *desc)
 	}
 }
 
+static void svsm_pvalidate_pages(struct snp_psc_desc *desc)
+{
+	struct svsm_pvalidate_call *pvalidate_call;
+	struct svsm_pvalidate_entry *pe;
+	unsigned int call_count, i;
+	struct svsm_call call = {};
+	u64 pvalidate_call_pa;
+	struct psc_entry *e;
+	unsigned long flags;
+	unsigned long vaddr;
+	bool action;
+	int ret;
+
+	/*
+	 * This can be called very early in the boot, use native functions in
+	 * order to avoid paravirt issues.
+	 */
+	flags = native_save_fl();
+	if (flags & X86_EFLAGS_IF)
+		native_irq_disable();
+
+	call.caa = __svsm_get_caa();
+
+	pvalidate_call = (struct svsm_pvalidate_call *)call.caa->svsm_buffer;
+	pvalidate_call_pa = __svsm_get_caa_pa() + offsetof(struct svsm_ca, svsm_buffer);
+
+	/* Calculate how many entries the CA buffer can hold */
+	call_count = sizeof(call.caa->svsm_buffer);
+	call_count -= offsetof(struct svsm_pvalidate_call, entry);
+	call_count /= sizeof(pvalidate_call->entry[0]);
+
+	/* Protocol 0, Call ID 1 */
+	call.rax = SVSM_CORE_CALL(SVSM_CORE_PVALIDATE);
+	call.rcx = pvalidate_call_pa;
+
+	pvalidate_call->entries = 0;
+	pvalidate_call->next    = 0;
+
+	for (i = 0; i <= desc->hdr.end_entry; i++) {
+		e = &desc->entries[i];
+		pe = &pvalidate_call->entry[pvalidate_call->entries];
+
+		pe->page_size = e->pagesize ? RMP_PG_SIZE_2M : RMP_PG_SIZE_4K;
+		pe->action    = e->operation == SNP_PAGE_STATE_PRIVATE;
+		pe->ignore_cf = 0;
+		pe->pfn       = e->gfn;
+
+		pvalidate_call->entries++;
+		if (pvalidate_call->entries < call_count && i != desc->hdr.end_entry)
+			continue;
+
+		ret = svsm_protocol(&call);
+		if (ret == SVSM_PVALIDATE_FAIL_SIZEMISMATCH &&
+		    pvalidate_call->entry[pvalidate_call->next].page_size == RMP_PG_SIZE_2M) {
+			u64 pfn, pfn_end;
+
+			/*
+			 * The "next" field is the index of the failed entry. Calculate the
+			 * index of the entry after the failed entry before the fields are
+			 * cleared so that processing can continue on from that point (take
+			 * into account the for loop adding 1 to the entry).
+			 */
+			i -= pvalidate_call->entries - pvalidate_call->next;
+			i += 1;
+
+			action = pvalidate_call->entry[pvalidate_call->next].action;
+			pfn = pvalidate_call->entry[pvalidate_call->next].pfn;
+			pfn_end = pfn + 511;
+
+			pvalidate_call->entries = 0;
+			pvalidate_call->next    = 0;
+			for (; pfn <= pfn_end; pfn++) {
+				pe = &pvalidate_call->entry[pvalidate_call->entries];
+
+				pe->page_size = RMP_PG_SIZE_4K;
+				pe->action    = action;
+				pe->ignore_cf = 0;
+				pe->pfn       = pfn;
+
+				pvalidate_call->entries++;
+				if (pvalidate_call->entries < call_count && pfn != pfn_end)
+					continue;
+
+				ret = svsm_protocol(&call);
+				if (ret != SVSM_SUCCESS)
+					break;
+
+				pvalidate_call->entries = 0;
+				pvalidate_call->next    = 0;
+			}
+		}
+
+		if (ret != SVSM_SUCCESS) {
+			pe = &pvalidate_call->entry[pvalidate_call->next];
+			vaddr = (unsigned long)pfn_to_kaddr(pe->pfn);
+
+			WARN(1, "Failed to validate address %lx ret=%#x (%d)", vaddr, ret, ret);
+			sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_PVALIDATE);
+		}
+
+		pvalidate_call->entries = 0;
+		pvalidate_call->next    = 0;
+	}
+
+	if (flags & X86_EFLAGS_IF)
+		native_irq_enable();
+}
+
+static void pvalidate_pages(struct snp_psc_desc *desc)
+{
+	vmpl ? svsm_pvalidate_pages(desc)
+	     : base_pvalidate_pages(desc);
+}
+
 static int vmgexit_psc(struct ghcb *ghcb, struct snp_psc_desc *desc)
 {
 	int cur_entry, end_entry, ret = 0;
diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index af5017ab9746..d3e182d69d65 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -181,6 +181,12 @@ static struct svsm_ca *__svsm_get_caa(void)
 				       : boot_svsm_caa;
 }
 
+static u64 __svsm_get_caa_pa(void)
+{
+	return sev_cfg.cas_initialized ? this_cpu_read(svsm_caa_pa)
+				       : boot_svsm_caa_pa;
+}
+
 static __always_inline bool on_vc_stack(struct pt_regs *regs)
 {
 	unsigned long sp = regs->sp;
@@ -798,7 +804,6 @@ early_set_pages_state(unsigned long vaddr, unsigned long paddr,
 {
 	unsigned long paddr_end;
 	u64 val;
-	int ret;
 
 	vaddr = vaddr & PAGE_MASK;
 
@@ -806,12 +811,9 @@ early_set_pages_state(unsigned long vaddr, unsigned long paddr,
 	paddr_end = paddr + (npages << PAGE_SHIFT);
 
 	while (paddr < paddr_end) {
-		if (op == SNP_PAGE_STATE_SHARED) {
-			/* Page validation must be rescinded before changing to shared */
-			ret = pvalidate(vaddr, RMP_PG_SIZE_4K, false);
-			if (WARN(ret, "Failed to validate address 0x%lx ret %d", paddr, ret))
-				goto e_term;
-		}
+		/* Page validation must be rescinded before changing to shared */
+		if (op == SNP_PAGE_STATE_SHARED)
+			pvalidate_4k_page(vaddr, paddr, false);
 
 		/*
 		 * Use the MSR protocol because this function can be called before
@@ -833,12 +835,9 @@ early_set_pages_state(unsigned long vaddr, unsigned long paddr,
 			 paddr, GHCB_MSR_PSC_RESP_VAL(val)))
 			goto e_term;
 
-		if (op == SNP_PAGE_STATE_PRIVATE) {
-			/* Page validation must be performed after changing to private */
-			ret = pvalidate(vaddr, RMP_PG_SIZE_4K, true);
-			if (WARN(ret, "Failed to validate address 0x%lx ret %d", paddr, ret))
-				goto e_term;
-		}
+		/* Page validation must be performed after changing to private */
+		if (op == SNP_PAGE_STATE_PRIVATE)
+			pvalidate_4k_page(vaddr, paddr, true);
 
 		vaddr += PAGE_SIZE;
 		paddr += PAGE_SIZE;
-- 
2.43.2


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

* [PATCH v3 06/14] x86/sev: Use the SVSM to create a vCPU when not in VMPL0
  2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
                   ` (4 preceding siblings ...)
  2024-03-25 22:26 ` [PATCH v3 05/14] x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0 Tom Lendacky
@ 2024-03-25 22:26 ` Tom Lendacky
  2024-04-12 15:28   ` Gupta, Pankaj
  2024-03-25 22:26 ` [PATCH v3 07/14] x86/sev: Provide SVSM discovery support Tom Lendacky
                   ` (7 subsequent siblings)
  13 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-03-25 22:26 UTC (permalink / raw)
  To: linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

Using the RMPADJUST instruction, the VSMA attribute can only be changed
at VMPL0. An SVSM will be present when running at VMPL1 or a lower
privilege level.

When an SVSM is present, use the SVSM_CORE_CREATE_VCPU call or the
SVSM_CORE_DESTROY_VCPU call to perform VMSA attribute changes. Use the
VMPL level supplied by the SVSM within the VMSA and when starting the
AP.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/include/asm/sev.h |  2 ++
 arch/x86/kernel/sev.c      | 60 +++++++++++++++++++++++++++++++++-----
 2 files changed, 54 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index 204f0a4857d6..d7be613b7372 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -229,6 +229,8 @@ struct svsm_call {
 #define SVSM_CORE_CALL(x)		((0ULL << 32) | (x))
 #define SVSM_CORE_REMAP_CA		0
 #define SVSM_CORE_PVALIDATE		1
+#define SVSM_CORE_CREATE_VCPU		2
+#define SVSM_CORE_DELETE_VCPU		3
 
 #ifdef CONFIG_AMD_MEM_ENCRYPT
 extern void __sev_es_ist_enter(struct pt_regs *regs);
diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index d3e182d69d65..ea8b43a0f01b 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -1016,7 +1016,7 @@ void snp_accept_memory(phys_addr_t start, phys_addr_t end)
 	set_pages_state(vaddr, npages, SNP_PAGE_STATE_PRIVATE);
 }
 
-static int snp_set_vmsa(void *va, bool vmsa)
+static int base_snp_set_vmsa(void *va, bool vmsa)
 {
 	u64 attrs;
 
@@ -1034,6 +1034,40 @@ static int snp_set_vmsa(void *va, bool vmsa)
 	return rmpadjust((unsigned long)va, RMP_PG_SIZE_4K, attrs);
 }
 
+static int svsm_snp_set_vmsa(void *va, void *caa, int apic_id, bool vmsa)
+{
+	struct svsm_call call = {};
+	unsigned long flags;
+	int ret;
+
+	local_irq_save(flags);
+
+	call.caa = this_cpu_read(svsm_caa);
+	call.rcx = __pa(va);
+
+	if (vmsa) {
+		/* Protocol 0, Call ID 2 */
+		call.rax = SVSM_CORE_CALL(SVSM_CORE_CREATE_VCPU);
+		call.rdx = __pa(caa);
+		call.r8  = apic_id;
+	} else {
+		/* Protocol 0, Call ID 3 */
+		call.rax = SVSM_CORE_CALL(SVSM_CORE_DELETE_VCPU);
+	}
+
+	ret = svsm_protocol(&call);
+
+	local_irq_restore(flags);
+
+	return ret;
+}
+
+static int snp_set_vmsa(void *va, void *caa, int apic_id, bool vmsa)
+{
+	return vmpl ? svsm_snp_set_vmsa(va, caa, apic_id, vmsa)
+		    : base_snp_set_vmsa(va, vmsa);
+}
+
 #define __ATTR_BASE		(SVM_SELECTOR_P_MASK | SVM_SELECTOR_S_MASK)
 #define INIT_CS_ATTRIBS		(__ATTR_BASE | SVM_SELECTOR_READ_MASK | SVM_SELECTOR_CODE_MASK)
 #define INIT_DS_ATTRIBS		(__ATTR_BASE | SVM_SELECTOR_WRITE_MASK)
@@ -1065,11 +1099,11 @@ static void *snp_alloc_vmsa_page(void)
 	return page_address(p + 1);
 }
 
-static void snp_cleanup_vmsa(struct sev_es_save_area *vmsa)
+static void snp_cleanup_vmsa(struct sev_es_save_area *vmsa, int apic_id)
 {
 	int err;
 
-	err = snp_set_vmsa(vmsa, false);
+	err = snp_set_vmsa(vmsa, NULL, apic_id, false);
 	if (err)
 		pr_err("clear VMSA page failed (%u), leaking page\n", err);
 	else
@@ -1080,6 +1114,7 @@ static int wakeup_cpu_via_vmgexit(u32 apic_id, unsigned long start_ip)
 {
 	struct sev_es_save_area *cur_vmsa, *vmsa;
 	struct ghcb_state state;
+	struct svsm_ca *caa;
 	unsigned long flags;
 	struct ghcb *ghcb;
 	u8 sipi_vector;
@@ -1126,6 +1161,12 @@ static int wakeup_cpu_via_vmgexit(u32 apic_id, unsigned long start_ip)
 	if (!vmsa)
 		return -ENOMEM;
 
+	/*
+	 * If an SVSM is present, then the SVSM CAA per-CPU variable will
+	 * have a value, otherwise it will be NULL.
+	 */
+	caa = per_cpu(svsm_caa, cpu);
+
 	/* CR4 should maintain the MCE value */
 	cr4 = native_read_cr4() & X86_CR4_MCE;
 
@@ -1173,11 +1214,11 @@ static int wakeup_cpu_via_vmgexit(u32 apic_id, unsigned long start_ip)
 	 *   VMPL level
 	 *   SEV_FEATURES (matches the SEV STATUS MSR right shifted 2 bits)
 	 */
-	vmsa->vmpl		= 0;
+	vmsa->vmpl		= vmpl;
 	vmsa->sev_features	= sev_status >> 2;
 
 	/* Switch the page over to a VMSA page now that it is initialized */
-	ret = snp_set_vmsa(vmsa, true);
+	ret = snp_set_vmsa(vmsa, caa, apic_id, true);
 	if (ret) {
 		pr_err("set VMSA page failed (%u)\n", ret);
 		free_page((unsigned long)vmsa);
@@ -1193,7 +1234,10 @@ static int wakeup_cpu_via_vmgexit(u32 apic_id, unsigned long start_ip)
 	vc_ghcb_invalidate(ghcb);
 	ghcb_set_rax(ghcb, vmsa->sev_features);
 	ghcb_set_sw_exit_code(ghcb, SVM_VMGEXIT_AP_CREATION);
-	ghcb_set_sw_exit_info_1(ghcb, ((u64)apic_id << 32) | SVM_VMGEXIT_AP_CREATE);
+	ghcb_set_sw_exit_info_1(ghcb,
+				((u64)apic_id << 32)	|
+				((u64)vmpl << 16)	|
+				SVM_VMGEXIT_AP_CREATE);
 	ghcb_set_sw_exit_info_2(ghcb, __pa(vmsa));
 
 	sev_es_wr_ghcb_msr(__pa(ghcb));
@@ -1211,13 +1255,13 @@ static int wakeup_cpu_via_vmgexit(u32 apic_id, unsigned long start_ip)
 
 	/* Perform cleanup if there was an error */
 	if (ret) {
-		snp_cleanup_vmsa(vmsa);
+		snp_cleanup_vmsa(vmsa, apic_id);
 		vmsa = NULL;
 	}
 
 	/* Free up any previous VMSA page */
 	if (cur_vmsa)
-		snp_cleanup_vmsa(cur_vmsa);
+		snp_cleanup_vmsa(cur_vmsa, apic_id);
 
 	/* Record the current VMSA page */
 	per_cpu(sev_vmsa, cpu) = vmsa;
-- 
2.43.2


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

* [PATCH v3 07/14] x86/sev: Provide SVSM discovery support
  2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
                   ` (5 preceding siblings ...)
  2024-03-25 22:26 ` [PATCH v3 06/14] x86/sev: Use the SVSM to create a vCPU when not in VMPL0 Tom Lendacky
@ 2024-03-25 22:26 ` Tom Lendacky
  2024-04-15 16:12   ` Gupta, Pankaj
  2024-03-25 22:26 ` [PATCH v3 08/14] x86/sev: Provide guest VMPL level to userspace Tom Lendacky
                   ` (6 subsequent siblings)
  13 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-03-25 22:26 UTC (permalink / raw)
  To: linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

The SVSM specification documents an alternative method of discovery for
the SVSM using a reserved CPUID bit and a reserved MSR.

For the CPUID support, the SNP CPUID table is updated to set bit 28 of
the EAX register of the 0x8000001f leaf when an SVSM is present. This bit
has been reserved for use in this capacity.

For the MSR support, a new reserved MSR 0xc001f000 has been defined. A #VC
should be generated when accessing this MSR. The #VC handler is expected
to ignore writes to this MSR and return the physical calling area address
(CAA) on reads of this MSR.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/include/asm/cpufeatures.h |  1 +
 arch/x86/include/asm/msr-index.h   |  2 ++
 arch/x86/kernel/sev-shared.c       | 11 +++++++++++
 arch/x86/kernel/sev.c              | 17 +++++++++++++++++
 4 files changed, 31 insertions(+)

diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index a38f8f9ba657..51e7c879f057 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -446,6 +446,7 @@
 #define X86_FEATURE_V_TSC_AUX		(19*32+ 9) /* "" Virtual TSC_AUX */
 #define X86_FEATURE_SME_COHERENT	(19*32+10) /* "" AMD hardware-enforced cache coherency */
 #define X86_FEATURE_DEBUG_SWAP		(19*32+14) /* AMD SEV-ES full debug state swap support */
+#define X86_FEATURE_SVSM_PRESENT	(19*32+28) /* "" SNP SVSM is present */
 
 /* AMD-defined Extended Feature 2 EAX, CPUID level 0x80000021 (EAX), word 20 */
 #define X86_FEATURE_NO_NESTED_DATA_BP	(20*32+ 0) /* "" No Nested Data Breakpoints */
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 05956bd8bacf..cc4de3379265 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -654,6 +654,8 @@
 #define MSR_AMD64_RMP_BASE		0xc0010132
 #define MSR_AMD64_RMP_END		0xc0010133
 
+#define MSR_SVSM_CAA			0xc001f000
+
 /* AMD Collaborative Processor Performance Control MSRs */
 #define MSR_AMD_CPPC_CAP1		0xc00102b0
 #define MSR_AMD_CPPC_ENABLE		0xc00102b1
diff --git a/arch/x86/kernel/sev-shared.c b/arch/x86/kernel/sev-shared.c
index e63c0a6eccd6..17eb42c4ae71 100644
--- a/arch/x86/kernel/sev-shared.c
+++ b/arch/x86/kernel/sev-shared.c
@@ -1559,6 +1559,8 @@ static enum es_result vc_check_opcode_bytes(struct es_em_ctxt *ctxt,
 static void __head setup_svsm_ca(const struct cc_blob_sev_info *cc_info)
 {
 	struct snp_secrets_page_layout *secrets_page;
+	struct snp_cpuid_table *cpuid_table;
+	unsigned int i;
 	u64 caa;
 
 	BUILD_BUG_ON(sizeof(*secrets_page) != PAGE_SIZE);
@@ -1596,4 +1598,13 @@ static void __head setup_svsm_ca(const struct cc_blob_sev_info *cc_info)
 	 */
 	boot_svsm_caa = (struct svsm_ca *)caa;
 	boot_svsm_caa_pa = caa;
+
+	/* Advertise the SVSM presence via CPUID. */
+	cpuid_table = (struct snp_cpuid_table *)snp_cpuid_get_table();
+	for (i = 0; i < cpuid_table->count; i++) {
+		struct snp_cpuid_fn *fn = &cpuid_table->fn[i];
+
+		if (fn->eax_in == 0x8000001f)
+			fn->eax |= BIT(28);
+	}
 }
diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index ea8b43a0f01b..7f399ea87a3c 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -1347,12 +1347,29 @@ int __init sev_es_efi_map_ghcbs(pgd_t *pgd)
 	return 0;
 }
 
+static enum es_result vc_handle_svsm_caa_msr(struct es_em_ctxt *ctxt)
+{
+	struct pt_regs *regs = ctxt->regs;
+
+	/* Writes to the SVSM CAA msr are ignored */
+	if (ctxt->insn.opcode.bytes[1] == 0x30)
+		return ES_OK;
+
+	regs->ax = lower_32_bits(this_cpu_read(svsm_caa_pa));
+	regs->dx = upper_32_bits(this_cpu_read(svsm_caa_pa));
+
+	return ES_OK;
+}
+
 static enum es_result vc_handle_msr(struct ghcb *ghcb, struct es_em_ctxt *ctxt)
 {
 	struct pt_regs *regs = ctxt->regs;
 	enum es_result ret;
 	u64 exit_info_1;
 
+	if (regs->cx == MSR_SVSM_CAA)
+		return vc_handle_svsm_caa_msr(ctxt);
+
 	/* Is it a WRMSR? */
 	exit_info_1 = (ctxt->insn.opcode.bytes[1] == 0x30) ? 1 : 0;
 
-- 
2.43.2


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

* [PATCH v3 08/14] x86/sev: Provide guest VMPL level to userspace
  2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
                   ` (6 preceding siblings ...)
  2024-03-25 22:26 ` [PATCH v3 07/14] x86/sev: Provide SVSM discovery support Tom Lendacky
@ 2024-03-25 22:26 ` Tom Lendacky
  2024-03-25 22:26 ` [PATCH v3 09/14] virt: sev-guest: Choose the VMPCK key based on executing VMPL Tom Lendacky
                   ` (5 subsequent siblings)
  13 siblings, 0 replies; 61+ messages in thread
From: Tom Lendacky @ 2024-03-25 22:26 UTC (permalink / raw)
  To: linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

Requesting an attestation report from userspace involves providing the
VMPL level for the report. Currently any value from 0-3 is valid because
Linux enforces running at VMPL0.

When an SVSM is present, though, Linux will not be running at VMPL0 and
only VMPL values starting at the VMPL level Linux is running at to 3 are
valid. In order to allow userspace to determine the minimum VMPL value
that can be supplied to an attestation report, create a sysfs entry that
can be used to retrieve the current VMPL level of Linux.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/kernel/sev.c | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index 7f399ea87a3c..b027b00e315d 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -2527,3 +2527,40 @@ void __init snp_remap_svsm_ca(void)
 	/* Update the CAA to a proper kernel address */
 	boot_svsm_caa = &boot_svsm_ca_page;
 }
+
+static ssize_t vmpl_show(struct kobject *kobj,
+			 struct kobj_attribute *attr, char *buf)
+{
+	return sysfs_emit(buf, "%d\n", vmpl);
+}
+
+static struct kobj_attribute vmpl_attr = __ATTR_RO(vmpl);
+
+static struct attribute *vmpl_attrs[] = {
+	&vmpl_attr.attr,
+	NULL
+};
+
+static struct attribute_group sev_attr_group = {
+	.attrs = vmpl_attrs,
+};
+
+static int __init sev_sysfs_init(void)
+{
+	struct kobject *sev_kobj;
+	int ret;
+
+	if (!cc_platform_has(CC_ATTR_GUEST_SEV_SNP))
+		return -ENODEV;
+
+	sev_kobj = kobject_create_and_add("sev", kernel_kobj);
+	if (!sev_kobj)
+		return -ENOMEM;
+
+	ret = sysfs_create_group(sev_kobj, &sev_attr_group);
+	if (ret)
+		kobject_put(sev_kobj);
+
+	return ret;
+}
+arch_initcall(sev_sysfs_init);
-- 
2.43.2


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

* [PATCH v3 09/14] virt: sev-guest: Choose the VMPCK key based on executing VMPL
  2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
                   ` (7 preceding siblings ...)
  2024-03-25 22:26 ` [PATCH v3 08/14] x86/sev: Provide guest VMPL level to userspace Tom Lendacky
@ 2024-03-25 22:26 ` Tom Lendacky
  2024-04-16  4:54   ` Dan Williams
  2024-03-25 22:26 ` [PATCH v3 10/14] configfs-tsm: Allow the privlevel_floor attribute to be updated Tom Lendacky
                   ` (4 subsequent siblings)
  13 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-03-25 22:26 UTC (permalink / raw)
  To: linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

Currently, the sev-guest driver uses the vmpck-0 key by default. When an
SVSM is present the kernel is running at a VMPL other than 0 and the
vmpck-0 key is no longer available. So choose the vmpck key based on the
active VMPL level.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/include/asm/sev.h              |  2 ++
 arch/x86/kernel/sev.c                   |  6 ++++++
 drivers/virt/coco/sev-guest/sev-guest.c | 10 +++++++---
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index d7be613b7372..066eb0ba3d63 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -308,6 +308,7 @@ u64 sev_get_status(void);
 void kdump_sev_callback(void);
 void sev_show_status(void);
 void snp_remap_svsm_ca(void);
+int snp_get_vmpl(void);
 #else
 static inline void sev_es_ist_enter(struct pt_regs *regs) { }
 static inline void sev_es_ist_exit(void) { }
@@ -339,6 +340,7 @@ static inline u64 sev_get_status(void) { return 0; }
 static inline void kdump_sev_callback(void) { }
 static inline void sev_show_status(void) { }
 static inline void snp_remap_svsm_ca(void) { }
+static inline int snp_get_vmpl(void) { return 0; }
 #endif
 
 #ifdef CONFIG_KVM_AMD_SEV
diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index b027b00e315d..7e2b9934a95d 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -2464,6 +2464,12 @@ int snp_issue_guest_request(u64 exit_code, struct snp_req_data *input, struct sn
 }
 EXPORT_SYMBOL_GPL(snp_issue_guest_request);
 
+int snp_get_vmpl(void)
+{
+	return vmpl;
+}
+EXPORT_SYMBOL_GPL(snp_get_vmpl);
+
 static struct platform_device sev_guest_device = {
 	.name		= "sev-guest",
 	.id		= -1,
diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
index 87f241825bc3..1ff897913bf4 100644
--- a/drivers/virt/coco/sev-guest/sev-guest.c
+++ b/drivers/virt/coco/sev-guest/sev-guest.c
@@ -2,7 +2,7 @@
 /*
  * AMD Secure Encrypted Virtualization (SEV) guest driver interface
  *
- * Copyright (C) 2021 Advanced Micro Devices, Inc.
+ * Copyright (C) 2021-2024 Advanced Micro Devices, Inc.
  *
  * Author: Brijesh Singh <brijesh.singh@amd.com>
  */
@@ -70,8 +70,8 @@ struct snp_guest_dev {
 	u8 *vmpck;
 };
 
-static u32 vmpck_id;
-module_param(vmpck_id, uint, 0444);
+static int vmpck_id = -1;
+module_param(vmpck_id, int, 0444);
 MODULE_PARM_DESC(vmpck_id, "The VMPCK ID to use when communicating with the PSP.");
 
 /* Mutex to serialize the shared buffer access and command handling. */
@@ -923,6 +923,10 @@ static int __init sev_guest_probe(struct platform_device *pdev)
 	if (!snp_dev)
 		goto e_unmap;
 
+	/* Adjust the default VMPCK key based on the executing VMPL level */
+	if (vmpck_id == -1)
+		vmpck_id = snp_get_vmpl();
+
 	ret = -EINVAL;
 	snp_dev->vmpck = get_vmpck(vmpck_id, layout, &snp_dev->os_area_msg_seqno);
 	if (!snp_dev->vmpck) {
-- 
2.43.2


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

* [PATCH v3 10/14] configfs-tsm: Allow the privlevel_floor attribute to be updated
  2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
                   ` (8 preceding siblings ...)
  2024-03-25 22:26 ` [PATCH v3 09/14] virt: sev-guest: Choose the VMPCK key based on executing VMPL Tom Lendacky
@ 2024-03-25 22:26 ` Tom Lendacky
  2024-04-16  4:55   ` Dan Williams
  2024-03-25 22:26 ` [PATCH v3 11/14] x86/sev: Extend the config-fs attestation support for an SVSM Tom Lendacky
                   ` (3 subsequent siblings)
  13 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-03-25 22:26 UTC (permalink / raw)
  To: linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

With the introduction of an SVSM, Linux will be running at a non-zero
VMPL. Any request for an attestation report at a higher priviledge VMPL
than what Linux is currently running will result in an error. Allow for
the privlevel_floor attribute to be updated dynamically so that the
attribute may be set dynamically.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 drivers/virt/coco/sev-guest/sev-guest.c | 5 ++++-
 include/linux/tsm.h                     | 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
index 1ff897913bf4..bba6531cb606 100644
--- a/drivers/virt/coco/sev-guest/sev-guest.c
+++ b/drivers/virt/coco/sev-guest/sev-guest.c
@@ -885,7 +885,7 @@ static int sev_report_new(struct tsm_report *report, void *data)
 	return 0;
 }
 
-static const struct tsm_ops sev_tsm_ops = {
+static struct tsm_ops sev_tsm_ops = {
 	.name = KBUILD_MODNAME,
 	.report_new = sev_report_new,
 };
@@ -972,6 +972,9 @@ static int __init sev_guest_probe(struct platform_device *pdev)
 	snp_dev->input.resp_gpa = __pa(snp_dev->response);
 	snp_dev->input.data_gpa = __pa(snp_dev->certs_data);
 
+	/* Set the privlevel_floor attribute based on the current VMPL */
+	sev_tsm_ops.privlevel_floor = snp_get_vmpl();
+
 	ret = tsm_register(&sev_tsm_ops, snp_dev, &tsm_report_extra_type);
 	if (ret)
 		goto e_free_cert_data;
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
index de8324a2223c..50c5769657d8 100644
--- a/include/linux/tsm.h
+++ b/include/linux/tsm.h
@@ -54,7 +54,7 @@ struct tsm_report {
  */
 struct tsm_ops {
 	const char *name;
-	const unsigned int privlevel_floor;
+	unsigned int privlevel_floor;
 	int (*report_new)(struct tsm_report *report, void *data);
 };
 
-- 
2.43.2


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

* [PATCH v3 11/14] x86/sev: Extend the config-fs attestation support for an SVSM
  2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
                   ` (9 preceding siblings ...)
  2024-03-25 22:26 ` [PATCH v3 10/14] configfs-tsm: Allow the privlevel_floor attribute to be updated Tom Lendacky
@ 2024-03-25 22:26 ` Tom Lendacky
  2024-04-16  5:37   ` Dan Williams
  2024-03-25 22:26 ` [PATCH v3 12/14] fs/configfs: Add a callback to determine attribute visibility Tom Lendacky
                   ` (2 subsequent siblings)
  13 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-03-25 22:26 UTC (permalink / raw)
  To: linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

When an SVSM is present, the guest can also request attestation reports
from the SVSM. These SVSM attestation reports can be used to attest the
SVSM and any services running within the SVSM.

Extend the config-fs attestation support to allow for an SVSM attestation
report. This involves creating four (4) new config-fs attributes:

  - 'service-provider' (input)
    This attribute is used to determine whether the attestation request
    should be sent to the specified service provider or to the SEV
    firmware. The SVSM service provider is represented by the value
    'svsm'.

  - 'service_guid' (input)
    Used for requesting the attestation of a single service within the
    service provider. A null GUID implies that the SVSM_ATTEST_SERVICES
    call should be used to request the attestation report. A non-null
    GUID implies that the SVSM_ATTEST_SINGLE_SERVICE call should be used.

  - 'service_manifest_version' (input)
    Used with the SVSM_ATTEST_SINGLE_SERVICE call, the service version
    represents a specific service manifest version be used for the
    attestation report.

  - 'manifestblob' (output)
    Used to return the service manifest associated with the attestation
    report.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 Documentation/ABI/testing/configfs-tsm  |  69 +++++++++++
 arch/x86/include/asm/sev.h              |  31 ++++-
 arch/x86/kernel/sev.c                   |  50 ++++++++
 drivers/virt/coco/sev-guest/sev-guest.c | 151 ++++++++++++++++++++++++
 drivers/virt/coco/tsm.c                 |  93 ++++++++++++++-
 include/linux/tsm.h                     |  11 ++
 6 files changed, 402 insertions(+), 3 deletions(-)

diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
index dd24202b5ba5..72a7acdb5258 100644
--- a/Documentation/ABI/testing/configfs-tsm
+++ b/Documentation/ABI/testing/configfs-tsm
@@ -31,6 +31,21 @@ Description:
 		Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ.
 		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
 
+What:		/sys/kernel/config/tsm/report/$name/manifestblob
+Date:		January, 2024
+KernelVersion:	v6.10
+Contact:	linux-coco@lists.linux.dev
+Description:
+		(RO) Optional supplemental data that a TSM may emit, visibility
+		of this attribute depends on TSM, and may be empty if no
+		manifest data is available.
+
+		When @provider is "sev_guest" and the @service_provider is
+		"svsm" this file contains the service manifest used for the SVSM
+		attestation report from the Secure VM Service Module for SEV-SNP
+		Guests v1.00 Section 7.
+		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
+
 What:		/sys/kernel/config/tsm/report/$name/provider
 Date:		September, 2023
 KernelVersion:	v6.7
@@ -80,3 +95,57 @@ Contact:	linux-coco@lists.linux.dev
 Description:
 		(RO) Indicates the minimum permissible value that can be written
 		to @privlevel.
+
+What:		/sys/kernel/config/tsm/report/$name/service_provider
+Date:		January, 2024
+KernelVersion:	v6.10
+Contact:	linux-coco@lists.linux.dev
+Description:
+		(WO) Attribute is visible if a TSM implementation provider
+		supports the concept of attestation reports from a service
+		provider for TVMs, like SEV-SNP running under an SVSM.
+		Specifying the service provider via this attribute will create
+		an attestation report as specified by the service provider.
+		Currently supported service-providers are:
+			svsm
+
+		For the SVSM service provider, see the Secure VM Service Module
+		for SEV-SNP Guests v1.00 Section 7.
+		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
+
+What:		/sys/kernel/config/tsm/report/$name/service_guid
+Date:		January, 2024
+KernelVersion:	v6.10
+Contact:	linux-coco@lists.linux.dev
+Description:
+		(WO) Attribute is visible if a TSM implementation provider
+		supports the concept of attestation reports from a service
+		provider for TVMs, like SEV-SNP running under an SVSM.
+		Specifying an empty/null GUID (00000000-0000-0000-0000-000000)
+		requests all active services within the service provider be
+		part of the attestation report. Specifying a GUID request
+		an attestation report of just the specified service using the
+		manifest form specified by the service_manifest_version
+		attribute.
+
+		For the SVSM service provider, see the Secure VM Service Module
+		for SEV-SNP Guests v1.00 Section 7.
+		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
+
+What:		/sys/kernel/config/tsm/report/$name/service_manifest_version
+Date:		January, 2024
+KernelVersion:	v6.10
+Contact:	linux-coco@lists.linux.dev
+Description:
+		(WO) Attribute is visible if a TSM implementation provider
+		supports the concept of attestation reports from a service
+		provider for TVMs, like SEV-SNP running under an SVSM.
+		Indicates the service manifest version requested for the
+		attestation report. If this field is not set by the user,
+		the default manifest version of the service (the service's
+		initial/first manifest version) is returned. The initial
+		manifest version is always available.
+
+		For the SVSM service provider, see the Secure VM Service Module
+		for SEV-SNP Guests v1.00 Section 7.
+		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index 066eb0ba3d63..94af7fb7a8e1 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -209,6 +209,27 @@ struct svsm_pvalidate_call {
 	struct svsm_pvalidate_entry entry[];
 };
 
+/*
+ * The SVSM Attestation related structures
+ */
+struct svsm_location_entry {
+	u64 pa;
+	u32 len;
+	u8 rsvd[4];
+};
+
+struct svsm_attestation_call {
+	struct svsm_location_entry report_buffer;
+	struct svsm_location_entry nonce;
+	struct svsm_location_entry manifest_buffer;
+	struct svsm_location_entry certificates_buffer;
+
+	/* For attesting a single service */
+	u8 service_guid[16];
+	u32 service_manifest_version;
+	u8 rsvd[4];
+};
+
 /*
  * SVSM protocol structure
  */
@@ -232,6 +253,10 @@ struct svsm_call {
 #define SVSM_CORE_CREATE_VCPU		2
 #define SVSM_CORE_DELETE_VCPU		3
 
+#define SVSM_ATTEST_CALL(x)		((1ULL << 32) | (x))
+#define SVSM_ATTEST_SERVICES		0
+#define SVSM_ATTEST_SINGLE_SERVICE	1
+
 #ifdef CONFIG_AMD_MEM_ENCRYPT
 extern void __sev_es_ist_enter(struct pt_regs *regs);
 extern void __sev_es_ist_exit(void);
@@ -302,6 +327,7 @@ void snp_set_wakeup_secondary_cpu(void);
 bool snp_init(struct boot_params *bp);
 void __noreturn snp_abort(void);
 int snp_issue_guest_request(u64 exit_code, struct snp_req_data *input, struct snp_guest_request_ioctl *rio);
+int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input);
 void snp_accept_memory(phys_addr_t start, phys_addr_t end);
 u64 snp_get_unsupported_features(u64 status);
 u64 sev_get_status(void);
@@ -333,7 +359,10 @@ static inline int snp_issue_guest_request(u64 exit_code, struct snp_req_data *in
 {
 	return -ENOTTY;
 }
-
+static inline int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input)
+{
+	return -ENOTTY;
+}
 static inline void snp_accept_memory(phys_addr_t start, phys_addr_t end) { }
 static inline u64 snp_get_unsupported_features(u64 status) { return 0; }
 static inline u64 sev_get_status(void) { return 0; }
diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index 7e2b9934a95d..0a06632898c6 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -2400,6 +2400,56 @@ static int __init init_sev_config(char *str)
 }
 __setup("sev=", init_sev_config);
 
+static void update_attestation_input(struct svsm_call *call, struct svsm_attestation_call *input)
+{
+	/* If (new) lengths have been returned, propograte them up */
+	if (call->rcx_out != call->rcx)
+		input->manifest_buffer.len = call->rcx_out;
+
+	if (call->rdx_out != call->rdx)
+		input->certificates_buffer.len = call->rdx_out;
+
+	if (call->r8_out != call->r8)
+		input->report_buffer.len = call->r8_out;
+}
+
+int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input)
+{
+	struct svsm_attestation_call *attest_call;
+	struct svsm_call call = {};
+	unsigned long flags;
+	u64 attest_call_pa;
+	int ret;
+
+	if (!vmpl)
+		return -EINVAL;
+
+	local_irq_save(flags);
+
+	call.caa = __svsm_get_caa();
+
+	attest_call = (struct svsm_attestation_call *)call.caa->svsm_buffer;
+	attest_call_pa = __svsm_get_caa_pa() + offsetof(struct svsm_ca, svsm_buffer);
+
+	*attest_call = *input;
+
+	/*
+	 * Set input registers for the request and set RDX and R8 to known
+	 * values in order to detect length values being returned in them.
+	 */
+	call.rax = call_id;
+	call.rcx = attest_call_pa;
+	call.rdx = -1;
+	call.r8 = -1;
+	ret = svsm_protocol(&call);
+	update_attestation_input(&call, input);
+
+	local_irq_restore(flags);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(snp_issue_svsm_attestation_request);
+
 int snp_issue_guest_request(u64 exit_code, struct snp_req_data *input, struct snp_guest_request_ioctl *rio)
 {
 	struct ghcb_state state;
diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
index bba6531cb606..0d2c9926a97c 100644
--- a/drivers/virt/coco/sev-guest/sev-guest.c
+++ b/drivers/virt/coco/sev-guest/sev-guest.c
@@ -38,6 +38,8 @@
 #define SNP_REQ_MAX_RETRY_DURATION	(60*HZ)
 #define SNP_REQ_RETRY_DELAY		(2*HZ)
 
+#define SVSM_MAX_RETRIES		3
+
 struct snp_guest_crypto {
 	struct crypto_aead *tfm;
 	u8 *iv, *authtag;
@@ -783,6 +785,148 @@ struct snp_msg_cert_entry {
 	u32 length;
 };
 
+static int sev_svsm_report_new(struct tsm_report *report, void *data)
+{
+	unsigned int report_len, manifest_len, certificates_len;
+	void *report_blob, *manifest_blob, *certificates_blob;
+	struct svsm_attestation_call attest_call = {};
+	struct tsm_desc *desc = &report->desc;
+	unsigned int retry_count;
+	unsigned int size;
+	bool try_again;
+	void *buffer;
+	u64 call_id;
+	int ret;
+
+	/*
+	 * Allocate pages for the request:
+	 * - Report blob (4K)
+	 * - Manifest blob (4K)
+	 * - Certificate blob (16K)
+	 *
+	 * Above addresses must be 4K aligned
+	 */
+	report_len = SZ_4K;
+	manifest_len = SZ_4K;
+	certificates_len = SEV_FW_BLOB_MAX_SIZE;
+
+	if (guid_is_null(&desc->service_guid)) {
+		call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SERVICES);
+	} else {
+		export_guid(attest_call.service_guid, &desc->service_guid);
+		attest_call.service_manifest_version = desc->service_manifest_version;
+
+		call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SINGLE_SERVICE);
+	}
+
+	retry_count = 0;
+
+retry:
+	size = report_len + manifest_len + certificates_len;
+	buffer = alloc_pages_exact(size, __GFP_ZERO);
+	if (!buffer)
+		return -ENOMEM;
+
+	report_blob = buffer;
+	attest_call.report_buffer.pa = __pa(report_blob);
+	attest_call.report_buffer.len = report_len;
+
+	manifest_blob = report_blob + report_len;
+	attest_call.manifest_buffer.pa = __pa(manifest_blob);
+	attest_call.manifest_buffer.len = manifest_len;
+
+	certificates_blob = manifest_blob + manifest_len;
+	attest_call.certificates_buffer.pa = __pa(certificates_blob);
+	attest_call.certificates_buffer.len = certificates_len;
+
+	attest_call.nonce.pa = __pa(desc->inblob);
+	attest_call.nonce.len = desc->inblob_len;
+
+	ret = snp_issue_svsm_attestation_request(call_id, &attest_call);
+	switch (ret) {
+	case SVSM_SUCCESS:
+		break;
+	case SVSM_ERR_INVALID_PARAMETER:
+		ret = -EINVAL;
+
+		if (retry_count >= SVSM_MAX_RETRIES)
+			goto error;
+
+		try_again = false;
+
+		if (attest_call.report_buffer.len > report_len) {
+			report_len = PAGE_ALIGN(attest_call.report_buffer.len);
+			try_again = true;
+		}
+
+		if (attest_call.manifest_buffer.len > manifest_len) {
+			manifest_len = PAGE_ALIGN(attest_call.manifest_buffer.len);
+			try_again = true;
+		}
+
+		if (attest_call.certificates_buffer.len > certificates_len) {
+			certificates_len = PAGE_ALIGN(attest_call.certificates_buffer.len);
+			try_again = true;
+		}
+
+		/* If one of the buffers wasn't large enough, retry the request */
+		if (try_again) {
+			free_pages_exact(buffer, size);
+			retry_count++;
+			goto retry;
+		}
+
+		goto error;
+	case SVSM_ERR_BUSY:
+		ret = -EAGAIN;
+		goto error;
+	default:
+		pr_err_ratelimited("SVSM attestation request failed (%#x)\n", ret);
+		ret = -EINVAL;
+		goto error;
+	}
+
+	ret = -ENOMEM;
+
+	report_len = attest_call.report_buffer.len;
+	void *rbuf __free(kvfree) = kvzalloc(report_len, GFP_KERNEL);
+	if (!rbuf)
+		goto error;
+
+	memcpy(rbuf, report_blob, report_len);
+	report->outblob = no_free_ptr(rbuf);
+	report->outblob_len = report_len;
+
+	manifest_len = attest_call.manifest_buffer.len;
+	void *mbuf __free(kvfree) = kvzalloc(manifest_len, GFP_KERNEL);
+	if (!mbuf)
+		goto error;
+
+	memcpy(mbuf, manifest_blob, manifest_len);
+	report->manifestblob = no_free_ptr(mbuf);
+	report->manifestblob_len = manifest_len;
+
+	certificates_len = attest_call.certificates_buffer.len;
+	if (!certificates_len)
+		goto success;
+
+	void *cbuf __free(kvfree) = kvzalloc(certificates_len, GFP_KERNEL);
+	if (!cbuf)
+		goto error;
+
+	memcpy(cbuf, certificates_blob, certificates_len);
+	report->auxblob = no_free_ptr(cbuf);
+	report->auxblob_len = certificates_len;
+
+success:
+	ret = 0;
+
+error:
+	free_pages_exact(buffer, size);
+
+	return ret;
+}
+
 static int sev_report_new(struct tsm_report *report, void *data)
 {
 	struct snp_msg_cert_entry *cert_table;
@@ -797,6 +941,13 @@ static int sev_report_new(struct tsm_report *report, void *data)
 	if (desc->inblob_len != SNP_REPORT_USER_DATA_SIZE)
 		return -EINVAL;
 
+	if (desc->service_provider) {
+		if (strcmp(desc->service_provider, "svsm"))
+			return -EINVAL;
+
+		return sev_svsm_report_new(report, data);
+	}
+
 	void *buf __free(kvfree) = kvzalloc(size, GFP_KERNEL);
 	if (!buf)
 		return -ENOMEM;
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
index d1c2db83a8ca..46f230bf13ac 100644
--- a/drivers/virt/coco/tsm.c
+++ b/drivers/virt/coco/tsm.c
@@ -35,7 +35,7 @@ static DECLARE_RWSEM(tsm_rwsem);
  * The attestation report format is TSM provider specific, when / if a standard
  * materializes that can be published instead of the vendor layout. Until then
  * the 'provider' attribute indicates the format of 'outblob', and optionally
- * 'auxblob'.
+ * 'auxblob' and 'manifestblob'.
  */
 
 struct tsm_report_state {
@@ -48,6 +48,7 @@ struct tsm_report_state {
 enum tsm_data_select {
 	TSM_REPORT,
 	TSM_CERTS,
+	TSM_MANIFEST,
 };
 
 static struct tsm_report *to_tsm_report(struct config_item *cfg)
@@ -119,6 +120,74 @@ static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
 }
 CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
 
+static ssize_t tsm_report_service_provider_store(struct config_item *cfg,
+						 const char *buf, size_t len)
+{
+	struct tsm_report *report = to_tsm_report(cfg);
+	size_t sp_len;
+	char *sp;
+	int rc;
+
+	guard(rwsem_write)(&tsm_rwsem);
+	rc = try_advance_write_generation(report);
+	if (rc)
+		return rc;
+
+	sp_len = (buf[len - 1] != '\n') ? len : len - 1;
+
+	sp = kstrndup(buf, sp_len, GFP_KERNEL);
+	if (!sp)
+		return -ENOMEM;
+	kfree(report->desc.service_provider);
+
+	report->desc.service_provider = sp;
+
+	return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, service_provider);
+
+static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
+					     const char *buf, size_t len)
+{
+	struct tsm_report *report = to_tsm_report(cfg);
+	int rc;
+
+	guard(rwsem_write)(&tsm_rwsem);
+	rc = try_advance_write_generation(report);
+	if (rc)
+		return rc;
+
+	report->desc.service_guid = guid_null;
+
+	rc = guid_parse(buf, &report->desc.service_guid);
+	if (rc)
+		return rc;
+
+	return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, service_guid);
+
+static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg,
+							 const char *buf, size_t len)
+{
+	struct tsm_report *report = to_tsm_report(cfg);
+	unsigned int val;
+	int rc;
+
+	rc = kstrtouint(buf, 0, &val);
+	if (rc)
+		return rc;
+
+	guard(rwsem_write)(&tsm_rwsem);
+	rc = try_advance_write_generation(report);
+	if (rc)
+		return rc;
+	report->desc.service_manifest_version = val;
+
+	return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, service_manifest_version);
+
 static ssize_t tsm_report_inblob_write(struct config_item *cfg,
 				       const void *buf, size_t count)
 {
@@ -163,6 +232,9 @@ static ssize_t __read_report(struct tsm_report *report, void *buf, size_t count,
 	if (select == TSM_REPORT) {
 		out = report->outblob;
 		len = report->outblob_len;
+	} else if (select == TSM_MANIFEST) {
+		out = report->manifestblob;
+		len = report->manifestblob_len;
 	} else {
 		out = report->auxblob;
 		len = report->auxblob_len;
@@ -188,7 +260,7 @@ static ssize_t read_cached_report(struct tsm_report *report, void *buf,
 
 	/*
 	 * A given TSM backend always fills in ->outblob regardless of
-	 * whether the report includes an auxblob or not.
+	 * whether the report includes an auxblob/manifestblob or not.
 	 */
 	if (!report->outblob ||
 	    state->read_generation != state->write_generation)
@@ -224,8 +296,10 @@ static ssize_t tsm_report_read(struct tsm_report *report, void *buf,
 
 	kvfree(report->outblob);
 	kvfree(report->auxblob);
+	kvfree(report->manifestblob);
 	report->outblob = NULL;
 	report->auxblob = NULL;
+	report->manifestblob = NULL;
 	rc = ops->report_new(report, provider.data);
 	if (rc < 0)
 		return rc;
@@ -252,6 +326,15 @@ static ssize_t tsm_report_auxblob_read(struct config_item *cfg, void *buf,
 }
 CONFIGFS_BIN_ATTR_RO(tsm_report_, auxblob, NULL, TSM_OUTBLOB_MAX);
 
+static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,
+					    size_t count)
+{
+	struct tsm_report *report = to_tsm_report(cfg);
+
+	return tsm_report_read(report, buf, count, TSM_MANIFEST);
+}
+CONFIGFS_BIN_ATTR_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX);
+
 #define TSM_DEFAULT_ATTRS() \
 	&tsm_report_attr_generation, \
 	&tsm_report_attr_provider
@@ -265,6 +348,9 @@ static struct configfs_attribute *tsm_report_extra_attrs[] = {
 	TSM_DEFAULT_ATTRS(),
 	&tsm_report_attr_privlevel,
 	&tsm_report_attr_privlevel_floor,
+	&tsm_report_attr_service_provider,
+	&tsm_report_attr_service_guid,
+	&tsm_report_attr_service_manifest_version,
 	NULL,
 };
 
@@ -280,6 +366,7 @@ static struct configfs_bin_attribute *tsm_report_bin_attrs[] = {
 static struct configfs_bin_attribute *tsm_report_bin_extra_attrs[] = {
 	TSM_DEFAULT_BIN_ATTRS(),
 	&tsm_report_attr_auxblob,
+	&tsm_report_attr_manifestblob,
 	NULL,
 };
 
@@ -288,8 +375,10 @@ static void tsm_report_item_release(struct config_item *cfg)
 	struct tsm_report *report = to_tsm_report(cfg);
 	struct tsm_report_state *state = to_state(report);
 
+	kvfree(report->manifestblob);
 	kvfree(report->auxblob);
 	kvfree(report->outblob);
+	kfree(report->desc.service_provider);
 	kfree(state);
 }
 
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
index 50c5769657d8..27cc97fe8dcd 100644
--- a/include/linux/tsm.h
+++ b/include/linux/tsm.h
@@ -4,6 +4,7 @@
 
 #include <linux/sizes.h>
 #include <linux/types.h>
+#include <linux/uuid.h>
 
 #define TSM_INBLOB_MAX 64
 #define TSM_OUTBLOB_MAX SZ_32K
@@ -19,11 +20,17 @@
  * @privlevel: optional privilege level to associate with @outblob
  * @inblob_len: sizeof @inblob
  * @inblob: arbitrary input data
+ * @service_provider: optional name of where to obtain the tsm report blob
+ * @service_guid: optional service-provider service guid to attest
+ * @service_manifest_version: optional service-provider service manifest version requested
  */
 struct tsm_desc {
 	unsigned int privlevel;
 	size_t inblob_len;
 	u8 inblob[TSM_INBLOB_MAX];
+	char *service_provider;
+	guid_t service_guid;
+	unsigned int service_manifest_version;
 };
 
 /**
@@ -33,6 +40,8 @@ struct tsm_desc {
  * @outblob: generated evidence to provider to the attestation agent
  * @auxblob_len: sizeof(@auxblob)
  * @auxblob: (optional) auxiliary data to the report (e.g. certificate data)
+ * @manifestblob_len: sizeof(@manifestblob)
+ * @manifestblob: (optional) manifest data associated with the report
  */
 struct tsm_report {
 	struct tsm_desc desc;
@@ -40,6 +49,8 @@ struct tsm_report {
 	u8 *outblob;
 	size_t auxblob_len;
 	u8 *auxblob;
+	size_t manifestblob_len;
+	u8 *manifestblob;
 };
 
 /**
-- 
2.43.2


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

* [PATCH v3 12/14] fs/configfs: Add a callback to determine attribute visibility
  2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
                   ` (10 preceding siblings ...)
  2024-03-25 22:26 ` [PATCH v3 11/14] x86/sev: Extend the config-fs attestation support for an SVSM Tom Lendacky
@ 2024-03-25 22:26 ` Tom Lendacky
  2024-04-16  5:46   ` Dan Williams
  2024-03-25 22:26 ` [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM Tom Lendacky
  2024-03-25 22:26 ` [PATCH v3 14/14] x86/sev: Allow non-VMPL0 execution when an SVSM is present Tom Lendacky
  13 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-03-25 22:26 UTC (permalink / raw)
  To: linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra, Joel Becker, Christoph Hellwig

In order to support dynamic decisions as to whether an attribute should be
created, add a callback that returns a bool to indicate whether the
attribute should be display. If no callback is registered, the attribute
is displayed by default.

Cc: Joel Becker <jlbec@evilplan.org>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 fs/configfs/file.c       |   7 +++
 include/linux/configfs.h | 111 +++++++++++++++++++++++++++------------
 2 files changed, 84 insertions(+), 34 deletions(-)

diff --git a/fs/configfs/file.c b/fs/configfs/file.c
index 0ad32150611e..a976c183756c 100644
--- a/fs/configfs/file.c
+++ b/fs/configfs/file.c
@@ -451,6 +451,9 @@ int configfs_create_file(struct config_item * item, const struct configfs_attrib
 	umode_t mode = (attr->ca_mode & S_IALLUGO) | S_IFREG;
 	int error = 0;
 
+	if (attr->is_visible && !attr->is_visible(item, attr))
+		return 0;
+
 	inode_lock_nested(d_inode(dir), I_MUTEX_NORMAL);
 	error = configfs_make_dirent(parent_sd, NULL, (void *) attr, mode,
 				     CONFIGFS_ITEM_ATTR, parent_sd->s_frag);
@@ -470,9 +473,13 @@ int configfs_create_bin_file(struct config_item *item,
 {
 	struct dentry *dir = item->ci_dentry;
 	struct configfs_dirent *parent_sd = dir->d_fsdata;
+	const struct configfs_attribute *attr = &bin_attr->cb_attr;
 	umode_t mode = (bin_attr->cb_attr.ca_mode & S_IALLUGO) | S_IFREG;
 	int error = 0;
 
+	if (attr->is_visible && !attr->is_visible(item, attr))
+		return 0;
+
 	inode_lock_nested(dir->d_inode, I_MUTEX_NORMAL);
 	error = configfs_make_dirent(parent_sd, NULL, (void *) bin_attr, mode,
 				     CONFIGFS_ITEM_BIN_ATTR, parent_sd->s_frag);
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 2606711adb18..c836d7bc7c9e 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -116,35 +116,57 @@ struct configfs_attribute {
 	const char		*ca_name;
 	struct module 		*ca_owner;
 	umode_t			ca_mode;
+	bool (*is_visible)(const struct config_item *, const struct configfs_attribute *);
 	ssize_t (*show)(struct config_item *, char *);
 	ssize_t (*store)(struct config_item *, const char *, size_t);
 };
 
-#define CONFIGFS_ATTR(_pfx, _name)			\
+#define __CONFIGFS_ATTR(_pfx, _name, _vis)		\
 static struct configfs_attribute _pfx##attr_##_name = {	\
 	.ca_name	= __stringify(_name),		\
 	.ca_mode	= S_IRUGO | S_IWUSR,		\
 	.ca_owner	= THIS_MODULE,			\
+	.is_visible	= _vis,				\
 	.show		= _pfx##_name##_show,		\
 	.store		= _pfx##_name##_store,		\
 }
 
-#define CONFIGFS_ATTR_RO(_pfx, _name)			\
+#define __CONFIGFS_ATTR_RO(_pfx, _name, _vis)		\
 static struct configfs_attribute _pfx##attr_##_name = {	\
 	.ca_name	= __stringify(_name),		\
 	.ca_mode	= S_IRUGO,			\
 	.ca_owner	= THIS_MODULE,			\
+	.is_visible	= _vis,				\
 	.show		= _pfx##_name##_show,		\
 }
 
-#define CONFIGFS_ATTR_WO(_pfx, _name)			\
+#define __CONFIGFS_ATTR_WO(_pfx, _name, _vis)		\
 static struct configfs_attribute _pfx##attr_##_name = {	\
 	.ca_name	= __stringify(_name),		\
 	.ca_mode	= S_IWUSR,			\
 	.ca_owner	= THIS_MODULE,			\
+	.is_visible	= _vis,				\
 	.store		= _pfx##_name##_store,		\
 }
 
+#define CONFIGFS_ATTR(_pfx, _name)			\
+	__CONFIGFS_ATTR(_pfx, _name, NULL)
+
+#define CONFIGFS_ATTR_RO(_pfx, _name)			\
+	__CONFIGFS_ATTR_RO(_pfx, _name, NULL)
+
+#define CONFIGFS_ATTR_WO(_pfx, _name)			\
+	__CONFIGFS_ATTR_WO(_pfx, _name, NULL)
+
+#define CONFIGFS_ATTR_VISIBLE(_pfx, _name, _vis)	\
+	__CONFIGFS_ATTR(_pfx, _name, _vis)
+
+#define CONFIGFS_ATTR_VISIBLE_RO(_pfx, _name, _vis)	\
+	__CONFIGFS_ATTR_RO(_pfx, _name, _vis)
+
+#define CONFIGFS_ATTR_VISIBLE_WO(_pfx, _name, _vis)	\
+	__CONFIGFS_ATTR_WO(_pfx, _name, _vis)
+
 struct file;
 struct vm_area_struct;
 
@@ -156,43 +178,64 @@ struct configfs_bin_attribute {
 	ssize_t (*write)(struct config_item *, const void *, size_t);
 };
 
-#define CONFIGFS_BIN_ATTR(_pfx, _name, _priv, _maxsz)		\
-static struct configfs_bin_attribute _pfx##attr_##_name = {	\
-	.cb_attr = {						\
-		.ca_name	= __stringify(_name),		\
-		.ca_mode	= S_IRUGO | S_IWUSR,		\
-		.ca_owner	= THIS_MODULE,			\
-	},							\
-	.cb_private	= _priv,				\
-	.cb_max_size	= _maxsz,				\
-	.read		= _pfx##_name##_read,			\
-	.write		= _pfx##_name##_write,			\
+#define __CONFIGFS_BIN_ATTR(_pfx, _name, _priv, _maxsz, _vis)		\
+static struct configfs_bin_attribute _pfx##attr_##_name = {		\
+	.cb_attr = {							\
+		.ca_name	= __stringify(_name),			\
+		.ca_mode	= S_IRUGO | S_IWUSR,			\
+		.ca_owner	= THIS_MODULE,				\
+		.is_visible	= _vis,					\
+	},								\
+	.cb_private	= _priv,					\
+	.cb_max_size	= _maxsz,					\
+	.read		= _pfx##_name##_read,				\
+	.write		= _pfx##_name##_write,				\
 }
 
-#define CONFIGFS_BIN_ATTR_RO(_pfx, _name, _priv, _maxsz)	\
-static struct configfs_bin_attribute _pfx##attr_##_name = {	\
-	.cb_attr = {						\
-		.ca_name	= __stringify(_name),		\
-		.ca_mode	= S_IRUGO,			\
-		.ca_owner	= THIS_MODULE,			\
-	},							\
-	.cb_private	= _priv,				\
-	.cb_max_size	= _maxsz,				\
-	.read		= _pfx##_name##_read,			\
+#define __CONFIGFS_BIN_ATTR_RO(_pfx, _name, _priv, _maxsz, _vis)	\
+static struct configfs_bin_attribute _pfx##attr_##_name = {		\
+	.cb_attr = {							\
+		.ca_name	= __stringify(_name),			\
+		.ca_mode	= S_IRUGO,				\
+		.ca_owner	= THIS_MODULE,				\
+		.is_visible	= _vis,					\
+	},								\
+	.cb_private	= _priv,					\
+	.cb_max_size	= _maxsz,					\
+	.read		= _pfx##_name##_read,				\
 }
 
-#define CONFIGFS_BIN_ATTR_WO(_pfx, _name, _priv, _maxsz)	\
-static struct configfs_bin_attribute _pfx##attr_##_name = {	\
-	.cb_attr = {						\
-		.ca_name	= __stringify(_name),		\
-		.ca_mode	= S_IWUSR,			\
-		.ca_owner	= THIS_MODULE,			\
-	},							\
-	.cb_private	= _priv,				\
-	.cb_max_size	= _maxsz,				\
-	.write		= _pfx##_name##_write,			\
+#define __CONFIGFS_BIN_ATTR_WO(_pfx, _name, _priv, _maxsz, _vis)	\
+static struct configfs_bin_attribute _pfx##attr_##_name = {		\
+	.cb_attr = {							\
+		.ca_name	= __stringify(_name),			\
+		.ca_mode	= S_IWUSR,				\
+		.ca_owner	= THIS_MODULE,				\
+		.is_visible	= _vis,					\
+	},								\
+	.cb_private	= _priv,					\
+	.cb_max_size	= _maxsz,					\
+	.write		= _pfx##_name##_write,				\
 }
 
+#define CONFIGFS_BIN_ATTR(_pfx, _name, _priv, _maxsz)			\
+	__CONFIGFS_BIN_ATTR(_pfx, _name, _priv, _maxsz, NULL)
+
+#define CONFIGFS_BIN_ATTR_RO(_pfx, _name, _priv, _maxsz)		\
+	__CONFIGFS_BIN_ATTR_RO(_pfx, _name, _priv, _maxsz, NULL)
+
+#define CONFIGFS_BIN_ATTR_WO(_pfx, _name, _priv, _maxsz)		\
+	__CONFIGFS_BIN_ATTR_WO(_pfx, _name, _priv, _maxsz, NULL)
+
+#define CONFIGFS_BIN_ATTR_VISIBLE(_pfx, _name, _priv, _maxs, _vis)	\
+	__CONFIGFS_BIN_ATTR(_pfx, _name, _priv, _maxsz, _vis)
+
+#define CONFIGFS_BIN_ATTR_VISIBLE_RO(_pfx, _name, _priv, _maxsz, _vis)	\
+	__CONFIGFS_BIN_ATTR_RO(_pfx, _name, _priv, _maxsz, _vis)
+
+#define CONFIGFS_BIN_ATTR_VISIBLE_WO(_pfx, _name, _priv, _maxsz, _vis)	\
+	__CONFIGFS_BIN_ATTR_WO(_pfx, _name, _priv, _maxsz, _vis)
+
 /*
  * If allow_link() exists, the item can symlink(2) out to other
  * items.  If the item is a group, it may support mkdir(2).
-- 
2.43.2


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

* [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
  2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
                   ` (11 preceding siblings ...)
  2024-03-25 22:26 ` [PATCH v3 12/14] fs/configfs: Add a callback to determine attribute visibility Tom Lendacky
@ 2024-03-25 22:26 ` Tom Lendacky
  2024-04-09 18:12   ` Kuppuswamy Sathyanarayanan
                     ` (2 more replies)
  2024-03-25 22:26 ` [PATCH v3 14/14] x86/sev: Allow non-VMPL0 execution when an SVSM is present Tom Lendacky
  13 siblings, 3 replies; 61+ messages in thread
From: Tom Lendacky @ 2024-03-25 22:26 UTC (permalink / raw)
  To: linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra, Joel Becker, Christoph Hellwig

Config-fs provides support to hide individual attribute entries. Using
this support, base the display of the SVSM related entries on the presence
of an SVSM.

Cc: Joel Becker <jlbec@evilplan.org>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/coco/core.c        |  4 ++++
 drivers/virt/coco/tsm.c     | 14 ++++++++++----
 include/linux/cc_platform.h |  8 ++++++++
 3 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/arch/x86/coco/core.c b/arch/x86/coco/core.c
index d07be9d05cd0..efa0f648f754 100644
--- a/arch/x86/coco/core.c
+++ b/arch/x86/coco/core.c
@@ -12,6 +12,7 @@
 
 #include <asm/coco.h>
 #include <asm/processor.h>
+#include <asm/sev.h>
 
 enum cc_vendor cc_vendor __ro_after_init = CC_VENDOR_NONE;
 u64 cc_mask __ro_after_init;
@@ -78,6 +79,9 @@ static bool noinstr amd_cc_platform_has(enum cc_attr attr)
 	case CC_ATTR_GUEST_STATE_ENCRYPT:
 		return sev_status & MSR_AMD64_SEV_ES_ENABLED;
 
+	case CC_ATTR_GUEST_SVSM_PRESENT:
+		return snp_get_vmpl();
+
 	/*
 	 * With SEV, the rep string I/O instructions need to be unrolled
 	 * but SEV-ES supports them through the #VC handler.
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
index 46f230bf13ac..d30471874e87 100644
--- a/drivers/virt/coco/tsm.c
+++ b/drivers/virt/coco/tsm.c
@@ -64,6 +64,12 @@ static struct tsm_report_state *to_state(struct tsm_report *report)
 	return container_of(report, struct tsm_report_state, report);
 }
 
+static bool provider_visibility(const struct config_item *item,
+				const struct configfs_attribute *attr)
+{
+	return cc_platform_has(CC_ATTR_GUEST_SVSM_PRESENT);
+}
+
 static int try_advance_write_generation(struct tsm_report *report)
 {
 	struct tsm_report_state *state = to_state(report);
@@ -144,7 +150,7 @@ static ssize_t tsm_report_service_provider_store(struct config_item *cfg,
 
 	return len;
 }
-CONFIGFS_ATTR_WO(tsm_report_, service_provider);
+CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_provider, provider_visibility);
 
 static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
 					     const char *buf, size_t len)
@@ -165,7 +171,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
 
 	return len;
 }
-CONFIGFS_ATTR_WO(tsm_report_, service_guid);
+CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_guid, provider_visibility);
 
 static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg,
 							 const char *buf, size_t len)
@@ -186,7 +192,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg
 
 	return len;
 }
-CONFIGFS_ATTR_WO(tsm_report_, service_manifest_version);
+CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_manifest_version, provider_visibility);
 
 static ssize_t tsm_report_inblob_write(struct config_item *cfg,
 				       const void *buf, size_t count)
@@ -333,7 +339,7 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,
 
 	return tsm_report_read(report, buf, count, TSM_MANIFEST);
 }
-CONFIGFS_BIN_ATTR_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX);
+CONFIGFS_BIN_ATTR_VISIBLE_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX, provider_visibility);
 
 #define TSM_DEFAULT_ATTRS() \
 	&tsm_report_attr_generation, \
diff --git a/include/linux/cc_platform.h b/include/linux/cc_platform.h
index cb0d6cd1c12f..f1b4266c1484 100644
--- a/include/linux/cc_platform.h
+++ b/include/linux/cc_platform.h
@@ -90,6 +90,14 @@ enum cc_attr {
 	 * Examples include TDX Guest.
 	 */
 	CC_ATTR_HOTPLUG_DISABLED,
+
+	/**
+	 * @CC_ATTR_GUEST_SVSM_PRESENT: Guest is running under an SVSM
+	 *
+	 * The platform/OS is running as a guest/virtual machine and is
+	 * running under a Secure VM Service Module (SVSM).
+	 */
+	CC_ATTR_GUEST_SVSM_PRESENT,
 };
 
 #ifdef CONFIG_ARCH_HAS_CC_PLATFORM
-- 
2.43.2


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

* [PATCH v3 14/14] x86/sev: Allow non-VMPL0 execution when an SVSM is present
  2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
                   ` (12 preceding siblings ...)
  2024-03-25 22:26 ` [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM Tom Lendacky
@ 2024-03-25 22:26 ` Tom Lendacky
  13 siblings, 0 replies; 61+ messages in thread
From: Tom Lendacky @ 2024-03-25 22:26 UTC (permalink / raw)
  To: linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

To allow execution at a level other than VMPL0, an SVSM must be present.
Allow the SEV-SNP guest to continue booting if an SVSM is detected and
the hypervisor supports the SVSM feature as indicated in the GHCB
hypervisor features bitmap.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/boot/compressed/sev.c    | 11 +++++++++--
 arch/x86/include/asm/sev-common.h |  1 +
 arch/x86/kernel/sev.c             | 20 +++++++++++++++++---
 3 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
index f8407ee83ac8..974201ba2499 100644
--- a/arch/x86/boot/compressed/sev.c
+++ b/arch/x86/boot/compressed/sev.c
@@ -619,10 +619,17 @@ void sev_enable(struct boot_params *bp)
 	 * features.
 	 */
 	if (sev_status & MSR_AMD64_SEV_SNP_ENABLED) {
-		if (!(get_hv_features() & GHCB_HV_FT_SNP))
+		u64 hv_features = get_hv_features();
+
+		if (!(hv_features & GHCB_HV_FT_SNP))
 			sev_es_terminate(SEV_TERM_SET_GEN, GHCB_SNP_UNSUPPORTED);
 
-		if (!running_at_vmpl0(&boot_ghcb_page))
+		/*
+		 * VMPL0 is not required if an SVSM is present and the hypervisor
+		 * supports the required SVSM GHCB events.
+		 */
+		if (!running_at_vmpl0(&boot_ghcb_page) &&
+		    !(vmpl && (hv_features & GHCB_HV_FT_SNP_MULTI_VMPL)))
 			sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_NOT_VMPL0);
 	}
 
diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h
index 71db5ba020b9..3de377a4e981 100644
--- a/arch/x86/include/asm/sev-common.h
+++ b/arch/x86/include/asm/sev-common.h
@@ -118,6 +118,7 @@ enum psc_op {
 
 #define GHCB_HV_FT_SNP			BIT_ULL(0)
 #define GHCB_HV_FT_SNP_AP_CREATION	BIT_ULL(1)
+#define GHCB_HV_FT_SNP_MULTI_VMPL	BIT_ULL(5)
 
 /*
  * SNP Page State Change NAE event
diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index 0a06632898c6..fd3a832c65ec 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -2366,22 +2366,36 @@ static void dump_cpuid_table(void)
  * sort of indicator, and there's not really any other good place to do it,
  * so do it here.
  */
-static int __init report_cpuid_table(void)
+static void __init report_cpuid_table(void)
 {
 	const struct snp_cpuid_table *cpuid_table = snp_cpuid_get_table();
 
 	if (!cpuid_table->count)
-		return 0;
+		return;
 
 	pr_info("Using SNP CPUID table, %d entries present.\n",
 		cpuid_table->count);
 
 	if (sev_cfg.debug)
 		dump_cpuid_table();
+}
+
+static void __init report_vmpl_level(void)
+{
+	if (!cc_platform_has(CC_ATTR_GUEST_SEV_SNP))
+		return;
+
+	pr_info("SNP running at VMPL%u.\n", vmpl);
+}
+
+static int __init report_snp_info(void)
+{
+	report_vmpl_level();
+	report_cpuid_table();
 
 	return 0;
 }
-arch_initcall(report_cpuid_table);
+arch_initcall(report_snp_info);
 
 static int __init init_sev_config(char *str)
 {
-- 
2.43.2


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

* Re: [PATCH v3 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file
  2024-03-25 22:26 ` [PATCH v3 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file Tom Lendacky
@ 2024-04-09 17:09   ` Borislav Petkov
  2024-04-09 17:44     ` Tom Lendacky
  2024-04-12 16:19   ` Gupta, Pankaj
  1 sibling, 1 reply; 61+ messages in thread
From: Borislav Petkov @ 2024-04-09 17:09 UTC (permalink / raw)
  To: Tom Lendacky
  Cc: linux-kernel, x86, linux-coco, svsm-devel, Thomas Gleixner,
	Ingo Molnar, Dave Hansen, H. Peter Anvin, Andy Lutomirski,
	Peter Zijlstra, Dan Williams, Michael Roth, Ashish Kalra

On Mon, Mar 25, 2024 at 05:26:20PM -0500, Tom Lendacky wrote:
> The snp_init() in boot/compressed/sev.c is local to that file and is not
> called from outside of the file. Change the name so that it is not tied
> to the function definition in arch/x86/include/asm/sev.h.

That part I don't understand: I can rename the function without making
it static and it builds fine, so where is it "tied" to the function
definition in kernel proper?

Don't get me wrong - leaking kernel proper symbols into the decompressor
has been a pet peeve of mine for a while now but this is not the case
here, is it?

And yes, the patch is fine - I'm just asking...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

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

* Re: [PATCH v3 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file
  2024-04-09 17:09   ` Borislav Petkov
@ 2024-04-09 17:44     ` Tom Lendacky
  2024-04-09 17:57       ` Borislav Petkov
  0 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-04-09 17:44 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: linux-kernel, x86, linux-coco, svsm-devel, Thomas Gleixner,
	Ingo Molnar, Dave Hansen, H. Peter Anvin, Andy Lutomirski,
	Peter Zijlstra, Dan Williams, Michael Roth, Ashish Kalra

On 4/9/24 12:09, Borislav Petkov wrote:
> On Mon, Mar 25, 2024 at 05:26:20PM -0500, Tom Lendacky wrote:
>> The snp_init() in boot/compressed/sev.c is local to that file and is not
>> called from outside of the file. Change the name so that it is not tied
>> to the function definition in arch/x86/include/asm/sev.h.
> 
> That part I don't understand: I can rename the function without making
> it static and it builds fine, so where is it "tied" to the function
> definition in kernel proper?

When it's not static and has the name snp_init(), then it has to match 
the definition in arch/x86/include/asm/sev.h, which is really intended 
for the snp_init() in arch/x86/kernel/sev.c when called from 
arch/x86/mm/mem_encrypt_identity.c.

So, yes, changing the name would be enough except then it remains not a 
static and you can get a compiler warning about not having a prototype 
for it if the -Wmissing-prototypes option is ever applied to that file 
(I don't believe it is today because it is in the decompressor code, but 
that can change). And since nothing calls the snp_init() in 
arch/x86/boot/compressed/sev.c from outside of that file, making it 
static was appropriate.

Thanks,
Tom

> 
> Don't get me wrong - leaking kernel proper symbols into the decompressor
> has been a pet peeve of mine for a while now but this is not the case
> here, is it?
> 
> And yes, the patch is fine - I'm just asking...
> 
> Thx.
> 

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

* Re: [PATCH v3 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file
  2024-04-09 17:44     ` Tom Lendacky
@ 2024-04-09 17:57       ` Borislav Petkov
  0 siblings, 0 replies; 61+ messages in thread
From: Borislav Petkov @ 2024-04-09 17:57 UTC (permalink / raw)
  To: Tom Lendacky
  Cc: linux-kernel, x86, linux-coco, svsm-devel, Thomas Gleixner,
	Ingo Molnar, Dave Hansen, H. Peter Anvin, Andy Lutomirski,
	Peter Zijlstra, Dan Williams, Michael Roth, Ashish Kalra

On Tue, Apr 09, 2024 at 12:44:13PM -0500, Tom Lendacky wrote:
> When it's not static and has the name snp_init(), then it has to match the
> definition in arch/x86/include/asm/sev.h, which is really intended for the
> snp_init() in arch/x86/kernel/sev.c when called from
> arch/x86/mm/mem_encrypt_identity.c.
> 
> So, yes, changing the name would be enough except then it remains not a
> static and you can get a compiler warning about not having a prototype for
> it if the -Wmissing-prototypes option is ever applied to that file (I don't
> believe it is today because it is in the decompressor code, but that can
> change). And since nothing calls the snp_init() in
> arch/x86/boot/compressed/sev.c from outside of that file, making it static
> was appropriate.

Yes, then please remove all that text about what could potentially
happen from the commit message so that it is not confusing as to what
the situation *currently* is.

The two functions are independent right now. It is enough to say that
you want to differentiate which one is called when, in order to avoid
confusion.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

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

* Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
  2024-03-25 22:26 ` [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM Tom Lendacky
@ 2024-04-09 18:12   ` Kuppuswamy Sathyanarayanan
  2024-04-12 15:52     ` Tom Lendacky
  2024-04-16  5:47   ` Dan Williams
  2024-04-16  6:03   ` Dan Williams
  2 siblings, 1 reply; 61+ messages in thread
From: Kuppuswamy Sathyanarayanan @ 2024-04-09 18:12 UTC (permalink / raw)
  To: Tom Lendacky, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra, Joel Becker, Christoph Hellwig


On 3/25/24 3:26 PM, Tom Lendacky wrote:
> Config-fs provides support to hide individual attribute entries. Using
> this support, base the display of the SVSM related entries on the presence
> of an SVSM.
>
> Cc: Joel Becker <jlbec@evilplan.org>
> Cc: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
>  arch/x86/coco/core.c        |  4 ++++
>  drivers/virt/coco/tsm.c     | 14 ++++++++++----
>  include/linux/cc_platform.h |  8 ++++++++
>  3 files changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/coco/core.c b/arch/x86/coco/core.c
> index d07be9d05cd0..efa0f648f754 100644
> --- a/arch/x86/coco/core.c
> +++ b/arch/x86/coco/core.c
> @@ -12,6 +12,7 @@
>  
>  #include <asm/coco.h>
>  #include <asm/processor.h>
> +#include <asm/sev.h>
>  
>  enum cc_vendor cc_vendor __ro_after_init = CC_VENDOR_NONE;
>  u64 cc_mask __ro_after_init;
> @@ -78,6 +79,9 @@ static bool noinstr amd_cc_platform_has(enum cc_attr attr)
>  	case CC_ATTR_GUEST_STATE_ENCRYPT:
>  		return sev_status & MSR_AMD64_SEV_ES_ENABLED;
>  
> +	case CC_ATTR_GUEST_SVSM_PRESENT:
> +		return snp_get_vmpl();
> +
>  	/*
>  	 * With SEV, the rep string I/O instructions need to be unrolled
>  	 * but SEV-ES supports them through the #VC handler.
> diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
> index 46f230bf13ac..d30471874e87 100644
> --- a/drivers/virt/coco/tsm.c
> +++ b/drivers/virt/coco/tsm.c
> @@ -64,6 +64,12 @@ static struct tsm_report_state *to_state(struct tsm_report *report)
>  	return container_of(report, struct tsm_report_state, report);
>  }
>  
> +static bool provider_visibility(const struct config_item *item,
> +				const struct configfs_attribute *attr)
> +{
> +	return cc_platform_has(CC_ATTR_GUEST_SVSM_PRESENT);
> +}
> +

Any comment about the following query? I think introducing a CC flag for this use
case is over kill.

https://lore.kernel.org/lkml/6b90b223-46e0-4e6d-a17c-5caf72e3c949@linux.intel.com/

>  static int try_advance_write_generation(struct tsm_report *report)
>  {
>  	struct tsm_report_state *state = to_state(report);
> @@ -144,7 +150,7 @@ static ssize_t tsm_report_service_provider_store(struct config_item *cfg,
>  
>  	return len;
>  }
> -CONFIGFS_ATTR_WO(tsm_report_, service_provider);
> +CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_provider, provider_visibility);
>  
>  static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
>  					     const char *buf, size_t len)
> @@ -165,7 +171,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
>  
>  	return len;
>  }
> -CONFIGFS_ATTR_WO(tsm_report_, service_guid);
> +CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_guid, provider_visibility);
>  
>  static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg,
>  							 const char *buf, size_t len)
> @@ -186,7 +192,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg
>  
>  	return len;
>  }
> -CONFIGFS_ATTR_WO(tsm_report_, service_manifest_version);
> +CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_manifest_version, provider_visibility);
>  
>  static ssize_t tsm_report_inblob_write(struct config_item *cfg,
>  				       const void *buf, size_t count)
> @@ -333,7 +339,7 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,
>  
>  	return tsm_report_read(report, buf, count, TSM_MANIFEST);
>  }
> -CONFIGFS_BIN_ATTR_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX);
> +CONFIGFS_BIN_ATTR_VISIBLE_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX, provider_visibility);
>  
>  #define TSM_DEFAULT_ATTRS() \
>  	&tsm_report_attr_generation, \
> diff --git a/include/linux/cc_platform.h b/include/linux/cc_platform.h
> index cb0d6cd1c12f..f1b4266c1484 100644
> --- a/include/linux/cc_platform.h
> +++ b/include/linux/cc_platform.h
> @@ -90,6 +90,14 @@ enum cc_attr {
>  	 * Examples include TDX Guest.
>  	 */
>  	CC_ATTR_HOTPLUG_DISABLED,
> +
> +	/**
> +	 * @CC_ATTR_GUEST_SVSM_PRESENT: Guest is running under an SVSM
> +	 *
> +	 * The platform/OS is running as a guest/virtual machine and is
> +	 * running under a Secure VM Service Module (SVSM).
> +	 */
> +	CC_ATTR_GUEST_SVSM_PRESENT,
>  };
>  
>  #ifdef CONFIG_ARCH_HAS_CC_PLATFORM

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer


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

* Re: [PATCH v3 06/14] x86/sev: Use the SVSM to create a vCPU when not in VMPL0
  2024-03-25 22:26 ` [PATCH v3 06/14] x86/sev: Use the SVSM to create a vCPU when not in VMPL0 Tom Lendacky
@ 2024-04-12 15:28   ` Gupta, Pankaj
  0 siblings, 0 replies; 61+ messages in thread
From: Gupta, Pankaj @ 2024-04-12 15:28 UTC (permalink / raw)
  To: Tom Lendacky, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

On 3/25/2024 11:26 PM, Tom Lendacky wrote:
> Using the RMPADJUST instruction, the VSMA attribute can only be changed
> at VMPL0. An SVSM will be present when running at VMPL1 or a lower
> privilege level.
> 
> When an SVSM is present, use the SVSM_CORE_CREATE_VCPU call or the
> SVSM_CORE_DESTROY_VCPU call to perform VMSA attribute changes. Use the
> VMPL level supplied by the SVSM within the VMSA and when starting the
> AP.
> 
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>

Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com>

> ---
>   arch/x86/include/asm/sev.h |  2 ++
>   arch/x86/kernel/sev.c      | 60 +++++++++++++++++++++++++++++++++-----
>   2 files changed, 54 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
> index 204f0a4857d6..d7be613b7372 100644
> --- a/arch/x86/include/asm/sev.h
> +++ b/arch/x86/include/asm/sev.h
> @@ -229,6 +229,8 @@ struct svsm_call {
>   #define SVSM_CORE_CALL(x)		((0ULL << 32) | (x))
>   #define SVSM_CORE_REMAP_CA		0
>   #define SVSM_CORE_PVALIDATE		1
> +#define SVSM_CORE_CREATE_VCPU		2
> +#define SVSM_CORE_DELETE_VCPU		3
>   
>   #ifdef CONFIG_AMD_MEM_ENCRYPT
>   extern void __sev_es_ist_enter(struct pt_regs *regs);
> diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
> index d3e182d69d65..ea8b43a0f01b 100644
> --- a/arch/x86/kernel/sev.c
> +++ b/arch/x86/kernel/sev.c
> @@ -1016,7 +1016,7 @@ void snp_accept_memory(phys_addr_t start, phys_addr_t end)
>   	set_pages_state(vaddr, npages, SNP_PAGE_STATE_PRIVATE);
>   }
>   
> -static int snp_set_vmsa(void *va, bool vmsa)
> +static int base_snp_set_vmsa(void *va, bool vmsa)
>   {
>   	u64 attrs;
>   
> @@ -1034,6 +1034,40 @@ static int snp_set_vmsa(void *va, bool vmsa)
>   	return rmpadjust((unsigned long)va, RMP_PG_SIZE_4K, attrs);
>   }
>   
> +static int svsm_snp_set_vmsa(void *va, void *caa, int apic_id, bool vmsa)
> +{
> +	struct svsm_call call = {};
> +	unsigned long flags;
> +	int ret;
> +
> +	local_irq_save(flags);
> +
> +	call.caa = this_cpu_read(svsm_caa);
> +	call.rcx = __pa(va);
> +
> +	if (vmsa) {
> +		/* Protocol 0, Call ID 2 */
> +		call.rax = SVSM_CORE_CALL(SVSM_CORE_CREATE_VCPU);
> +		call.rdx = __pa(caa);
> +		call.r8  = apic_id;
> +	} else {
> +		/* Protocol 0, Call ID 3 */
> +		call.rax = SVSM_CORE_CALL(SVSM_CORE_DELETE_VCPU);
> +	}
> +
> +	ret = svsm_protocol(&call);
> +
> +	local_irq_restore(flags);
> +
> +	return ret;
> +}
> +
> +static int snp_set_vmsa(void *va, void *caa, int apic_id, bool vmsa)
> +{
> +	return vmpl ? svsm_snp_set_vmsa(va, caa, apic_id, vmsa)
> +		    : base_snp_set_vmsa(va, vmsa);
> +}
> +
>   #define __ATTR_BASE		(SVM_SELECTOR_P_MASK | SVM_SELECTOR_S_MASK)
>   #define INIT_CS_ATTRIBS		(__ATTR_BASE | SVM_SELECTOR_READ_MASK | SVM_SELECTOR_CODE_MASK)
>   #define INIT_DS_ATTRIBS		(__ATTR_BASE | SVM_SELECTOR_WRITE_MASK)
> @@ -1065,11 +1099,11 @@ static void *snp_alloc_vmsa_page(void)
>   	return page_address(p + 1);
>   }
>   
> -static void snp_cleanup_vmsa(struct sev_es_save_area *vmsa)
> +static void snp_cleanup_vmsa(struct sev_es_save_area *vmsa, int apic_id)
>   {
>   	int err;
>   
> -	err = snp_set_vmsa(vmsa, false);
> +	err = snp_set_vmsa(vmsa, NULL, apic_id, false);
>   	if (err)
>   		pr_err("clear VMSA page failed (%u), leaking page\n", err);
>   	else
> @@ -1080,6 +1114,7 @@ static int wakeup_cpu_via_vmgexit(u32 apic_id, unsigned long start_ip)
>   {
>   	struct sev_es_save_area *cur_vmsa, *vmsa;
>   	struct ghcb_state state;
> +	struct svsm_ca *caa;
>   	unsigned long flags;
>   	struct ghcb *ghcb;
>   	u8 sipi_vector;
> @@ -1126,6 +1161,12 @@ static int wakeup_cpu_via_vmgexit(u32 apic_id, unsigned long start_ip)
>   	if (!vmsa)
>   		return -ENOMEM;
>   
> +	/*
> +	 * If an SVSM is present, then the SVSM CAA per-CPU variable will
> +	 * have a value, otherwise it will be NULL.
> +	 */
> +	caa = per_cpu(svsm_caa, cpu);
> +
>   	/* CR4 should maintain the MCE value */
>   	cr4 = native_read_cr4() & X86_CR4_MCE;
>   
> @@ -1173,11 +1214,11 @@ static int wakeup_cpu_via_vmgexit(u32 apic_id, unsigned long start_ip)
>   	 *   VMPL level
>   	 *   SEV_FEATURES (matches the SEV STATUS MSR right shifted 2 bits)
>   	 */
> -	vmsa->vmpl		= 0;
> +	vmsa->vmpl		= vmpl;
>   	vmsa->sev_features	= sev_status >> 2;
>   
>   	/* Switch the page over to a VMSA page now that it is initialized */
> -	ret = snp_set_vmsa(vmsa, true);
> +	ret = snp_set_vmsa(vmsa, caa, apic_id, true);
>   	if (ret) {
>   		pr_err("set VMSA page failed (%u)\n", ret);
>   		free_page((unsigned long)vmsa);
> @@ -1193,7 +1234,10 @@ static int wakeup_cpu_via_vmgexit(u32 apic_id, unsigned long start_ip)
>   	vc_ghcb_invalidate(ghcb);
>   	ghcb_set_rax(ghcb, vmsa->sev_features);
>   	ghcb_set_sw_exit_code(ghcb, SVM_VMGEXIT_AP_CREATION);
> -	ghcb_set_sw_exit_info_1(ghcb, ((u64)apic_id << 32) | SVM_VMGEXIT_AP_CREATE);
> +	ghcb_set_sw_exit_info_1(ghcb,
> +				((u64)apic_id << 32)	|
> +				((u64)vmpl << 16)	|
> +				SVM_VMGEXIT_AP_CREATE);
>   	ghcb_set_sw_exit_info_2(ghcb, __pa(vmsa));
>   
>   	sev_es_wr_ghcb_msr(__pa(ghcb));
> @@ -1211,13 +1255,13 @@ static int wakeup_cpu_via_vmgexit(u32 apic_id, unsigned long start_ip)
>   
>   	/* Perform cleanup if there was an error */
>   	if (ret) {
> -		snp_cleanup_vmsa(vmsa);
> +		snp_cleanup_vmsa(vmsa, apic_id);
>   		vmsa = NULL;
>   	}
>   
>   	/* Free up any previous VMSA page */
>   	if (cur_vmsa)
> -		snp_cleanup_vmsa(cur_vmsa);
> +		snp_cleanup_vmsa(cur_vmsa, apic_id);
>   
>   	/* Record the current VMSA page */
>   	per_cpu(sev_vmsa, cpu) = vmsa;

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

* Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
  2024-04-09 18:12   ` Kuppuswamy Sathyanarayanan
@ 2024-04-12 15:52     ` Tom Lendacky
  2024-04-15 19:16       ` Tom Lendacky
  0 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-04-12 15:52 UTC (permalink / raw)
  To: Kuppuswamy Sathyanarayanan, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra, Joel Becker, Christoph Hellwig

On 4/9/24 13:12, Kuppuswamy Sathyanarayanan wrote:
> 
> On 3/25/24 3:26 PM, Tom Lendacky wrote:
>> Config-fs provides support to hide individual attribute entries. Using
>> this support, base the display of the SVSM related entries on the presence
>> of an SVSM.
>>
>> Cc: Joel Becker <jlbec@evilplan.org>
>> Cc: Christoph Hellwig <hch@lst.de>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>>   arch/x86/coco/core.c        |  4 ++++
>>   drivers/virt/coco/tsm.c     | 14 ++++++++++----
>>   include/linux/cc_platform.h |  8 ++++++++
>>   3 files changed, 22 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/coco/core.c b/arch/x86/coco/core.c
>> index d07be9d05cd0..efa0f648f754 100644
>> --- a/arch/x86/coco/core.c
>> +++ b/arch/x86/coco/core.c
>> @@ -12,6 +12,7 @@
>>   
>>   #include <asm/coco.h>
>>   #include <asm/processor.h>
>> +#include <asm/sev.h>
>>   
>>   enum cc_vendor cc_vendor __ro_after_init = CC_VENDOR_NONE;
>>   u64 cc_mask __ro_after_init;
>> @@ -78,6 +79,9 @@ static bool noinstr amd_cc_platform_has(enum cc_attr attr)
>>   	case CC_ATTR_GUEST_STATE_ENCRYPT:
>>   		return sev_status & MSR_AMD64_SEV_ES_ENABLED;
>>   
>> +	case CC_ATTR_GUEST_SVSM_PRESENT:
>> +		return snp_get_vmpl();
>> +
>>   	/*
>>   	 * With SEV, the rep string I/O instructions need to be unrolled
>>   	 * but SEV-ES supports them through the #VC handler.
>> diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
>> index 46f230bf13ac..d30471874e87 100644
>> --- a/drivers/virt/coco/tsm.c
>> +++ b/drivers/virt/coco/tsm.c
>> @@ -64,6 +64,12 @@ static struct tsm_report_state *to_state(struct tsm_report *report)
>>   	return container_of(report, struct tsm_report_state, report);
>>   }
>>   
>> +static bool provider_visibility(const struct config_item *item,
>> +				const struct configfs_attribute *attr)
>> +{
>> +	return cc_platform_has(CC_ATTR_GUEST_SVSM_PRESENT);
>> +}
>> +
> 
> Any comment about the following query? I think introducing a CC flag for this use
> case is over kill.
> 
> https://lore.kernel.org/lkml/6b90b223-46e0-4e6d-a17c-5caf72e3c949@linux.intel.com/

If you don't think TDX will be able to make use of the SVSM attribute I 
can look at adding a callback. But I was waiting to see if anyone else had 
comments, for or against, before re-doing it all.

Thanks,
Tom

> 
>>   static int try_advance_write_generation(struct tsm_report *report)
>>   {
>>   	struct tsm_report_state *state = to_state(report);
>> @@ -144,7 +150,7 @@ static ssize_t tsm_report_service_provider_store(struct config_item *cfg,
>>   
>>   	return len;
>>   }
>> -CONFIGFS_ATTR_WO(tsm_report_, service_provider);
>> +CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_provider, provider_visibility);
>>   
>>   static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
>>   					     const char *buf, size_t len)
>> @@ -165,7 +171,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
>>   
>>   	return len;
>>   }
>> -CONFIGFS_ATTR_WO(tsm_report_, service_guid);
>> +CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_guid, provider_visibility);
>>   
>>   static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg,
>>   							 const char *buf, size_t len)
>> @@ -186,7 +192,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg
>>   
>>   	return len;
>>   }
>> -CONFIGFS_ATTR_WO(tsm_report_, service_manifest_version);
>> +CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_manifest_version, provider_visibility);
>>   
>>   static ssize_t tsm_report_inblob_write(struct config_item *cfg,
>>   				       const void *buf, size_t count)
>> @@ -333,7 +339,7 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,
>>   
>>   	return tsm_report_read(report, buf, count, TSM_MANIFEST);
>>   }
>> -CONFIGFS_BIN_ATTR_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX);
>> +CONFIGFS_BIN_ATTR_VISIBLE_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX, provider_visibility);
>>   
>>   #define TSM_DEFAULT_ATTRS() \
>>   	&tsm_report_attr_generation, \
>> diff --git a/include/linux/cc_platform.h b/include/linux/cc_platform.h
>> index cb0d6cd1c12f..f1b4266c1484 100644
>> --- a/include/linux/cc_platform.h
>> +++ b/include/linux/cc_platform.h
>> @@ -90,6 +90,14 @@ enum cc_attr {
>>   	 * Examples include TDX Guest.
>>   	 */
>>   	CC_ATTR_HOTPLUG_DISABLED,
>> +
>> +	/**
>> +	 * @CC_ATTR_GUEST_SVSM_PRESENT: Guest is running under an SVSM
>> +	 *
>> +	 * The platform/OS is running as a guest/virtual machine and is
>> +	 * running under a Secure VM Service Module (SVSM).
>> +	 */
>> +	CC_ATTR_GUEST_SVSM_PRESENT,
>>   };
>>   
>>   #ifdef CONFIG_ARCH_HAS_CC_PLATFORM
> 

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

* Re: [PATCH v3 04/14] x86/sev: Use kernel provided SVSM Calling Areas
  2024-03-25 22:26 ` [PATCH v3 04/14] x86/sev: Use kernel provided SVSM Calling Areas Tom Lendacky
@ 2024-04-12 16:04   ` Gupta, Pankaj
  0 siblings, 0 replies; 61+ messages in thread
From: Gupta, Pankaj @ 2024-04-12 16:04 UTC (permalink / raw)
  To: Tom Lendacky, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

On 3/25/2024 11:26 PM, Tom Lendacky wrote:
> The SVSM Calling Area (CA) is used to communicate between Linux and the
> SVSM. Since the firmware supplied CA for the BSP is likely to be in
> reserved memory, switch off that CA to a kernel provided CA so that access
> and use of the CA is available during boot. The CA switch is done using
> the SVSM core protocol SVSM_CORE_REMAP_CA call.
> 
> An SVSM call is executed by filling out the SVSM CA and setting the proper
> register state as documented by the SVSM protocol. The SVSM is invoked by
> by requesting the hypervisor to run VMPL0.
s/by/''
> 
> Once it is safe to allocate/reserve memory, allocate a CA for each CPU.
> After allocating the new CAs, the BSP will switch from the boot CA to the
> per-CPU CA. The CA for an AP is identified to the SVSM when creating the
> VMSA in preparation for booting the AP.
> 
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>

Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com>

> ---
>   arch/x86/include/asm/sev-common.h |  13 ++
>   arch/x86/include/asm/sev.h        |  32 +++++
>   arch/x86/include/uapi/asm/svm.h   |   1 +
>   arch/x86/kernel/sev-shared.c      |  94 +++++++++++++-
>   arch/x86/kernel/sev.c             | 205 +++++++++++++++++++++++++-----
>   arch/x86/mm/mem_encrypt_amd.c     |   8 +-
>   6 files changed, 318 insertions(+), 35 deletions(-)
> 
> diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h
> index 68a8cdf6fd6a..71db5ba020b9 100644
> --- a/arch/x86/include/asm/sev-common.h
> +++ b/arch/x86/include/asm/sev-common.h
> @@ -96,6 +96,19 @@ enum psc_op {
>   	/* GHCBData[63:32] */				\
>   	(((u64)(val) & GENMASK_ULL(63, 32)) >> 32)
>   
> +/* GHCB Run at VMPL Request/Response */
> +#define GHCB_MSR_VMPL_REQ		0x016
> +#define GHCB_MSR_VMPL_REQ_LEVEL(v)			\
> +	/* GHCBData[39:32] */				\
> +	(((u64)(v) & GENMASK_ULL(7, 0) << 32) |		\
> +	/* GHCBDdata[11:0] */				\
> +	GHCB_MSR_VMPL_REQ)
> +
> +#define GHCB_MSR_VMPL_RESP		0x017
> +#define GHCB_MSR_VMPL_RESP_VAL(v)			\
> +	/* GHCBData[63:32] */				\
> +	(((u64)(v) & GENMASK_ULL(63, 32)) >> 32)
> +
>   /* GHCB Hypervisor Feature Request/Response */
>   #define GHCB_MSR_HV_FT_REQ		0x080
>   #define GHCB_MSR_HV_FT_RESP		0x081
> diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
> index 891e7d9a1f66..4aa36905b047 100644
> --- a/arch/x86/include/asm/sev.h
> +++ b/arch/x86/include/asm/sev.h
> @@ -178,6 +178,36 @@ struct svsm_ca {
>   	u8 svsm_buffer[PAGE_SIZE - 8];
>   };
>   
> +#define SVSM_SUCCESS				0
> +#define SVSM_ERR_INCOMPLETE			0x80000000
> +#define SVSM_ERR_UNSUPPORTED_PROTOCOL		0x80000001
> +#define SVSM_ERR_UNSUPPORTED_CALL		0x80000002
> +#define SVSM_ERR_INVALID_ADDRESS		0x80000003
> +#define SVSM_ERR_INVALID_FORMAT			0x80000004
> +#define SVSM_ERR_INVALID_PARAMETER		0x80000005
> +#define SVSM_ERR_INVALID_REQUEST		0x80000006
> +#define SVSM_ERR_BUSY				0x80000007
> +
> +/*
> + * SVSM protocol structure
> + */
> +struct svsm_call {
> +	struct svsm_ca *caa;
> +	u64 rax;
> +	u64 rcx;
> +	u64 rdx;
> +	u64 r8;
> +	u64 r9;
> +	u64 rax_out;
> +	u64 rcx_out;
> +	u64 rdx_out;
> +	u64 r8_out;
> +	u64 r9_out;
> +};
> +
> +#define SVSM_CORE_CALL(x)		((0ULL << 32) | (x))
> +#define SVSM_CORE_REMAP_CA		0
> +
>   #ifdef CONFIG_AMD_MEM_ENCRYPT
>   extern void __sev_es_ist_enter(struct pt_regs *regs);
>   extern void __sev_es_ist_exit(void);
> @@ -253,6 +283,7 @@ u64 snp_get_unsupported_features(u64 status);
>   u64 sev_get_status(void);
>   void kdump_sev_callback(void);
>   void sev_show_status(void);
> +void snp_remap_svsm_ca(void);
>   #else
>   static inline void sev_es_ist_enter(struct pt_regs *regs) { }
>   static inline void sev_es_ist_exit(void) { }
> @@ -283,6 +314,7 @@ static inline u64 snp_get_unsupported_features(u64 status) { return 0; }
>   static inline u64 sev_get_status(void) { return 0; }
>   static inline void kdump_sev_callback(void) { }
>   static inline void sev_show_status(void) { }
> +static inline void snp_remap_svsm_ca(void) { }
>   #endif
>   
>   #ifdef CONFIG_KVM_AMD_SEV
> diff --git a/arch/x86/include/uapi/asm/svm.h b/arch/x86/include/uapi/asm/svm.h
> index 80e1df482337..1814b413fd57 100644
> --- a/arch/x86/include/uapi/asm/svm.h
> +++ b/arch/x86/include/uapi/asm/svm.h
> @@ -115,6 +115,7 @@
>   #define SVM_VMGEXIT_AP_CREATE_ON_INIT		0
>   #define SVM_VMGEXIT_AP_CREATE			1
>   #define SVM_VMGEXIT_AP_DESTROY			2
> +#define SVM_VMGEXIT_SNP_RUN_VMPL		0x80000018
>   #define SVM_VMGEXIT_HV_FEATURES			0x8000fffd
>   #define SVM_VMGEXIT_TERM_REQUEST		0x8000fffe
>   #define SVM_VMGEXIT_TERM_REASON(reason_set, reason_code)	\
> diff --git a/arch/x86/kernel/sev-shared.c b/arch/x86/kernel/sev-shared.c
> index 66d33292eb78..78d2b9f570de 100644
> --- a/arch/x86/kernel/sev-shared.c
> +++ b/arch/x86/kernel/sev-shared.c
> @@ -18,9 +18,11 @@
>   #define sev_printk_rtl(fmt, ...)	printk_ratelimited(fmt, ##__VA_ARGS__)
>   #else
>   #undef WARN
> -#define WARN(condition, format...) (!!(condition))
> +#define WARN(condition, format...)	(!!(condition))
>   #define sev_printk(fmt, ...)
>   #define sev_printk_rtl(fmt, ...)
> +#undef vc_forward_exception
> +#define vc_forward_exception(c)		panic("SNP: Hypervisor requested exception\n")
>   #endif
>   
>   /* I/O parameters for CPUID-related helpers */
> @@ -247,6 +249,96 @@ static enum es_result verify_exception_info(struct ghcb *ghcb, struct es_em_ctxt
>   	return ES_VMM_ERROR;
>   }
>   
> +static __always_inline void issue_svsm_call(struct svsm_call *call, u8 *pending)
> +{
> +	/*
> +	 * Issue the VMGEXIT to run the SVSM:
> +	 *   - Load the SVSM register state (RAX, RCX, RDX, R8 and R9)
> +	 *   - Set the CA call pending field to 1
> +	 *   - Issue VMGEXIT
> +	 *   - Save the SVSM return register state (RAX, RCX, RDX, R8 and R9)
> +	 *   - Perform atomic exchange of the CA call pending field
> +	 */
> +	asm volatile("mov %9, %%r8\n\t"
> +		     "mov %10, %%r9\n\t"
> +		     "movb $1, %11\n\t"
> +		     "rep; vmmcall\n\t"
> +		     "mov %%r8, %3\n\t"
> +		     "mov %%r9, %4\n\t"
> +		     "xchgb %5, %11\n\t"
> +		     : "=a" (call->rax_out), "=c" (call->rcx_out), "=d" (call->rdx_out),
> +		       "=m" (call->r8_out), "=m" (call->r9_out),
> +		       "+r" (*pending)
> +		     : "a" (call->rax), "c" (call->rcx), "d" (call->rdx),
> +		       "r" (call->r8), "r" (call->r9),
> +		       "m" (call->caa->call_pending)
> +		     : "r8", "r9", "memory");
> +}
> +
> +static int __svsm_msr_protocol(struct svsm_call *call)
> +{
> +	u64 val, resp;
> +	u8 pending;
> +
> +	val = sev_es_rd_ghcb_msr();
> +
> +	sev_es_wr_ghcb_msr(GHCB_MSR_VMPL_REQ_LEVEL(0));
> +
> +	pending = 0;
> +	issue_svsm_call(call, &pending);
> +
> +	resp = sev_es_rd_ghcb_msr();
> +
> +	sev_es_wr_ghcb_msr(val);
> +
> +	if (pending)
> +		return -EINVAL;
> +
> +	if (GHCB_RESP_CODE(resp) != GHCB_MSR_VMPL_RESP)
> +		return -EINVAL;
> +
> +	if (GHCB_MSR_VMPL_RESP_VAL(resp) != 0)
> +		return -EINVAL;
> +
> +	return call->rax_out;
> +}
> +
> +static int __svsm_ghcb_protocol(struct ghcb *ghcb, struct svsm_call *call)
> +{
> +	struct es_em_ctxt ctxt;
> +	u8 pending;
> +
> +	vc_ghcb_invalidate(ghcb);
> +
> +	/* Fill in protocol and format specifiers */
> +	ghcb->protocol_version = ghcb_version;
> +	ghcb->ghcb_usage       = GHCB_DEFAULT_USAGE;
> +
> +	ghcb_set_sw_exit_code(ghcb, SVM_VMGEXIT_SNP_RUN_VMPL);
> +	ghcb_set_sw_exit_info_1(ghcb, 0);
> +	ghcb_set_sw_exit_info_2(ghcb, 0);
> +
> +	sev_es_wr_ghcb_msr(__pa(ghcb));
> +
> +	pending = 0;
> +	issue_svsm_call(call, &pending);
> +
> +	if (pending)
> +		return -EINVAL;
> +
> +	switch (verify_exception_info(ghcb, &ctxt)) {
> +	case ES_OK:
> +		break;
> +	case ES_EXCEPTION:
> +		vc_forward_exception(&ctxt);
> +		fallthrough;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	return call->rax_out;
> +}
> +
>   static enum es_result sev_es_ghcb_hv_call(struct ghcb *ghcb,
>   					  struct es_em_ctxt *ctxt,
>   					  u64 exit_code, u64 exit_info_1,
> diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
> index 64799a04feb4..af5017ab9746 100644
> --- a/arch/x86/kernel/sev.c
> +++ b/arch/x86/kernel/sev.c
> @@ -134,6 +134,8 @@ struct ghcb_state {
>   
>   static DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data);
>   static DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa);
> +static DEFINE_PER_CPU(struct svsm_ca *, svsm_caa);
> +static DEFINE_PER_CPU(u64, svsm_caa_pa);
>   
>   /*
>    * SVSM related information:
> @@ -141,6 +143,7 @@ static DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa);
>    *   non-zero. The VMPL is therefore used to indicate the presence of an SVSM.
>    */
>   static u8 vmpl __ro_after_init;
> +static struct svsm_ca boot_svsm_ca_page __aligned(PAGE_SIZE);
>   static struct svsm_ca *boot_svsm_caa __ro_after_init;
>   static u64 boot_svsm_caa_pa __ro_after_init;
>   
> @@ -158,11 +161,26 @@ struct sev_config {
>   	       */
>   	      ghcbs_initialized	: 1,
>   
> +	      /*
> +	       * A flag used to indicate when the per-CPU SVSM CA is to be
> +	       * used instead of the boot SVSM CA.
> +	       *
> +	       * For APs, the per-CPU SVSM CA is created as part of the AP
> +	       * bringup, so this flag can be used globally for the BSP and APs.
> +	       */
> +	      cas_initialized	: 1,
> +
>   	      __reserved	: 62;
>   };
>   
>   static struct sev_config sev_cfg __read_mostly;
>   
> +static struct svsm_ca *__svsm_get_caa(void)
> +{
> +	return sev_cfg.cas_initialized ? this_cpu_read(svsm_caa)
> +				       : boot_svsm_caa;
> +}
> +
>   static __always_inline bool on_vc_stack(struct pt_regs *regs)
>   {
>   	unsigned long sp = regs->sp;
> @@ -580,6 +598,33 @@ static enum es_result vc_ioio_check(struct es_em_ctxt *ctxt, u16 port, size_t si
>   	return ES_EXCEPTION;
>   }
>   
> +static __always_inline void vc_forward_exception(struct es_em_ctxt *ctxt)
> +{
> +	long error_code = ctxt->fi.error_code;
> +	int trapnr = ctxt->fi.vector;
> +
> +	ctxt->regs->orig_ax = ctxt->fi.error_code;
> +
> +	switch (trapnr) {
> +	case X86_TRAP_GP:
> +		exc_general_protection(ctxt->regs, error_code);
> +		break;
> +	case X86_TRAP_UD:
> +		exc_invalid_op(ctxt->regs);
> +		break;
> +	case X86_TRAP_PF:
> +		write_cr2(ctxt->fi.cr2);
> +		exc_page_fault(ctxt->regs, error_code);
> +		break;
> +	case X86_TRAP_AC:
> +		exc_alignment_check(ctxt->regs, error_code);
> +		break;
> +	default:
> +		pr_emerg("Unsupported exception in #VC instruction emulation - can't continue\n");
> +		BUG();
> +	}
> +}
> +
>   /* Include code shared with pre-decompression boot stage */
>   #include "sev-shared.c"
>   
> @@ -608,6 +653,42 @@ static noinstr void __sev_put_ghcb(struct ghcb_state *state)
>   	}
>   }
>   
> +static int svsm_protocol(struct svsm_call *call)
> +{
> +	struct ghcb_state state;
> +	unsigned long flags;
> +	struct ghcb *ghcb;
> +	int ret;
> +
> +	/*
> +	 * This can be called very early in the boot, use native functions in
> +	 * order to avoid paravirt issues.
> +	 */
> +	flags = native_save_fl();
> +	if (flags & X86_EFLAGS_IF)
> +		native_irq_disable();
> +
> +	if (sev_cfg.ghcbs_initialized)
> +		ghcb = __sev_get_ghcb(&state);
> +	else if (boot_ghcb)
> +		ghcb = boot_ghcb;
> +	else
> +		ghcb = NULL;
> +
> +	do {
> +		ret = ghcb ? __svsm_ghcb_protocol(ghcb, call)
> +			   : __svsm_msr_protocol(call);
> +	} while (ret == SVSM_ERR_BUSY);
> +
> +	if (sev_cfg.ghcbs_initialized)
> +		__sev_put_ghcb(&state);
> +
> +	if (flags & X86_EFLAGS_IF)
> +		native_irq_enable();
> +
> +	return ret;
> +}
> +
>   void noinstr __sev_es_nmi_complete(void)
>   {
>   	struct ghcb_state state;
> @@ -1369,6 +1450,18 @@ static void __init alloc_runtime_data(int cpu)
>   		panic("Can't allocate SEV-ES runtime data");
>   
>   	per_cpu(runtime_data, cpu) = data;
> +
> +	if (vmpl) {
> +		struct svsm_ca *caa;
> +
> +		/* Allocate the SVSM CA page if an SVSM is present */
> +		caa = memblock_alloc(sizeof(*caa), PAGE_SIZE);
> +		if (!caa)
> +			panic("Can't allocate SVSM CA page\n");
> +
> +		per_cpu(svsm_caa, cpu) = caa;
> +		per_cpu(svsm_caa_pa, cpu) = __pa(caa);
> +	}
>   }
>   
>   static void __init init_ghcb(int cpu)
> @@ -1418,6 +1511,31 @@ void __init sev_es_init_vc_handling(void)
>   		init_ghcb(cpu);
>   	}
>   
> +	/* If running under an SVSM, switch to the per-cpu CA */
> +	if (vmpl) {
> +		struct svsm_call call = {};
> +		unsigned long flags;
> +		int ret;
> +
> +		local_irq_save(flags);
> +
> +		/*
> +		 * SVSM_CORE_REMAP_CA call:
> +		 *   RAX = 0 (Protocol=0, CallID=0)
> +		 *   RCX = New CA GPA
> +		 */
> +		call.caa = __svsm_get_caa();
> +		call.rax = SVSM_CORE_CALL(SVSM_CORE_REMAP_CA);
> +		call.rcx = this_cpu_read(svsm_caa_pa);
> +		ret = svsm_protocol(&call);
> +		if (ret != SVSM_SUCCESS)
> +			panic("Can't remap the SVSM CA, ret=%#x (%d)\n", ret, ret);
> +
> +		sev_cfg.cas_initialized = true;
> +
> +		local_irq_restore(flags);
> +	}
> +
>   	sev_es_setup_play_dead();
>   
>   	/* Secondary CPUs use the runtime #VC handler */
> @@ -1842,33 +1960,6 @@ static enum es_result vc_handle_exitcode(struct es_em_ctxt *ctxt,
>   	return result;
>   }
>   
> -static __always_inline void vc_forward_exception(struct es_em_ctxt *ctxt)
> -{
> -	long error_code = ctxt->fi.error_code;
> -	int trapnr = ctxt->fi.vector;
> -
> -	ctxt->regs->orig_ax = ctxt->fi.error_code;
> -
> -	switch (trapnr) {
> -	case X86_TRAP_GP:
> -		exc_general_protection(ctxt->regs, error_code);
> -		break;
> -	case X86_TRAP_UD:
> -		exc_invalid_op(ctxt->regs);
> -		break;
> -	case X86_TRAP_PF:
> -		write_cr2(ctxt->fi.cr2);
> -		exc_page_fault(ctxt->regs, error_code);
> -		break;
> -	case X86_TRAP_AC:
> -		exc_alignment_check(ctxt->regs, error_code);
> -		break;
> -	default:
> -		pr_emerg("Unsupported exception in #VC instruction emulation - can't continue\n");
> -		BUG();
> -	}
> -}
> -
>   static __always_inline bool is_vc2_stack(unsigned long sp)
>   {
>   	return (sp >= __this_cpu_ist_bottom_va(VC2) && sp < __this_cpu_ist_top_va(VC2));
> @@ -2118,6 +2209,50 @@ static __head struct cc_blob_sev_info *find_cc_blob(struct boot_params *bp)
>   	return cc_info;
>   }
>   
> +static __head void setup_svsm(struct cc_blob_sev_info *cc_info)
> +{
> +	struct svsm_call call = {};
> +	int ret;
> +	u64 pa;
> +
> +	/*
> +	 * Record the SVSM Calling Area address (CAA) if the guest is not
> +	 * running at VMPL0. The CA will be used to communicate with the
> +	 * SVSM to perform the SVSM services.
> +	 */
> +	setup_svsm_ca(cc_info);
> +
> +	/* Nothing to do if not running under an SVSM. */
> +	if (!vmpl)
> +		return;
> +
> +	/*
> +	 * It is very early in the boot and the kernel is running identity
> +	 * mapped but without having adjusted the pagetables to where the
> +	 * kernel was loaded (physbase), so the get the CA address using
                                              \..> s/the/''
> +	 * RIP-relative addressing.
> +	 */
> +	pa = (u64)&RIP_REL_REF(boot_svsm_ca_page);
> +
> +	/*
> +	 * Switch over to the boot SVSM CA while the current CA is still
> +	 * addressable. There is no GHCB at this point so use the MSR protocol.
> +	 *
> +	 * SVSM_CORE_REMAP_CA call:
> +	 *   RAX = 0 (Protocol=0, CallID=0)
> +	 *   RCX = New CA GPA
> +	 */
> +	call.caa = __svsm_get_caa();
> +	call.rax = SVSM_CORE_CALL(SVSM_CORE_REMAP_CA);
> +	call.rcx = pa;
> +	ret = svsm_protocol(&call);
> +	if (ret != SVSM_SUCCESS)
> +		panic("Can't remap the SVSM CA, ret=%#x (%d)\n", ret, ret);
> +
> +	boot_svsm_caa = (struct svsm_ca *)pa;
> +	boot_svsm_caa_pa = pa;
> +}
> +
>   bool __head snp_init(struct boot_params *bp)
>   {
>   	struct cc_blob_sev_info *cc_info;
> @@ -2131,12 +2266,7 @@ bool __head snp_init(struct boot_params *bp)
>   
>   	setup_cpuid_table(cc_info);
>   
> -	/*
> -	 * Record the SVSM Calling Area address (CAA) if the guest is not
> -	 * running at VMPL0. The CA will be used to communicate with the
> -	 * SVSM to perform the SVSM services.
> -	 */
> -	setup_svsm_ca(cc_info);
> +	setup_svsm(cc_info);
>   
>   	/*
>   	 * The CC blob will be used later to access the secrets page. Cache
> @@ -2328,3 +2458,12 @@ void sev_show_status(void)
>   	}
>   	pr_cont("\n");
>   }
> +
> +void __init snp_remap_svsm_ca(void)
> +{
> +	if (!vmpl)
> +		return;
> +
> +	/* Update the CAA to a proper kernel address */
> +	boot_svsm_caa = &boot_svsm_ca_page;
> +}
> diff --git a/arch/x86/mm/mem_encrypt_amd.c b/arch/x86/mm/mem_encrypt_amd.c
> index 70b91de2e053..8943286f9fdc 100644
> --- a/arch/x86/mm/mem_encrypt_amd.c
> +++ b/arch/x86/mm/mem_encrypt_amd.c
> @@ -2,7 +2,7 @@
>   /*
>    * AMD Memory Encryption Support
>    *
> - * Copyright (C) 2016 Advanced Micro Devices, Inc.
> + * Copyright (C) 2016-2024 Advanced Micro Devices, Inc.
>    *
>    * Author: Tom Lendacky <thomas.lendacky@amd.com>
>    */
> @@ -492,6 +492,12 @@ void __init sme_early_init(void)
>   	 */
>   	if (sev_status & MSR_AMD64_SEV_ENABLED)
>   		ia32_disable();
> +
> +	/*
> +	 * Switch the SVSM CA mapping (if active) from identity mapped to
> +	 * kernel mapped.
> +	 */
> +	snp_remap_svsm_ca();
>   }
>   
>   void __init mem_encrypt_free_decrypted_mem(void)


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

* Re: [PATCH v3 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file
  2024-03-25 22:26 ` [PATCH v3 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file Tom Lendacky
  2024-04-09 17:09   ` Borislav Petkov
@ 2024-04-12 16:19   ` Gupta, Pankaj
  1 sibling, 0 replies; 61+ messages in thread
From: Gupta, Pankaj @ 2024-04-12 16:19 UTC (permalink / raw)
  To: Tom Lendacky, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

On 3/25/2024 11:26 PM, Tom Lendacky wrote:
> The snp_init() in boot/compressed/sev.c is local to that file and is not
> called from outside of the file. Change the name so that it is not tied
> to the function definition in arch/x86/include/asm/sev.h. Move the renamed
> snp_init() and related functions up in the file to avoid having to add a
> forward declaration and make the function static, too.
> 
> This will allow the snp_init() function in arch/x86/kernel/sev.c to be
> changed without having to make the same change in boot/compressed/sev.c.
> 
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>

Seems no functional change. Just rename snp_init() & move functions up 
in the file.

Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com>


> ---
>   arch/x86/boot/compressed/sev.c | 162 ++++++++++++++++-----------------
>   1 file changed, 81 insertions(+), 81 deletions(-)
> 
> diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
> index ec71846d28c9..5ad0ff4664f1 100644
> --- a/arch/x86/boot/compressed/sev.c
> +++ b/arch/x86/boot/compressed/sev.c
> @@ -413,6 +413,85 @@ void snp_check_features(void)
>   	}
>   }
>   
> +/* Search for Confidential Computing blob in the EFI config table. */
> +static struct cc_blob_sev_info *find_cc_blob_efi(struct boot_params *bp)
> +{
> +	unsigned long cfg_table_pa;
> +	unsigned int cfg_table_len;
> +	int ret;
> +
> +	ret = efi_get_conf_table(bp, &cfg_table_pa, &cfg_table_len);
> +	if (ret)
> +		return NULL;
> +
> +	return (struct cc_blob_sev_info *)efi_find_vendor_table(bp, cfg_table_pa,
> +								cfg_table_len,
> +								EFI_CC_BLOB_GUID);
> +}
> +
> +/*
> + * Initial set up of SNP relies on information provided by the
> + * Confidential Computing blob, which can be passed to the boot kernel
> + * by firmware/bootloader in the following ways:
> + *
> + * - via an entry in the EFI config table
> + * - via a setup_data structure, as defined by the Linux Boot Protocol
> + *
> + * Scan for the blob in that order.
> + */
> +static struct cc_blob_sev_info *find_cc_blob(struct boot_params *bp)
> +{
> +	struct cc_blob_sev_info *cc_info;
> +
> +	cc_info = find_cc_blob_efi(bp);
> +	if (cc_info)
> +		goto found_cc_info;
> +
> +	cc_info = find_cc_blob_setup_data(bp);
> +	if (!cc_info)
> +		return NULL;
> +
> +found_cc_info:
> +	if (cc_info->magic != CC_BLOB_SEV_HDR_MAGIC)
> +		sev_es_terminate(SEV_TERM_SET_GEN, GHCB_SNP_UNSUPPORTED);
> +
> +	return cc_info;
> +}
> +
> +/*
> + * Indicate SNP based on presence of SNP-specific CC blob. Subsequent checks
> + * will verify the SNP CPUID/MSR bits.
> + */
> +static bool early_snp_init(struct boot_params *bp)
> +{
> +	struct cc_blob_sev_info *cc_info;
> +
> +	if (!bp)
> +		return false;
> +
> +	cc_info = find_cc_blob(bp);
> +	if (!cc_info)
> +		return false;
> +
> +	/*
> +	 * If a SNP-specific Confidential Computing blob is present, then
> +	 * firmware/bootloader have indicated SNP support. Verifying this
> +	 * involves CPUID checks which will be more reliable if the SNP
> +	 * CPUID table is used. See comments over snp_setup_cpuid_table() for
> +	 * more details.
> +	 */
> +	setup_cpuid_table(cc_info);
> +
> +	/*
> +	 * Pass run-time kernel a pointer to CC info via boot_params so EFI
> +	 * config table doesn't need to be searched again during early startup
> +	 * phase.
> +	 */
> +	bp->cc_blob_address = (u32)(unsigned long)cc_info;
> +
> +	return true;
> +}
> +
>   /*
>    * sev_check_cpu_support - Check for SEV support in the CPU capabilities
>    *
> @@ -463,7 +542,7 @@ void sev_enable(struct boot_params *bp)
>   		bp->cc_blob_address = 0;
>   
>   	/*
> -	 * Do an initial SEV capability check before snp_init() which
> +	 * Do an initial SEV capability check before early_snp_init() which
>   	 * loads the CPUID page and the same checks afterwards are done
>   	 * without the hypervisor and are trustworthy.
>   	 *
> @@ -478,7 +557,7 @@ void sev_enable(struct boot_params *bp)
>   	 * Setup/preliminary detection of SNP. This will be sanity-checked
>   	 * against CPUID/MSR values later.
>   	 */
> -	snp = snp_init(bp);
> +	snp = early_snp_init(bp);
>   
>   	/* Now repeat the checks with the SNP CPUID table. */
>   
> @@ -535,85 +614,6 @@ u64 sev_get_status(void)
>   	return m.q;
>   }
>   
> -/* Search for Confidential Computing blob in the EFI config table. */
> -static struct cc_blob_sev_info *find_cc_blob_efi(struct boot_params *bp)
> -{
> -	unsigned long cfg_table_pa;
> -	unsigned int cfg_table_len;
> -	int ret;
> -
> -	ret = efi_get_conf_table(bp, &cfg_table_pa, &cfg_table_len);
> -	if (ret)
> -		return NULL;
> -
> -	return (struct cc_blob_sev_info *)efi_find_vendor_table(bp, cfg_table_pa,
> -								cfg_table_len,
> -								EFI_CC_BLOB_GUID);
> -}
> -
> -/*
> - * Initial set up of SNP relies on information provided by the
> - * Confidential Computing blob, which can be passed to the boot kernel
> - * by firmware/bootloader in the following ways:
> - *
> - * - via an entry in the EFI config table
> - * - via a setup_data structure, as defined by the Linux Boot Protocol
> - *
> - * Scan for the blob in that order.
> - */
> -static struct cc_blob_sev_info *find_cc_blob(struct boot_params *bp)
> -{
> -	struct cc_blob_sev_info *cc_info;
> -
> -	cc_info = find_cc_blob_efi(bp);
> -	if (cc_info)
> -		goto found_cc_info;
> -
> -	cc_info = find_cc_blob_setup_data(bp);
> -	if (!cc_info)
> -		return NULL;
> -
> -found_cc_info:
> -	if (cc_info->magic != CC_BLOB_SEV_HDR_MAGIC)
> -		sev_es_terminate(SEV_TERM_SET_GEN, GHCB_SNP_UNSUPPORTED);
> -
> -	return cc_info;
> -}
> -
> -/*
> - * Indicate SNP based on presence of SNP-specific CC blob. Subsequent checks
> - * will verify the SNP CPUID/MSR bits.
> - */
> -bool snp_init(struct boot_params *bp)
> -{
> -	struct cc_blob_sev_info *cc_info;
> -
> -	if (!bp)
> -		return false;
> -
> -	cc_info = find_cc_blob(bp);
> -	if (!cc_info)
> -		return false;
> -
> -	/*
> -	 * If a SNP-specific Confidential Computing blob is present, then
> -	 * firmware/bootloader have indicated SNP support. Verifying this
> -	 * involves CPUID checks which will be more reliable if the SNP
> -	 * CPUID table is used. See comments over snp_setup_cpuid_table() for
> -	 * more details.
> -	 */
> -	setup_cpuid_table(cc_info);
> -
> -	/*
> -	 * Pass run-time kernel a pointer to CC info via boot_params so EFI
> -	 * config table doesn't need to be searched again during early startup
> -	 * phase.
> -	 */
> -	bp->cc_blob_address = (u32)(unsigned long)cc_info;
> -
> -	return true;
> -}
> -
>   void sev_prep_identity_maps(unsigned long top_level_pgt)
>   {
>   	/*


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

* Re: [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic
  2024-03-25 22:26 ` [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic Tom Lendacky
@ 2024-04-12 16:41   ` Gupta, Pankaj
  2024-04-17 11:46   ` Borislav Petkov
  1 sibling, 0 replies; 61+ messages in thread
From: Gupta, Pankaj @ 2024-04-12 16:41 UTC (permalink / raw)
  To: Tom Lendacky, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

On 3/25/2024 11:26 PM, Tom Lendacky wrote:
> Currently, the enforce_vmpl0() function uses a set argument when testing
> for VMPL0 and terminates the guest if the guest is not running at VMPL0.
> 
> Make the function more generic by moving it into the common code, renaming
> it, allowing it to take an argument for use in the VMPL0 check (RMPADJUST
> instruction) and return the result of the check, allowing the caller to
> determine the action taken based on the result.
> 
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>

This is preparatory patch for patch3.

Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com>

> ---
>   arch/x86/boot/compressed/sev.c | 13 ++++++-------
>   1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
> index 5ad0ff4664f1..49dc9661176d 100644
> --- a/arch/x86/boot/compressed/sev.c
> +++ b/arch/x86/boot/compressed/sev.c
> @@ -335,10 +335,9 @@ void do_boot_stage2_vc(struct pt_regs *regs, unsigned long exit_code)
>   		sev_es_terminate(SEV_TERM_SET_GEN, GHCB_SEV_ES_GEN_REQ);
>   }
>   
> -static void enforce_vmpl0(void)
> +static bool running_at_vmpl0(void *va)
>   {
>   	u64 attrs;
> -	int err;
>   
>   	/*
>   	 * RMPADJUST modifies RMP permissions of a lesser-privileged (numerically
> @@ -347,12 +346,11 @@ static void enforce_vmpl0(void)
>   	 *
>   	 * If the guest is running at VMPL0, it will succeed. Even if that operation
>   	 * modifies permission bits, it is still ok to do so currently because Linux
> -	 * SNP guests are supported only on VMPL0 so VMPL1 or higher permission masks
> -	 * changing is a don't-care.
> +	 * SNP guests running at VMPL0 only run at VMPL0, so VMPL1 or higher
> +	 * permission mask changes are a don't-care.
>   	 */
>   	attrs = 1;
> -	if (rmpadjust((unsigned long)&boot_ghcb_page, RMP_PG_SIZE_4K, attrs))
> -		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_NOT_VMPL0);
> +	return !rmpadjust((unsigned long)va, RMP_PG_SIZE_4K, attrs);
>   }
>   
>   /*
> @@ -588,7 +586,8 @@ void sev_enable(struct boot_params *bp)
>   		if (!(get_hv_features() & GHCB_HV_FT_SNP))
>   			sev_es_terminate(SEV_TERM_SET_GEN, GHCB_SNP_UNSUPPORTED);
>   
> -		enforce_vmpl0();
> +		if (!running_at_vmpl0(&boot_ghcb_page))
> +			sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_NOT_VMPL0);
>   	}
>   
>   	if (snp && !(sev_status & MSR_AMD64_SEV_SNP_ENABLED))


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

* Re: [PATCH v3 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page
  2024-03-25 22:26 ` [PATCH v3 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page Tom Lendacky
@ 2024-04-12 17:03   ` Gupta, Pankaj
  2024-04-17 20:40   ` Borislav Petkov
  1 sibling, 0 replies; 61+ messages in thread
From: Gupta, Pankaj @ 2024-04-12 17:03 UTC (permalink / raw)
  To: Tom Lendacky, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

On 3/25/2024 11:26 PM, Tom Lendacky wrote:
> During early boot phases, check for the presence of an SVSM when running
> as an SEV-SNP guest.
> 
> An SVSM is present if the 64-bit value at offset 0x148 into the secrets
> page is non-zero. If an SVSM is present, save the SVSM Calling Area
> address (CAA), located at offset 0x150 into the secrets page, and set
> the VMPL level of the guest, which should be non-zero, to indicate the
> presence of an SVSM.
> 
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>

Looks good.
Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com>

> ---
>   arch/x86/boot/compressed/sev.c    | 35 ++++++++---------
>   arch/x86/include/asm/sev-common.h |  4 ++
>   arch/x86/include/asm/sev.h        | 25 +++++++++++-
>   arch/x86/kernel/sev-shared.c      | 64 +++++++++++++++++++++++++++++++
>   arch/x86/kernel/sev.c             | 16 ++++++++
>   5 files changed, 125 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
> index 49dc9661176d..fe61ff630c7e 100644
> --- a/arch/x86/boot/compressed/sev.c
> +++ b/arch/x86/boot/compressed/sev.c
> @@ -12,6 +12,7 @@
>    */
>   #include "misc.h"
>   
> +#include <linux/mm.h>
>   #include <asm/bootparam.h>
>   #include <asm/pgtable_types.h>
>   #include <asm/sev.h>
> @@ -29,6 +30,15 @@
>   static struct ghcb boot_ghcb_page __aligned(PAGE_SIZE);
>   struct ghcb *boot_ghcb;
>   
> +/*
> + * SVSM related information:
> + *   When running under an SVSM, the VMPL that Linux is executing at must be
> + *   non-zero. The VMPL is therefore used to indicate the presence of an SVSM.
> + */
> +static u8 vmpl __section(".data");
> +static u64 boot_svsm_caa_pa __section(".data");
> +static struct svsm_ca *boot_svsm_caa __section(".data");
> +
>   /*
>    * Copy a version of this function here - insn-eval.c can't be used in
>    * pre-decompression code.
> @@ -335,24 +345,6 @@ void do_boot_stage2_vc(struct pt_regs *regs, unsigned long exit_code)
>   		sev_es_terminate(SEV_TERM_SET_GEN, GHCB_SEV_ES_GEN_REQ);
>   }
>   
> -static bool running_at_vmpl0(void *va)
> -{
> -	u64 attrs;
> -
> -	/*
> -	 * RMPADJUST modifies RMP permissions of a lesser-privileged (numerically
> -	 * higher) privilege level. Here, clear the VMPL1 permission mask of the
> -	 * GHCB page. If the guest is not running at VMPL0, this will fail.
> -	 *
> -	 * If the guest is running at VMPL0, it will succeed. Even if that operation
> -	 * modifies permission bits, it is still ok to do so currently because Linux
> -	 * SNP guests running at VMPL0 only run at VMPL0, so VMPL1 or higher
> -	 * permission mask changes are a don't-care.
> -	 */
> -	attrs = 1;
> -	return !rmpadjust((unsigned long)va, RMP_PG_SIZE_4K, attrs);
> -}
> -
>   /*
>    * SNP_FEATURES_IMPL_REQ is the mask of SNP features that will need
>    * guest side implementation for proper functioning of the guest. If any
> @@ -480,6 +472,13 @@ static bool early_snp_init(struct boot_params *bp)
>   	 */
>   	setup_cpuid_table(cc_info);
>   
> +	/*
> +	 * Record the SVSM Calling Area address (CAA) if the guest is not
> +	 * running at VMPL0. The CA will be used to communicate with the
> +	 * SVSM to perform the SVSM services.
> +	 */
> +	setup_svsm_ca(cc_info);
> +
>   	/*
>   	 * Pass run-time kernel a pointer to CC info via boot_params so EFI
>   	 * config table doesn't need to be searched again during early startup
> diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h
> index b463fcbd4b90..68a8cdf6fd6a 100644
> --- a/arch/x86/include/asm/sev-common.h
> +++ b/arch/x86/include/asm/sev-common.h
> @@ -159,6 +159,10 @@ struct snp_psc_desc {
>   #define GHCB_TERM_NOT_VMPL0		3	/* SNP guest is not running at VMPL-0 */
>   #define GHCB_TERM_CPUID			4	/* CPUID-validation failure */
>   #define GHCB_TERM_CPUID_HV		5	/* CPUID failure during hypervisor fallback */
> +#define GHCB_TERM_SECRETS_PAGE		6	/* Secrets page failure */
> +#define GHCB_TERM_NO_SVSM		7	/* SVSM is not advertised in the secrets page */
> +#define GHCB_TERM_SVSM_VMPL0		8	/* SVSM is present but has set VMPL to 0 */
> +#define GHCB_TERM_SVSM_CAA		9	/* SVSM is present but the CA is not page aligned */
>   
>   #define GHCB_RESP_CODE(v)		((v) & GHCB_MSR_INFO_MASK)
>   
> diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
> index 9477b4053bce..891e7d9a1f66 100644
> --- a/arch/x86/include/asm/sev.h
> +++ b/arch/x86/include/asm/sev.h
> @@ -152,9 +152,32 @@ struct snp_secrets_page_layout {
>   	u8 vmpck2[VMPCK_KEY_LEN];
>   	u8 vmpck3[VMPCK_KEY_LEN];
>   	struct secrets_os_area os_area;
> -	u8 rsvd3[3840];
> +
> +	u8 vmsa_tweak_bitmap[64];
> +
> +	/* SVSM fields */
> +	u64 svsm_base;
> +	u64 svsm_size;
> +	u64 svsm_caa;
> +	u32 svsm_max_version;
> +	u8 svsm_guest_vmpl;
> +	u8 rsvd3[3];
> +
> +	/* Remainder of page */
> +	u8 rsvd4[3744];
>   } __packed;
>   
> +/*
> + * The SVSM Calling Area (CA) related structures.
> + */
> +struct svsm_ca {
> +	u8 call_pending;
> +	u8 mem_available;
> +	u8 rsvd1[6];
> +
> +	u8 svsm_buffer[PAGE_SIZE - 8];
> +};
> +
>   #ifdef CONFIG_AMD_MEM_ENCRYPT
>   extern void __sev_es_ist_enter(struct pt_regs *regs);
>   extern void __sev_es_ist_exit(void);
> diff --git a/arch/x86/kernel/sev-shared.c b/arch/x86/kernel/sev-shared.c
> index 8b04958da5e7..66d33292eb78 100644
> --- a/arch/x86/kernel/sev-shared.c
> +++ b/arch/x86/kernel/sev-shared.c
> @@ -111,6 +111,24 @@ sev_es_terminate(unsigned int set, unsigned int reason)
>   		asm volatile("hlt\n" : : : "memory");
>   }
>   
> +static bool running_at_vmpl0(void *va)
> +{
> +	u64 attrs;
> +
> +	/*
> +	 * RMPADJUST modifies RMP permissions of a lesser-privileged (numerically
> +	 * higher) privilege level. Here, clear the VMPL1 permission mask of the
> +	 * GHCB page. If the guest is not running at VMPL0, this will fail.
> +	 *
> +	 * If the guest is running at VMPL0, it will succeed. Even if that operation
> +	 * modifies permission bits, it is still ok to do so currently because Linux
> +	 * SNP guests running at VMPL0 only run at VMPL0, so VMPL1 or higher
> +	 * permission mask changes are a don't-care.
> +	 */
> +	attrs = 1;
> +	return !rmpadjust((unsigned long)va, RMP_PG_SIZE_4K, attrs);
> +}
> +
>   /*
>    * The hypervisor features are available from GHCB version 2 onward.
>    */
> @@ -1267,3 +1285,49 @@ static enum es_result vc_check_opcode_bytes(struct es_em_ctxt *ctxt,
>   
>   	return ES_UNSUPPORTED;
>   }
> +
> +/*
> + * Maintain the GPA of the SVSM Calling Area (CA) in order to utilize the SVSM
> + * services needed when not running in VMPL0.
> + */
> +static void __head setup_svsm_ca(const struct cc_blob_sev_info *cc_info)
> +{
> +	struct snp_secrets_page_layout *secrets_page;
> +	u64 caa;
> +
> +	BUILD_BUG_ON(sizeof(*secrets_page) != PAGE_SIZE);
> +
> +	/*
> +	 * Use __pa() since this routine is running identity mapped when
> +	 * called, both by the decompressor code and the early kernel code.
> +	 */
> +	if (running_at_vmpl0((void *)__pa(&boot_ghcb_page)))
> +		return;
> +
> +	/*
> +	 * Not running at VMPL0, ensure everything has been properly supplied
> +	 * for running under an SVSM.
> +	 */
> +	if (!cc_info || !cc_info->secrets_phys || cc_info->secrets_len != PAGE_SIZE)
> +		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_SECRETS_PAGE);
> +
> +	secrets_page = (struct snp_secrets_page_layout *)cc_info->secrets_phys;
> +	if (!secrets_page->svsm_size)
> +		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_NO_SVSM);
> +
> +	if (!secrets_page->svsm_guest_vmpl)
> +		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_SVSM_VMPL0);
> +
> +	vmpl = secrets_page->svsm_guest_vmpl;
> +
> +	caa = secrets_page->svsm_caa;
> +	if (!PAGE_ALIGNED(caa))
> +		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_SVSM_CAA);
> +
> +	/*
> +	 * The CA is identity mapped when this routine is called, both by the
> +	 * decompressor code and the early kernel code.
> +	 */
> +	boot_svsm_caa = (struct svsm_ca *)caa;
> +	boot_svsm_caa_pa = caa;
> +}
> diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
> index b59b09c2f284..64799a04feb4 100644
> --- a/arch/x86/kernel/sev.c
> +++ b/arch/x86/kernel/sev.c
> @@ -135,6 +135,15 @@ struct ghcb_state {
>   static DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data);
>   static DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa);
>   
> +/*
> + * SVSM related information:
> + *   When running under an SVSM, the VMPL that Linux is executing at must be
> + *   non-zero. The VMPL is therefore used to indicate the presence of an SVSM.
> + */
> +static u8 vmpl __ro_after_init;
> +static struct svsm_ca *boot_svsm_caa __ro_after_init;
> +static u64 boot_svsm_caa_pa __ro_after_init;
> +
>   struct sev_config {
>   	__u64 debug		: 1,
>   
> @@ -2122,6 +2131,13 @@ bool __head snp_init(struct boot_params *bp)
>   
>   	setup_cpuid_table(cc_info);
>   
> +	/*
> +	 * Record the SVSM Calling Area address (CAA) if the guest is not
> +	 * running at VMPL0. The CA will be used to communicate with the
> +	 * SVSM to perform the SVSM services.
> +	 */
> +	setup_svsm_ca(cc_info);
> +
>   	/*
>   	 * The CC blob will be used later to access the secrets page. Cache
>   	 * it here like the boot kernel does.


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

* Re: [PATCH v3 07/14] x86/sev: Provide SVSM discovery support
  2024-03-25 22:26 ` [PATCH v3 07/14] x86/sev: Provide SVSM discovery support Tom Lendacky
@ 2024-04-15 16:12   ` Gupta, Pankaj
  0 siblings, 0 replies; 61+ messages in thread
From: Gupta, Pankaj @ 2024-04-15 16:12 UTC (permalink / raw)
  To: Tom Lendacky, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

On 3/25/2024 11:26 PM, Tom Lendacky wrote:
> The SVSM specification documents an alternative method of discovery for
> the SVSM using a reserved CPUID bit and a reserved MSR.
> 
> For the CPUID support, the SNP CPUID table is updated to set bit 28 of
> the EAX register of the 0x8000001f leaf when an SVSM is present. This bit
> has been reserved for use in this capacity.
> 
> For the MSR support, a new reserved MSR 0xc001f000 has been defined. A #VC
> should be generated when accessing this MSR. The #VC handler is expected
> to ignore writes to this MSR and return the physical calling area address
> (CAA) on reads of this MSR.
> 
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>

Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com>

> ---
>   arch/x86/include/asm/cpufeatures.h |  1 +
>   arch/x86/include/asm/msr-index.h   |  2 ++
>   arch/x86/kernel/sev-shared.c       | 11 +++++++++++
>   arch/x86/kernel/sev.c              | 17 +++++++++++++++++
>   4 files changed, 31 insertions(+)
> 
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index a38f8f9ba657..51e7c879f057 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -446,6 +446,7 @@
>   #define X86_FEATURE_V_TSC_AUX		(19*32+ 9) /* "" Virtual TSC_AUX */
>   #define X86_FEATURE_SME_COHERENT	(19*32+10) /* "" AMD hardware-enforced cache coherency */
>   #define X86_FEATURE_DEBUG_SWAP		(19*32+14) /* AMD SEV-ES full debug state swap support */
> +#define X86_FEATURE_SVSM_PRESENT	(19*32+28) /* "" SNP SVSM is present */
>   
>   /* AMD-defined Extended Feature 2 EAX, CPUID level 0x80000021 (EAX), word 20 */
>   #define X86_FEATURE_NO_NESTED_DATA_BP	(20*32+ 0) /* "" No Nested Data Breakpoints */
> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> index 05956bd8bacf..cc4de3379265 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -654,6 +654,8 @@
>   #define MSR_AMD64_RMP_BASE		0xc0010132
>   #define MSR_AMD64_RMP_END		0xc0010133
>   
> +#define MSR_SVSM_CAA			0xc001f000
> +
>   /* AMD Collaborative Processor Performance Control MSRs */
>   #define MSR_AMD_CPPC_CAP1		0xc00102b0
>   #define MSR_AMD_CPPC_ENABLE		0xc00102b1
> diff --git a/arch/x86/kernel/sev-shared.c b/arch/x86/kernel/sev-shared.c
> index e63c0a6eccd6..17eb42c4ae71 100644
> --- a/arch/x86/kernel/sev-shared.c
> +++ b/arch/x86/kernel/sev-shared.c
> @@ -1559,6 +1559,8 @@ static enum es_result vc_check_opcode_bytes(struct es_em_ctxt *ctxt,
>   static void __head setup_svsm_ca(const struct cc_blob_sev_info *cc_info)
>   {
>   	struct snp_secrets_page_layout *secrets_page;
> +	struct snp_cpuid_table *cpuid_table;
> +	unsigned int i;
>   	u64 caa;
>   
>   	BUILD_BUG_ON(sizeof(*secrets_page) != PAGE_SIZE);
> @@ -1596,4 +1598,13 @@ static void __head setup_svsm_ca(const struct cc_blob_sev_info *cc_info)
>   	 */
>   	boot_svsm_caa = (struct svsm_ca *)caa;
>   	boot_svsm_caa_pa = caa;
> +
> +	/* Advertise the SVSM presence via CPUID. */
> +	cpuid_table = (struct snp_cpuid_table *)snp_cpuid_get_table();
> +	for (i = 0; i < cpuid_table->count; i++) {
> +		struct snp_cpuid_fn *fn = &cpuid_table->fn[i];
> +
> +		if (fn->eax_in == 0x8000001f)
> +			fn->eax |= BIT(28);
> +	}
>   }
> diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
> index ea8b43a0f01b..7f399ea87a3c 100644
> --- a/arch/x86/kernel/sev.c
> +++ b/arch/x86/kernel/sev.c
> @@ -1347,12 +1347,29 @@ int __init sev_es_efi_map_ghcbs(pgd_t *pgd)
>   	return 0;
>   }
>   
> +static enum es_result vc_handle_svsm_caa_msr(struct es_em_ctxt *ctxt)
> +{
> +	struct pt_regs *regs = ctxt->regs;
> +
> +	/* Writes to the SVSM CAA msr are ignored */
> +	if (ctxt->insn.opcode.bytes[1] == 0x30)
> +		return ES_OK;
> +
> +	regs->ax = lower_32_bits(this_cpu_read(svsm_caa_pa));
> +	regs->dx = upper_32_bits(this_cpu_read(svsm_caa_pa));
> +
> +	return ES_OK;
> +}
> +
>   static enum es_result vc_handle_msr(struct ghcb *ghcb, struct es_em_ctxt *ctxt)
>   {
>   	struct pt_regs *regs = ctxt->regs;
>   	enum es_result ret;
>   	u64 exit_info_1;
>   
> +	if (regs->cx == MSR_SVSM_CAA)
> +		return vc_handle_svsm_caa_msr(ctxt);
> +
>   	/* Is it a WRMSR? */
>   	exit_info_1 = (ctxt->insn.opcode.bytes[1] == 0x30) ? 1 : 0;
>   


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

* Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
  2024-04-12 15:52     ` Tom Lendacky
@ 2024-04-15 19:16       ` Tom Lendacky
  2024-04-15 19:48         ` Kuppuswamy Sathyanarayanan
  2024-04-16  6:05         ` Dan Williams
  0 siblings, 2 replies; 61+ messages in thread
From: Tom Lendacky @ 2024-04-15 19:16 UTC (permalink / raw)
  To: Kuppuswamy Sathyanarayanan, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra, Joel Becker, Christoph Hellwig

On 4/12/24 10:52, Tom Lendacky wrote:
> On 4/9/24 13:12, Kuppuswamy Sathyanarayanan wrote:
>> On 3/25/24 3:26 PM, Tom Lendacky wrote:
>>> Config-fs provides support to hide individual attribute entries. Using
>>> this support, base the display of the SVSM related entries on the 
>>> presence
>>> of an SVSM.
>>>
>>> Cc: Joel Becker <jlbec@evilplan.org>
>>> Cc: Christoph Hellwig <hch@lst.de>
>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>>> ---
>>>   arch/x86/coco/core.c        |  4 ++++
>>>   drivers/virt/coco/tsm.c     | 14 ++++++++++----
>>>   include/linux/cc_platform.h |  8 ++++++++
>>>   3 files changed, 22 insertions(+), 4 deletions(-)
>>>

>>
>> Any comment about the following query? I think introducing a CC flag 
>> for this use
>> case is over kill.
>>
>> https://lore.kernel.org/lkml/6b90b223-46e0-4e6d-a17c-5caf72e3c949@linux.intel.com/
> 
> If you don't think TDX will be able to make use of the SVSM attribute I 
> can look at adding a callback. But I was waiting to see if anyone else 
> had comments, for or against, before re-doing it all.
> 

What about something like this (applied on top of patch 13):

diff --git a/arch/x86/coco/core.c b/arch/x86/coco/core.c
index efa0f648f754..d07be9d05cd0 100644
--- a/arch/x86/coco/core.c
+++ b/arch/x86/coco/core.c
@@ -12,7 +12,6 @@
  
  #include <asm/coco.h>
  #include <asm/processor.h>
-#include <asm/sev.h>
  
  enum cc_vendor cc_vendor __ro_after_init = CC_VENDOR_NONE;
  u64 cc_mask __ro_after_init;
@@ -79,9 +78,6 @@ static bool noinstr amd_cc_platform_has(enum cc_attr attr)
  	case CC_ATTR_GUEST_STATE_ENCRYPT:
  		return sev_status & MSR_AMD64_SEV_ES_ENABLED;
  
-	case CC_ATTR_GUEST_SVSM_PRESENT:
-		return snp_get_vmpl();
-
  	/*
  	 * With SEV, the rep string I/O instructions need to be unrolled
  	 * but SEV-ES supports them through the #VC handler.
diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
index 0d2c9926a97c..68c881a50026 100644
--- a/drivers/virt/coco/sev-guest/sev-guest.c
+++ b/drivers/virt/coco/sev-guest/sev-guest.c
@@ -1036,6 +1036,17 @@ static int sev_report_new(struct tsm_report *report, void *data)
  	return 0;
  }
  
+static bool sev_tsm_visibility(enum tsm_type type)
+{
+	/* Check for SVSM-related attributes */
+	switch (type) {
+	case TSM_TYPE_SERVICE_PROVIDER:
+		return snp_get_vmpl();
+	default:
+		return false;
+	}
+}
+
  static struct tsm_ops sev_tsm_ops = {
  	.name = KBUILD_MODNAME,
  	.report_new = sev_report_new,
@@ -1126,7 +1137,8 @@ static int __init sev_guest_probe(struct platform_device *pdev)
  	/* Set the privlevel_floor attribute based on the current VMPL */
  	sev_tsm_ops.privlevel_floor = snp_get_vmpl();
  
-	ret = tsm_register(&sev_tsm_ops, snp_dev, &tsm_report_extra_type);
+	ret = tsm_register(&sev_tsm_ops, snp_dev, &tsm_report_extra_type,
+			   sev_tsm_visibility);
  	if (ret)
  		goto e_free_cert_data;
  
diff --git a/drivers/virt/coco/tdx-guest/tdx-guest.c b/drivers/virt/coco/tdx-guest/tdx-guest.c
index 1253bf76b570..0fd8e60d7bee 100644
--- a/drivers/virt/coco/tdx-guest/tdx-guest.c
+++ b/drivers/virt/coco/tdx-guest/tdx-guest.c
@@ -301,7 +301,7 @@ static int __init tdx_guest_init(void)
  		goto free_misc;
  	}
  
-	ret = tsm_register(&tdx_tsm_ops, NULL, NULL);
+	ret = tsm_register(&tdx_tsm_ops, NULL, NULL, NULL);
  	if (ret)
  		goto free_quote;
  
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
index d30471874e87..e73840aed13d 100644
--- a/drivers/virt/coco/tsm.c
+++ b/drivers/virt/coco/tsm.c
@@ -16,6 +16,7 @@ static struct tsm_provider {
  	const struct tsm_ops *ops;
  	const struct config_item_type *type;
  	void *data;
+	tsm_visibility_t visibility;
  } provider;
  static DECLARE_RWSEM(tsm_rwsem);
  
@@ -64,10 +65,13 @@ static struct tsm_report_state *to_state(struct tsm_report *report)
  	return container_of(report, struct tsm_report_state, report);
  }
  
-static bool provider_visibility(const struct config_item *item,
-				const struct configfs_attribute *attr)
+static bool service_provider_visibility(const struct config_item *item,
+					const struct configfs_attribute *attr)
  {
-	return cc_platform_has(CC_ATTR_GUEST_SVSM_PRESENT);
+	if (!provider.visibility)
+		return true;
+
+	return provider.visibility(TSM_TYPE_SERVICE_PROVIDER);
  }
  
  static int try_advance_write_generation(struct tsm_report *report)
@@ -150,7 +154,7 @@ static ssize_t tsm_report_service_provider_store(struct config_item *cfg,
  
  	return len;
  }
-CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_provider, provider_visibility);
+CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_provider, service_provider_visibility);
  
  static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
  					     const char *buf, size_t len)
@@ -171,7 +175,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
  
  	return len;
  }
-CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_guid, provider_visibility);
+CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_guid, service_provider_visibility);
  
  static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg,
  							 const char *buf, size_t len)
@@ -192,7 +196,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg
  
  	return len;
  }
-CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_manifest_version, provider_visibility);
+CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_manifest_version, service_provider_visibility);
  
  static ssize_t tsm_report_inblob_write(struct config_item *cfg,
  				       const void *buf, size_t count)
@@ -339,7 +343,8 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,
  
  	return tsm_report_read(report, buf, count, TSM_MANIFEST);
  }
-CONFIGFS_BIN_ATTR_VISIBLE_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX, provider_visibility);
+CONFIGFS_BIN_ATTR_VISIBLE_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX,
+			     service_provider_visibility);
  
  #define TSM_DEFAULT_ATTRS() \
  	&tsm_report_attr_generation, \
@@ -449,7 +454,8 @@ static struct configfs_subsystem tsm_configfs = {
  };
  
  int tsm_register(const struct tsm_ops *ops, void *priv,
-		 const struct config_item_type *type)
+		 const struct config_item_type *type,
+		 tsm_visibility_t visibility)
  {
  	const struct tsm_ops *conflict;
  
@@ -468,6 +474,7 @@ int tsm_register(const struct tsm_ops *ops, void *priv,
  	provider.ops = ops;
  	provider.data = priv;
  	provider.type = type;
+	provider.visibility = visibility;
  	return 0;
  }
  EXPORT_SYMBOL_GPL(tsm_register);
@@ -480,6 +487,7 @@ int tsm_unregister(const struct tsm_ops *ops)
  	provider.ops = NULL;
  	provider.data = NULL;
  	provider.type = NULL;
+	provider.visibility = NULL;
  	return 0;
  }
  EXPORT_SYMBOL_GPL(tsm_unregister);
diff --git a/include/linux/cc_platform.h b/include/linux/cc_platform.h
index f1b4266c1484..cb0d6cd1c12f 100644
--- a/include/linux/cc_platform.h
+++ b/include/linux/cc_platform.h
@@ -90,14 +90,6 @@ enum cc_attr {
  	 * Examples include TDX Guest.
  	 */
  	CC_ATTR_HOTPLUG_DISABLED,
-
-	/**
-	 * @CC_ATTR_GUEST_SVSM_PRESENT: Guest is running under an SVSM
-	 *
-	 * The platform/OS is running as a guest/virtual machine and is
-	 * running under a Secure VM Service Module (SVSM).
-	 */
-	CC_ATTR_GUEST_SVSM_PRESENT,
  };
  
  #ifdef CONFIG_ARCH_HAS_CC_PLATFORM
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
index 27cc97fe8dcd..5aaf626d178d 100644
--- a/include/linux/tsm.h
+++ b/include/linux/tsm.h
@@ -74,7 +74,20 @@ extern const struct config_item_type tsm_report_default_type;
  /* publish @privlevel, @privlevel_floor, and @auxblob attributes */
  extern const struct config_item_type tsm_report_extra_type;
  
+/*
+ * Used to indicate the attribute group type to the visibility callback to
+ * avoid the callback having to examine the attribute name.
+ */
+enum tsm_type {
+	TSM_TYPE_SERVICE_PROVIDER,
+
+	TSM_TYPE_MAX
+};
+
+typedef bool (*tsm_visibility_t)(enum tsm_type type);
+
  int tsm_register(const struct tsm_ops *ops, void *priv,
-		 const struct config_item_type *type);
+		 const struct config_item_type *type,
+		 tsm_visibility_t visibility);
  int tsm_unregister(const struct tsm_ops *ops);
  #endif /* __TSM_H */

> Thanks,
> Tom
> 

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

* Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
  2024-04-15 19:16       ` Tom Lendacky
@ 2024-04-15 19:48         ` Kuppuswamy Sathyanarayanan
  2024-04-15 20:13           ` Tom Lendacky
  2024-04-16  6:05         ` Dan Williams
  1 sibling, 1 reply; 61+ messages in thread
From: Kuppuswamy Sathyanarayanan @ 2024-04-15 19:48 UTC (permalink / raw)
  To: Tom Lendacky, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra, Joel Becker, Christoph Hellwig

Hi,

On 4/15/24 12:16 PM, Tom Lendacky wrote:
> On 4/12/24 10:52, Tom Lendacky wrote:
>> On 4/9/24 13:12, Kuppuswamy Sathyanarayanan wrote:
>>> On 3/25/24 3:26 PM, Tom Lendacky wrote:
>>>> Config-fs provides support to hide individual attribute entries. Using
>>>> this support, base the display of the SVSM related entries on the presence
>>>> of an SVSM.
>>>>
>>>> Cc: Joel Becker <jlbec@evilplan.org>
>>>> Cc: Christoph Hellwig <hch@lst.de>
>>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>>>> ---
>>>>   arch/x86/coco/core.c        |  4 ++++
>>>>   drivers/virt/coco/tsm.c     | 14 ++++++++++----
>>>>   include/linux/cc_platform.h |  8 ++++++++
>>>>   3 files changed, 22 insertions(+), 4 deletions(-)
>>>>
>
>>>
>>> Any comment about the following query? I think introducing a CC flag for this use
>>> case is over kill.
>>>
>>> https://lore.kernel.org/lkml/6b90b223-46e0-4e6d-a17c-5caf72e3c949@linux.intel.com/
>>
>> If you don't think TDX will be able to make use of the SVSM attribute I can look at adding a callback. But I was waiting to see if anyone else had comments, for or against, before re-doing it all.
>>
>
> What about something like this (applied on top of patch 13):
>
> diff --git a/arch/x86/coco/core.c b/arch/x86/coco/core.c
> index efa0f648f754..d07be9d05cd0 100644
> --- a/arch/x86/coco/core.c
> +++ b/arch/x86/coco/core.c
> @@ -12,7 +12,6 @@
>  
>  #include <asm/coco.h>
>  #include <asm/processor.h>
> -#include <asm/sev.h>
>  
>  enum cc_vendor cc_vendor __ro_after_init = CC_VENDOR_NONE;
>  u64 cc_mask __ro_after_init;
> @@ -79,9 +78,6 @@ static bool noinstr amd_cc_platform_has(enum cc_attr attr)
>      case CC_ATTR_GUEST_STATE_ENCRYPT:
>          return sev_status & MSR_AMD64_SEV_ES_ENABLED;
>  
> -    case CC_ATTR_GUEST_SVSM_PRESENT:
> -        return snp_get_vmpl();
> -
>      /*
>       * With SEV, the rep string I/O instructions need to be unrolled
>       * but SEV-ES supports them through the #VC handler.
> diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
> index 0d2c9926a97c..68c881a50026 100644
> --- a/drivers/virt/coco/sev-guest/sev-guest.c
> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
> @@ -1036,6 +1036,17 @@ static int sev_report_new(struct tsm_report *report, void *data)
>      return 0;
>  }
>  
> +static bool sev_tsm_visibility(enum tsm_type type)
> +{
> +    /* Check for SVSM-related attributes */
> +    switch (type) {
> +    case TSM_TYPE_SERVICE_PROVIDER:
> +        return snp_get_vmpl();
> +    default:
> +        return false;
> +    }
> +}
> +
>  static struct tsm_ops sev_tsm_ops = {
>      .name = KBUILD_MODNAME,
>      .report_new = sev_report_new,
> @@ -1126,7 +1137,8 @@ static int __init sev_guest_probe(struct platform_device *pdev)
>      /* Set the privlevel_floor attribute based on the current VMPL */
>      sev_tsm_ops.privlevel_floor = snp_get_vmpl();
>  
> -    ret = tsm_register(&sev_tsm_ops, snp_dev, &tsm_report_extra_type);
> +    ret = tsm_register(&sev_tsm_ops, snp_dev, &tsm_report_extra_type,
> +               sev_tsm_visibility);
>      if (ret)
>          goto e_free_cert_data;
>  
> diff --git a/drivers/virt/coco/tdx-guest/tdx-guest.c b/drivers/virt/coco/tdx-guest/tdx-guest.c
> index 1253bf76b570..0fd8e60d7bee 100644
> --- a/drivers/virt/coco/tdx-guest/tdx-guest.c
> +++ b/drivers/virt/coco/tdx-guest/tdx-guest.c
> @@ -301,7 +301,7 @@ static int __init tdx_guest_init(void)
>          goto free_misc;
>      }
>  
> -    ret = tsm_register(&tdx_tsm_ops, NULL, NULL);
> +    ret = tsm_register(&tdx_tsm_ops, NULL, NULL, NULL);
>      if (ret)
>          goto free_quote;
>  
> diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
> index d30471874e87..e73840aed13d 100644
> --- a/drivers/virt/coco/tsm.c
> +++ b/drivers/virt/coco/tsm.c
> @@ -16,6 +16,7 @@ static struct tsm_provider {
>      const struct tsm_ops *ops;
>      const struct config_item_type *type;
>      void *data;
> +    tsm_visibility_t visibility;
>  } provider;
>  static DECLARE_RWSEM(tsm_rwsem);
>  
> @@ -64,10 +65,13 @@ static struct tsm_report_state *to_state(struct tsm_report *report)
>      return container_of(report, struct tsm_report_state, report);
>  }
>  
> -static bool provider_visibility(const struct config_item *item,
> -                const struct configfs_attribute *attr)
> +static bool service_provider_visibility(const struct config_item *item,
> +                    const struct configfs_attribute *attr)
>  {
> -    return cc_platform_has(CC_ATTR_GUEST_SVSM_PRESENT);
> +    if (!provider.visibility)
> +        return true;
> +
> +    return provider.visibility(TSM_TYPE_SERVICE_PROVIDER);
>  }
>  
>  static int try_advance_write_generation(struct tsm_report *report)
> @@ -150,7 +154,7 @@ static ssize_t tsm_report_service_provider_store(struct config_item *cfg,
>  
>      return len;
>  }
> -CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_provider, provider_visibility);
> +CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_provider, service_provider_visibility);
>  
>  static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
>                           const char *buf, size_t len)
> @@ -171,7 +175,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
>  
>      return len;
>  }
> -CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_guid, provider_visibility);
> +CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_guid, service_provider_visibility);
>  
>  static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg,
>                               const char *buf, size_t len)
> @@ -192,7 +196,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg
>  
>      return len;
>  }
> -CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_manifest_version, provider_visibility);
> +CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_manifest_version, service_provider_visibility);
>  
>  static ssize_t tsm_report_inblob_write(struct config_item *cfg,
>                         const void *buf, size_t count)
> @@ -339,7 +343,8 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,
>  
>      return tsm_report_read(report, buf, count, TSM_MANIFEST);
>  }
> -CONFIGFS_BIN_ATTR_VISIBLE_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX, provider_visibility);
> +CONFIGFS_BIN_ATTR_VISIBLE_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX,
> +                 service_provider_visibility);
>  
>  #define TSM_DEFAULT_ATTRS() \
>      &tsm_report_attr_generation, \
> @@ -449,7 +454,8 @@ static struct configfs_subsystem tsm_configfs = {
>  };
>  
>  int tsm_register(const struct tsm_ops *ops, void *priv,
> -         const struct config_item_type *type)
> +         const struct config_item_type *type,
> +         tsm_visibility_t visibility)
>  {
>      const struct tsm_ops *conflict;
>  
> @@ -468,6 +474,7 @@ int tsm_register(const struct tsm_ops *ops, void *priv,
>      provider.ops = ops;
>      provider.data = priv;
>      provider.type = type;
> +    provider.visibility = visibility;
>      return 0;
>  }
>  EXPORT_SYMBOL_GPL(tsm_register);
> @@ -480,6 +487,7 @@ int tsm_unregister(const struct tsm_ops *ops)
>      provider.ops = NULL;
>      provider.data = NULL;
>      provider.type = NULL;
> +    provider.visibility = NULL;
>      return 0;
>  }
>  EXPORT_SYMBOL_GPL(tsm_unregister);
> diff --git a/include/linux/cc_platform.h b/include/linux/cc_platform.h
> index f1b4266c1484..cb0d6cd1c12f 100644
> --- a/include/linux/cc_platform.h
> +++ b/include/linux/cc_platform.h
> @@ -90,14 +90,6 @@ enum cc_attr {
>       * Examples include TDX Guest.
>       */
>      CC_ATTR_HOTPLUG_DISABLED,
> -
> -    /**
> -     * @CC_ATTR_GUEST_SVSM_PRESENT: Guest is running under an SVSM
> -     *
> -     * The platform/OS is running as a guest/virtual machine and is
> -     * running under a Secure VM Service Module (SVSM).
> -     */
> -    CC_ATTR_GUEST_SVSM_PRESENT,
>  };
>  
>  #ifdef CONFIG_ARCH_HAS_CC_PLATFORM
> diff --git a/include/linux/tsm.h b/include/linux/tsm.h
> index 27cc97fe8dcd..5aaf626d178d 100644
> --- a/include/linux/tsm.h
> +++ b/include/linux/tsm.h
> @@ -74,7 +74,20 @@ extern const struct config_item_type tsm_report_default_type;
>  /* publish @privlevel, @privlevel_floor, and @auxblob attributes */
>  extern const struct config_item_type tsm_report_extra_type;
>  
> +/*
> + * Used to indicate the attribute group type to the visibility callback to
> + * avoid the callback having to examine the attribute name.

Checking the attribute name will give more flexibility, right? Since it is one time
check, it should not be costly, right?

> +enum tsm_type {
> +    TSM_TYPE_SERVICE_PROVIDER,
> +
> +    TSM_TYPE_MAX
> +};
> +
> +typedef bool (*tsm_visibility_t)(enum tsm_type type);
> +
>  int tsm_register(const struct tsm_ops *ops, void *priv,
> -         const struct config_item_type *type);
> +         const struct config_item_type *type,
> +         tsm_visibility_t visibility);
>  int tsm_unregister(const struct tsm_ops *ops);
>  #endif /* __TSM_H */
>

Why not add a callback in tsm_ops?

>> Thanks,
>> Tom
>>
-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer


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

* Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
  2024-04-15 19:48         ` Kuppuswamy Sathyanarayanan
@ 2024-04-15 20:13           ` Tom Lendacky
  2024-04-15 21:50             ` Kuppuswamy Sathyanarayanan
  2024-04-16  6:08             ` Dan Williams
  0 siblings, 2 replies; 61+ messages in thread
From: Tom Lendacky @ 2024-04-15 20:13 UTC (permalink / raw)
  To: Kuppuswamy Sathyanarayanan, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra, Joel Becker, Christoph Hellwig

On 4/15/24 14:48, Kuppuswamy Sathyanarayanan wrote:
> Hi,
> 
> On 4/15/24 12:16 PM, Tom Lendacky wrote:
>> On 4/12/24 10:52, Tom Lendacky wrote:
>>> On 4/9/24 13:12, Kuppuswamy Sathyanarayanan wrote:
>>>> On 3/25/24 3:26 PM, Tom Lendacky wrote:
>>>>> Config-fs provides support to hide individual attribute entries. Using
>>>>> this support, base the display of the SVSM related entries on the presence
>>>>> of an SVSM.
>>>>>
>>>>> Cc: Joel Becker <jlbec@evilplan.org>
>>>>> Cc: Christoph Hellwig <hch@lst.de>
>>>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>>>>> ---
>>>>>    arch/x86/coco/core.c        |  4 ++++
>>>>>    drivers/virt/coco/tsm.c     | 14 ++++++++++----
>>>>>    include/linux/cc_platform.h |  8 ++++++++
>>>>>    3 files changed, 22 insertions(+), 4 deletions(-)
>>>>>
>>
>>>>
>>>> Any comment about the following query? I think introducing a CC flag for this use
>>>> case is over kill.
>>>>
>>>> https://lore.kernel.org/lkml/6b90b223-46e0-4e6d-a17c-5caf72e3c949@linux.intel.com/
>>>
>>> If you don't think TDX will be able to make use of the SVSM attribute I can look at adding a callback. But I was waiting to see if anyone else had comments, for or against, before re-doing it all.
>>>
>>
>> What about something like this (applied on top of patch 13):
>>

>> diff --git a/include/linux/tsm.h b/include/linux/tsm.h
>> index 27cc97fe8dcd..5aaf626d178d 100644
>> --- a/include/linux/tsm.h
>> +++ b/include/linux/tsm.h
>> @@ -74,7 +74,20 @@ extern const struct config_item_type tsm_report_default_type;
>>   /* publish @privlevel, @privlevel_floor, and @auxblob attributes */
>>   extern const struct config_item_type tsm_report_extra_type;
>>   
>> +/*
>> + * Used to indicate the attribute group type to the visibility callback to
>> + * avoid the callback having to examine the attribute name.
> 
> Checking the attribute name will give more flexibility, right? Since it is one time
> check, it should not be costly, right?

I thought about checking the name(s), but what if in the future another 
attribute is added, then you have to remember to update multiple places. 
This way you have an enum that represents the related attributes. Is 
there a scenario where you would want to not hide all attributes that 
are related? String comparisons just seem awkward to me.

I suppose the config_item and configfs_attr could also be supplied on 
the callback if that's a requirement.

> 
>> +enum tsm_type {
>> +    TSM_TYPE_SERVICE_PROVIDER,
>> +
>> +    TSM_TYPE_MAX
>> +};
>> +
>> +typedef bool (*tsm_visibility_t)(enum tsm_type type);
>> +
>>   int tsm_register(const struct tsm_ops *ops, void *priv,
>> -         const struct config_item_type *type);
>> +         const struct config_item_type *type,
>> +         tsm_visibility_t visibility);
>>   int tsm_unregister(const struct tsm_ops *ops);
>>   #endif /* __TSM_H */
>>
> 
> Why not add a callback in tsm_ops?

That's an option, too. Either way works for me.

Thanks,
Tom

> 
>>> Thanks,
>>> Tom
>>>

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

* Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
  2024-04-15 20:13           ` Tom Lendacky
@ 2024-04-15 21:50             ` Kuppuswamy Sathyanarayanan
  2024-04-15 22:03               ` Tom Lendacky
  2024-04-16  6:08             ` Dan Williams
  1 sibling, 1 reply; 61+ messages in thread
From: Kuppuswamy Sathyanarayanan @ 2024-04-15 21:50 UTC (permalink / raw)
  To: Tom Lendacky, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra, Joel Becker, Christoph Hellwig


On 4/15/24 1:13 PM, Tom Lendacky wrote:
> On 4/15/24 14:48, Kuppuswamy Sathyanarayanan wrote:
>> Hi,
>>
>> On 4/15/24 12:16 PM, Tom Lendacky wrote:
>>> On 4/12/24 10:52, Tom Lendacky wrote:
>>>> On 4/9/24 13:12, Kuppuswamy Sathyanarayanan wrote:
>>>>> On 3/25/24 3:26 PM, Tom Lendacky wrote:
>>>>>> Config-fs provides support to hide individual attribute entries. Using
>>>>>> this support, base the display of the SVSM related entries on the presence
>>>>>> of an SVSM.
>>>>>>
>>>>>> Cc: Joel Becker <jlbec@evilplan.org>
>>>>>> Cc: Christoph Hellwig <hch@lst.de>
>>>>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>>>>>> ---
>>>>>>    arch/x86/coco/core.c        |  4 ++++
>>>>>>    drivers/virt/coco/tsm.c     | 14 ++++++++++----
>>>>>>    include/linux/cc_platform.h |  8 ++++++++
>>>>>>    3 files changed, 22 insertions(+), 4 deletions(-)
>>>>>>
>>>
>>>>>
>>>>> Any comment about the following query? I think introducing a CC flag for this use
>>>>> case is over kill.
>>>>>
>>>>> https://lore.kernel.org/lkml/6b90b223-46e0-4e6d-a17c-5caf72e3c949@linux.intel.com/
>>>>
>>>> If you don't think TDX will be able to make use of the SVSM attribute I can look at adding a callback. But I was waiting to see if anyone else had comments, for or against, before re-doing it all.
>>>>
>>>
>>> What about something like this (applied on top of patch 13):
>>>
>
>>> diff --git a/include/linux/tsm.h b/include/linux/tsm.h
>>> index 27cc97fe8dcd..5aaf626d178d 100644
>>> --- a/include/linux/tsm.h
>>> +++ b/include/linux/tsm.h
>>> @@ -74,7 +74,20 @@ extern const struct config_item_type tsm_report_default_type;
>>>   /* publish @privlevel, @privlevel_floor, and @auxblob attributes */
>>>   extern const struct config_item_type tsm_report_extra_type;
>>>   +/*
>>> + * Used to indicate the attribute group type to the visibility callback to
>>> + * avoid the callback having to examine the attribute name.
>>
>> Checking the attribute name will give more flexibility, right? Since it is one time
>> check, it should not be costly, right?
>
> I thought about checking the name(s), but what if in the future another attribute is added, then you have to remember to update multiple places. This way you have an enum that represents the related attributes. Is there a 

I think it depends on how you implement the visibility function. If the vendor driver allows all attributes by default and denies few selected ones, you don't have to update the vendor driver for all new attributes. Letting the vendor driver decide whether to support any new attributes makes sense to me.

> scenario where you would want to not hide all attributes that are related? String comparisons just seem awkward to me.
>
> I suppose the config_item and configfs_attr could also be supplied on the callback if that's a requirement.


I am ok with enum based checks. But lets see what others think. Personally I think checking config attr name is more flexible.


>
>>
>>> +enum tsm_type {
>>> +    TSM_TYPE_SERVICE_PROVIDER,
>>> +
>>> +    TSM_TYPE_MAX
>>> +};
>>> +
>>> +typedef bool (*tsm_visibility_t)(enum tsm_type type);
>>> +
>>>   int tsm_register(const struct tsm_ops *ops, void *priv,
>>> -         const struct config_item_type *type);
>>> +         const struct config_item_type *type,
>>> +         tsm_visibility_t visibility);
>>>   int tsm_unregister(const struct tsm_ops *ops);
>>>   #endif /* __TSM_H */
>>>
>>
>> Why not add a callback in tsm_ops?
>
> That's an option, too. Either way works for me.
>
> Thanks,
> Tom
>
>>
>>>> Thanks,
>>>> Tom
>>>>
>
-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer


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

* Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
  2024-04-15 21:50             ` Kuppuswamy Sathyanarayanan
@ 2024-04-15 22:03               ` Tom Lendacky
  2024-04-16  6:09                 ` Dan Williams
  0 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-04-15 22:03 UTC (permalink / raw)
  To: Kuppuswamy Sathyanarayanan, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra, Joel Becker, Christoph Hellwig

On 4/15/24 16:50, Kuppuswamy Sathyanarayanan wrote:
> 
> On 4/15/24 1:13 PM, Tom Lendacky wrote:
>> On 4/15/24 14:48, Kuppuswamy Sathyanarayanan wrote:
>>> Hi,
>>>
>>> On 4/15/24 12:16 PM, Tom Lendacky wrote:
>>>> On 4/12/24 10:52, Tom Lendacky wrote:
>>>>> On 4/9/24 13:12, Kuppuswamy Sathyanarayanan wrote:
>>>>>> On 3/25/24 3:26 PM, Tom Lendacky wrote:
>>>>>>> Config-fs provides support to hide individual attribute entries. Using
>>>>>>> this support, base the display of the SVSM related entries on the presence
>>>>>>> of an SVSM.
>>>>>>>
>>>>>>> Cc: Joel Becker <jlbec@evilplan.org>
>>>>>>> Cc: Christoph Hellwig <hch@lst.de>
>>>>>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>>>>>>> ---
>>>>>>>     arch/x86/coco/core.c        |  4 ++++
>>>>>>>     drivers/virt/coco/tsm.c     | 14 ++++++++++----
>>>>>>>     include/linux/cc_platform.h |  8 ++++++++
>>>>>>>     3 files changed, 22 insertions(+), 4 deletions(-)
>>>>>>>
>>>>
>>>>>>
>>>>>> Any comment about the following query? I think introducing a CC flag for this use
>>>>>> case is over kill.
>>>>>>
>>>>>> https://lore.kernel.org/lkml/6b90b223-46e0-4e6d-a17c-5caf72e3c949@linux.intel.com/
>>>>>
>>>>> If you don't think TDX will be able to make use of the SVSM attribute I can look at adding a callback. But I was waiting to see if anyone else had comments, for or against, before re-doing it all.
>>>>>
>>>>
>>>> What about something like this (applied on top of patch 13):
>>>>
>>
>>>> diff --git a/include/linux/tsm.h b/include/linux/tsm.h
>>>> index 27cc97fe8dcd..5aaf626d178d 100644
>>>> --- a/include/linux/tsm.h
>>>> +++ b/include/linux/tsm.h
>>>> @@ -74,7 +74,20 @@ extern const struct config_item_type tsm_report_default_type;
>>>>    /* publish @privlevel, @privlevel_floor, and @auxblob attributes */
>>>>    extern const struct config_item_type tsm_report_extra_type;
>>>>    +/*
>>>> + * Used to indicate the attribute group type to the visibility callback to
>>>> + * avoid the callback having to examine the attribute name.
>>>
>>> Checking the attribute name will give more flexibility, right? Since it is one time
>>> check, it should not be costly, right?
>>
>> I thought about checking the name(s), but what if in the future another attribute is added, then you have to remember to update multiple places. This way you have an enum that represents the related attributes. Is there a
> 
> I think it depends on how you implement the visibility function. If the vendor driver allows all attributes by default and denies few selected ones, you don't have to update the vendor driver for all new attributes. Letting the vendor driver decide whether to support any new attributes makes sense to me.
> 
>> scenario where you would want to not hide all attributes that are related? String comparisons just seem awkward to me.
>>
>> I suppose the config_item and configfs_attr could also be supplied on the callback if that's a requirement.
> 
> 
> I am ok with enum based checks. But lets see what others think. Personally I think checking config attr name is more flexible.

I think we can do both. Supply the enum, config_item and configfs_attr 
and then the callback can decide using the enum and/or the attribute name.

It could be extended to the current extra attributes, too. The enum 
could have a TSM_TYPE_EXTRA (for the privlevel, privlevel_floor and 
auxblob) and allow those to be hidden as appropriate, too.

Thanks,
Tom

> 
> 
>>
>>>
>>>> +enum tsm_type {
>>>> +    TSM_TYPE_SERVICE_PROVIDER,
>>>> +
>>>> +    TSM_TYPE_MAX
>>>> +};
>>>> +
>>>> +typedef bool (*tsm_visibility_t)(enum tsm_type type);
>>>> +
>>>>    int tsm_register(const struct tsm_ops *ops, void *priv,
>>>> -         const struct config_item_type *type);
>>>> +         const struct config_item_type *type,
>>>> +         tsm_visibility_t visibility);
>>>>    int tsm_unregister(const struct tsm_ops *ops);
>>>>    #endif /* __TSM_H */
>>>>
>>>
>>> Why not add a callback in tsm_ops?
>>
>> That's an option, too. Either way works for me.
>>
>> Thanks,
>> Tom
>>
>>>
>>>>> Thanks,
>>>>> Tom
>>>>>
>>

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

* Re: [PATCH v3 09/14] virt: sev-guest: Choose the VMPCK key based on executing VMPL
  2024-03-25 22:26 ` [PATCH v3 09/14] virt: sev-guest: Choose the VMPCK key based on executing VMPL Tom Lendacky
@ 2024-04-16  4:54   ` Dan Williams
  2024-04-16 15:17     ` Tom Lendacky
  0 siblings, 1 reply; 61+ messages in thread
From: Dan Williams @ 2024-04-16  4:54 UTC (permalink / raw)
  To: Tom Lendacky, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

Hey, Tom, came looking to review the tsm_report changes and noticed
this...

Tom Lendacky wrote:
> Currently, the sev-guest driver uses the vmpck-0 key by default. When an
> SVSM is present the kernel is running at a VMPL other than 0 and the
> vmpck-0 key is no longer available. So choose the vmpck key based on the
> active VMPL level.

The module parameter is not mentioned in the changelog. Is it not
sufficient to always use snp_get_vmpl(), and if not should there be some
documentation about when to specify vmpck_id?

Do users know that "vmpl" and "vmpck_id" are interchangeable?

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

* Re: [PATCH v3 10/14] configfs-tsm: Allow the privlevel_floor attribute to be updated
  2024-03-25 22:26 ` [PATCH v3 10/14] configfs-tsm: Allow the privlevel_floor attribute to be updated Tom Lendacky
@ 2024-04-16  4:55   ` Dan Williams
  2024-04-16 15:23     ` Tom Lendacky
  0 siblings, 1 reply; 61+ messages in thread
From: Dan Williams @ 2024-04-16  4:55 UTC (permalink / raw)
  To: Tom Lendacky, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

Tom Lendacky wrote:
> With the introduction of an SVSM, Linux will be running at a non-zero
> VMPL. Any request for an attestation report at a higher priviledge VMPL
> than what Linux is currently running will result in an error. Allow for
> the privlevel_floor attribute to be updated dynamically so that the
> attribute may be set dynamically.
> 
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
>  drivers/virt/coco/sev-guest/sev-guest.c | 5 ++++-
>  include/linux/tsm.h                     | 2 +-
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
> index 1ff897913bf4..bba6531cb606 100644
> --- a/drivers/virt/coco/sev-guest/sev-guest.c
> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
> @@ -885,7 +885,7 @@ static int sev_report_new(struct tsm_report *report, void *data)
>  	return 0;
>  }
>  
> -static const struct tsm_ops sev_tsm_ops = {
> +static struct tsm_ops sev_tsm_ops = {
>  	.name = KBUILD_MODNAME,
>  	.report_new = sev_report_new,
>  };
> @@ -972,6 +972,9 @@ static int __init sev_guest_probe(struct platform_device *pdev)
>  	snp_dev->input.resp_gpa = __pa(snp_dev->response);
>  	snp_dev->input.data_gpa = __pa(snp_dev->certs_data);
>  
> +	/* Set the privlevel_floor attribute based on the current VMPL */
> +	sev_tsm_ops.privlevel_floor = snp_get_vmpl();

Why is this not vmpck_id?

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

* Re: [PATCH v3 11/14] x86/sev: Extend the config-fs attestation support for an SVSM
  2024-03-25 22:26 ` [PATCH v3 11/14] x86/sev: Extend the config-fs attestation support for an SVSM Tom Lendacky
@ 2024-04-16  5:37   ` Dan Williams
  2024-04-16 15:53     ` Tom Lendacky
  0 siblings, 1 reply; 61+ messages in thread
From: Dan Williams @ 2024-04-16  5:37 UTC (permalink / raw)
  To: Tom Lendacky, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra

Tom Lendacky wrote:
> When an SVSM is present, the guest can also request attestation reports
> from the SVSM. These SVSM attestation reports can be used to attest the
> SVSM and any services running within the SVSM.
> 
> Extend the config-fs attestation support to allow for an SVSM attestation
> report. This involves creating four (4) new config-fs attributes:
> 
>   - 'service-provider' (input)
>     This attribute is used to determine whether the attestation request
>     should be sent to the specified service provider or to the SEV
>     firmware. The SVSM service provider is represented by the value
>     'svsm'.
> 
>   - 'service_guid' (input)
>     Used for requesting the attestation of a single service within the
>     service provider. A null GUID implies that the SVSM_ATTEST_SERVICES
>     call should be used to request the attestation report. A non-null
>     GUID implies that the SVSM_ATTEST_SINGLE_SERVICE call should be used.
> 
>   - 'service_manifest_version' (input)
>     Used with the SVSM_ATTEST_SINGLE_SERVICE call, the service version
>     represents a specific service manifest version be used for the
>     attestation report.
> 
>   - 'manifestblob' (output)
>     Used to return the service manifest associated with the attestation
>     report.
> 
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
>  Documentation/ABI/testing/configfs-tsm  |  69 +++++++++++
>  arch/x86/include/asm/sev.h              |  31 ++++-
>  arch/x86/kernel/sev.c                   |  50 ++++++++
>  drivers/virt/coco/sev-guest/sev-guest.c | 151 ++++++++++++++++++++++++
>  drivers/virt/coco/tsm.c                 |  93 ++++++++++++++-
>  include/linux/tsm.h                     |  11 ++
>  6 files changed, 402 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
> index dd24202b5ba5..72a7acdb5258 100644
> --- a/Documentation/ABI/testing/configfs-tsm
> +++ b/Documentation/ABI/testing/configfs-tsm
> @@ -31,6 +31,21 @@ Description:
>  		Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ.
>  		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
>  
> +What:		/sys/kernel/config/tsm/report/$name/manifestblob
> +Date:		January, 2024
> +KernelVersion:	v6.10
> +Contact:	linux-coco@lists.linux.dev
> +Description:
> +		(RO) Optional supplemental data that a TSM may emit, visibility
> +		of this attribute depends on TSM, and may be empty if no
> +		manifest data is available.
> +
> +		When @provider is "sev_guest" and the @service_provider is
> +		"svsm" this file contains the service manifest used for the SVSM
> +		attestation report from the Secure VM Service Module for SEV-SNP
> +		Guests v1.00 Section 7.
> +		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf

Should this be "See 'service_provider' for the format of this blob"? To
date external "format specification" links are only referenced once in
this file, and this one is now duplicated.


> +
>  What:		/sys/kernel/config/tsm/report/$name/provider
>  Date:		September, 2023
>  KernelVersion:	v6.7
> @@ -80,3 +95,57 @@ Contact:	linux-coco@lists.linux.dev
>  Description:
>  		(RO) Indicates the minimum permissible value that can be written
>  		to @privlevel.
> +
> +What:		/sys/kernel/config/tsm/report/$name/service_provider
> +Date:		January, 2024
> +KernelVersion:	v6.10
> +Contact:	linux-coco@lists.linux.dev
> +Description:
> +		(WO) Attribute is visible if a TSM implementation provider
> +		supports the concept of attestation reports from a service
> +		provider for TVMs, like SEV-SNP running under an SVSM.
> +		Specifying the service provider via this attribute will create
> +		an attestation report as specified by the service provider.
> +		Currently supported service-providers are:
> +			svsm
> +
> +		For the SVSM service provider, see the Secure VM Service Module
> +		for SEV-SNP Guests v1.00 Section 7.
> +		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf

Given "SVSM" is a cross vendor concept should this explicitly
callout: "For provider.service_provider == sev_guest.svsm" as
preparation for other implementations defining their "svsm" manifest
format? 

> +
> +What:		/sys/kernel/config/tsm/report/$name/service_guid
> +Date:		January, 2024
> +KernelVersion:	v6.10
> +Contact:	linux-coco@lists.linux.dev
> +Description:
> +		(WO) Attribute is visible if a TSM implementation provider
> +		supports the concept of attestation reports from a service
> +		provider for TVMs, like SEV-SNP running under an SVSM.
> +		Specifying an empty/null GUID (00000000-0000-0000-0000-000000)
> +		requests all active services within the service provider be
> +		part of the attestation report. Specifying a GUID request
> +		an attestation report of just the specified service using the
> +		manifest form specified by the service_manifest_version
> +		attribute.
> +
> +		For the SVSM service provider, see the Secure VM Service Module
> +		for SEV-SNP Guests v1.00 Section 7.
> +		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf

...another "See..." instead of duplicate.

> +
> +What:		/sys/kernel/config/tsm/report/$name/service_manifest_version
> +Date:		January, 2024
> +KernelVersion:	v6.10
> +Contact:	linux-coco@lists.linux.dev
> +Description:
> +		(WO) Attribute is visible if a TSM implementation provider
> +		supports the concept of attestation reports from a service
> +		provider for TVMs, like SEV-SNP running under an SVSM.
> +		Indicates the service manifest version requested for the
> +		attestation report. If this field is not set by the user,
> +		the default manifest version of the service (the service's
> +		initial/first manifest version) is returned. The initial
> +		manifest version is always available.

...and that number is zero? Is there any expectation that the kernel
sanity checks this version, or how does the user figure out they need to
roll this request back?

> +
> +		For the SVSM service provider, see the Secure VM Service Module
> +		for SEV-SNP Guests v1.00 Section 7.
> +		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf

Ditto on replacing this with a "See.." reference.


> diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
> index 066eb0ba3d63..94af7fb7a8e1 100644
> --- a/arch/x86/include/asm/sev.h
> +++ b/arch/x86/include/asm/sev.h
> @@ -209,6 +209,27 @@ struct svsm_pvalidate_call {
>  	struct svsm_pvalidate_entry entry[];
>  };
>  
> +/*
> + * The SVSM Attestation related structures
> + */
> +struct svsm_location_entry {
> +	u64 pa;
> +	u32 len;
> +	u8 rsvd[4];
> +};
> +
> +struct svsm_attestation_call {
> +	struct svsm_location_entry report_buffer;
> +	struct svsm_location_entry nonce;
> +	struct svsm_location_entry manifest_buffer;
> +	struct svsm_location_entry certificates_buffer;
> +
> +	/* For attesting a single service */
> +	u8 service_guid[16];
> +	u32 service_manifest_version;
> +	u8 rsvd[4];
> +};
> +
>  /*
>   * SVSM protocol structure
>   */
> @@ -232,6 +253,10 @@ struct svsm_call {
>  #define SVSM_CORE_CREATE_VCPU		2
>  #define SVSM_CORE_DELETE_VCPU		3
>  
> +#define SVSM_ATTEST_CALL(x)		((1ULL << 32) | (x))
> +#define SVSM_ATTEST_SERVICES		0
> +#define SVSM_ATTEST_SINGLE_SERVICE	1
> +
>  #ifdef CONFIG_AMD_MEM_ENCRYPT
>  extern void __sev_es_ist_enter(struct pt_regs *regs);
>  extern void __sev_es_ist_exit(void);
> @@ -302,6 +327,7 @@ void snp_set_wakeup_secondary_cpu(void);
>  bool snp_init(struct boot_params *bp);
>  void __noreturn snp_abort(void);
>  int snp_issue_guest_request(u64 exit_code, struct snp_req_data *input, struct snp_guest_request_ioctl *rio);
> +int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input);
>  void snp_accept_memory(phys_addr_t start, phys_addr_t end);
>  u64 snp_get_unsupported_features(u64 status);
>  u64 sev_get_status(void);
> @@ -333,7 +359,10 @@ static inline int snp_issue_guest_request(u64 exit_code, struct snp_req_data *in
>  {
>  	return -ENOTTY;
>  }
> -
> +static inline int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input)
> +{
> +	return -ENOTTY;
> +}
>  static inline void snp_accept_memory(phys_addr_t start, phys_addr_t end) { }
>  static inline u64 snp_get_unsupported_features(u64 status) { return 0; }
>  static inline u64 sev_get_status(void) { return 0; }
> diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
> index 7e2b9934a95d..0a06632898c6 100644
> --- a/arch/x86/kernel/sev.c
> +++ b/arch/x86/kernel/sev.c
> @@ -2400,6 +2400,56 @@ static int __init init_sev_config(char *str)
>  }
>  __setup("sev=", init_sev_config);
>  
> +static void update_attestation_input(struct svsm_call *call, struct svsm_attestation_call *input)
> +{
> +	/* If (new) lengths have been returned, propograte them up */
> +	if (call->rcx_out != call->rcx)
> +		input->manifest_buffer.len = call->rcx_out;
> +
> +	if (call->rdx_out != call->rdx)
> +		input->certificates_buffer.len = call->rdx_out;
> +
> +	if (call->r8_out != call->r8)
> +		input->report_buffer.len = call->r8_out;
> +}
> +
> +int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input)
> +{
> +	struct svsm_attestation_call *attest_call;
> +	struct svsm_call call = {};
> +	unsigned long flags;
> +	u64 attest_call_pa;
> +	int ret;
> +
> +	if (!vmpl)
> +		return -EINVAL;
> +
> +	local_irq_save(flags);
> +
> +	call.caa = __svsm_get_caa();
> +
> +	attest_call = (struct svsm_attestation_call *)call.caa->svsm_buffer;
> +	attest_call_pa = __svsm_get_caa_pa() + offsetof(struct svsm_ca, svsm_buffer);
> +
> +	*attest_call = *input;
> +
> +	/*
> +	 * Set input registers for the request and set RDX and R8 to known
> +	 * values in order to detect length values being returned in them.
> +	 */
> +	call.rax = call_id;
> +	call.rcx = attest_call_pa;
> +	call.rdx = -1;
> +	call.r8 = -1;
> +	ret = svsm_protocol(&call);
> +	update_attestation_input(&call, input);
> +
> +	local_irq_restore(flags);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(snp_issue_svsm_attestation_request);
> +
>  int snp_issue_guest_request(u64 exit_code, struct snp_req_data *input, struct snp_guest_request_ioctl *rio)
>  {
>  	struct ghcb_state state;
> diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
> index bba6531cb606..0d2c9926a97c 100644
> --- a/drivers/virt/coco/sev-guest/sev-guest.c
> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
> @@ -38,6 +38,8 @@
>  #define SNP_REQ_MAX_RETRY_DURATION	(60*HZ)
>  #define SNP_REQ_RETRY_DELAY		(2*HZ)
>  
> +#define SVSM_MAX_RETRIES		3
> +
>  struct snp_guest_crypto {
>  	struct crypto_aead *tfm;
>  	u8 *iv, *authtag;
> @@ -783,6 +785,148 @@ struct snp_msg_cert_entry {
>  	u32 length;
>  };
>  
> +static int sev_svsm_report_new(struct tsm_report *report, void *data)
> +{
> +	unsigned int report_len, manifest_len, certificates_len;
> +	void *report_blob, *manifest_blob, *certificates_blob;
> +	struct svsm_attestation_call attest_call = {};
> +	struct tsm_desc *desc = &report->desc;
> +	unsigned int retry_count;
> +	unsigned int size;
> +	bool try_again;
> +	void *buffer;
> +	u64 call_id;
> +	int ret;
> +
> +	/*
> +	 * Allocate pages for the request:
> +	 * - Report blob (4K)
> +	 * - Manifest blob (4K)
> +	 * - Certificate blob (16K)
> +	 *
> +	 * Above addresses must be 4K aligned
> +	 */
> +	report_len = SZ_4K;
> +	manifest_len = SZ_4K;
> +	certificates_len = SEV_FW_BLOB_MAX_SIZE;
> +
> +	if (guid_is_null(&desc->service_guid)) {
> +		call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SERVICES);
> +	} else {
> +		export_guid(attest_call.service_guid, &desc->service_guid);
> +		attest_call.service_manifest_version = desc->service_manifest_version;
> +
> +		call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SINGLE_SERVICE);
> +	}
> +
> +	retry_count = 0;
> +
> +retry:
> +	size = report_len + manifest_len + certificates_len;
> +	buffer = alloc_pages_exact(size, __GFP_ZERO);
> +	if (!buffer)
> +		return -ENOMEM;
> +
> +	report_blob = buffer;
> +	attest_call.report_buffer.pa = __pa(report_blob);
> +	attest_call.report_buffer.len = report_len;
> +
> +	manifest_blob = report_blob + report_len;
> +	attest_call.manifest_buffer.pa = __pa(manifest_blob);
> +	attest_call.manifest_buffer.len = manifest_len;
> +
> +	certificates_blob = manifest_blob + manifest_len;
> +	attest_call.certificates_buffer.pa = __pa(certificates_blob);
> +	attest_call.certificates_buffer.len = certificates_len;
> +
> +	attest_call.nonce.pa = __pa(desc->inblob);
> +	attest_call.nonce.len = desc->inblob_len;
> +
> +	ret = snp_issue_svsm_attestation_request(call_id, &attest_call);
> +	switch (ret) {
> +	case SVSM_SUCCESS:
> +		break;
> +	case SVSM_ERR_INVALID_PARAMETER:
> +		ret = -EINVAL;
> +
> +		if (retry_count >= SVSM_MAX_RETRIES)
> +			goto error;
> +
> +		try_again = false;
> +
> +		if (attest_call.report_buffer.len > report_len) {
> +			report_len = PAGE_ALIGN(attest_call.report_buffer.len);
> +			try_again = true;
> +		}
> +
> +		if (attest_call.manifest_buffer.len > manifest_len) {
> +			manifest_len = PAGE_ALIGN(attest_call.manifest_buffer.len);
> +			try_again = true;
> +		}
> +
> +		if (attest_call.certificates_buffer.len > certificates_len) {
> +			certificates_len = PAGE_ALIGN(attest_call.certificates_buffer.len);
> +			try_again = true;
> +		}
> +
> +		/* If one of the buffers wasn't large enough, retry the request */
> +		if (try_again) {
> +			free_pages_exact(buffer, size);
> +			retry_count++;
> +			goto retry;
> +		}
> +
> +		goto error;
> +	case SVSM_ERR_BUSY:
> +		ret = -EAGAIN;
> +		goto error;
> +	default:
> +		pr_err_ratelimited("SVSM attestation request failed (%#x)\n", ret);
> +		ret = -EINVAL;
> +		goto error;
> +	}
> +
> +	ret = -ENOMEM;
> +
> +	report_len = attest_call.report_buffer.len;
> +	void *rbuf __free(kvfree) = kvzalloc(report_len, GFP_KERNEL);
> +	if (!rbuf)
> +		goto error;
> +
> +	memcpy(rbuf, report_blob, report_len);
> +	report->outblob = no_free_ptr(rbuf);
> +	report->outblob_len = report_len;
> +
> +	manifest_len = attest_call.manifest_buffer.len;
> +	void *mbuf __free(kvfree) = kvzalloc(manifest_len, GFP_KERNEL);
> +	if (!mbuf)
> +		goto error;
> +
> +	memcpy(mbuf, manifest_blob, manifest_len);
> +	report->manifestblob = no_free_ptr(mbuf);
> +	report->manifestblob_len = manifest_len;
> +
> +	certificates_len = attest_call.certificates_buffer.len;
> +	if (!certificates_len)
> +		goto success;
> +
> +	void *cbuf __free(kvfree) = kvzalloc(certificates_len, GFP_KERNEL);
> +	if (!cbuf)
> +		goto error;
> +
> +	memcpy(cbuf, certificates_blob, certificates_len);
> +	report->auxblob = no_free_ptr(cbuf);
> +	report->auxblob_len = certificates_len;
> +
> +success:
> +	ret = 0;
> +
> +error:
> +	free_pages_exact(buffer, size);
> +
> +	return ret;
> +}
> +
>  static int sev_report_new(struct tsm_report *report, void *data)
>  {
>  	struct snp_msg_cert_entry *cert_table;
> @@ -797,6 +941,13 @@ static int sev_report_new(struct tsm_report *report, void *data)
>  	if (desc->inblob_len != SNP_REPORT_USER_DATA_SIZE)
>  		return -EINVAL;
>  
> +	if (desc->service_provider) {
> +		if (strcmp(desc->service_provider, "svsm"))
> +			return -EINVAL;
> +
> +		return sev_svsm_report_new(report, data);
> +	}
> +
>  	void *buf __free(kvfree) = kvzalloc(size, GFP_KERNEL);
>  	if (!buf)
>  		return -ENOMEM;
> diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
> index d1c2db83a8ca..46f230bf13ac 100644
> --- a/drivers/virt/coco/tsm.c
> +++ b/drivers/virt/coco/tsm.c
> @@ -35,7 +35,7 @@ static DECLARE_RWSEM(tsm_rwsem);
>   * The attestation report format is TSM provider specific, when / if a standard
>   * materializes that can be published instead of the vendor layout. Until then
>   * the 'provider' attribute indicates the format of 'outblob', and optionally
> - * 'auxblob'.
> + * 'auxblob' and 'manifestblob'.
>   */
>  
>  struct tsm_report_state {
> @@ -48,6 +48,7 @@ struct tsm_report_state {
>  enum tsm_data_select {
>  	TSM_REPORT,
>  	TSM_CERTS,
> +	TSM_MANIFEST,
>  };
>  
>  static struct tsm_report *to_tsm_report(struct config_item *cfg)
> @@ -119,6 +120,74 @@ static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
>  }
>  CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
>  
> +static ssize_t tsm_report_service_provider_store(struct config_item *cfg,
> +						 const char *buf, size_t len)
> +{
> +	struct tsm_report *report = to_tsm_report(cfg);
> +	size_t sp_len;
> +	char *sp;
> +	int rc;
> +
> +	guard(rwsem_write)(&tsm_rwsem);
> +	rc = try_advance_write_generation(report);
> +	if (rc)
> +		return rc;
> +
> +	sp_len = (buf[len - 1] != '\n') ? len : len - 1;

This feels like it wants a sysfs_strdup().

> +
> +	sp = kstrndup(buf, sp_len, GFP_KERNEL);
> +	if (!sp)
> +		return -ENOMEM;
> +	kfree(report->desc.service_provider);
> +
> +	report->desc.service_provider = sp;
> +
> +	return len;
> +}
> +CONFIGFS_ATTR_WO(tsm_report_, service_provider);
> +
> +static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
> +					     const char *buf, size_t len)
> +{
> +	struct tsm_report *report = to_tsm_report(cfg);
> +	int rc;
> +
> +	guard(rwsem_write)(&tsm_rwsem);
> +	rc = try_advance_write_generation(report);
> +	if (rc)
> +		return rc;
> +
> +	report->desc.service_guid = guid_null;
> +
> +	rc = guid_parse(buf, &report->desc.service_guid);
> +	if (rc)
> +		return rc;
> +
> +	return len;
> +}
> +CONFIGFS_ATTR_WO(tsm_report_, service_guid);
> +
> +static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg,
> +							 const char *buf, size_t len)
> +{
> +	struct tsm_report *report = to_tsm_report(cfg);
> +	unsigned int val;
> +	int rc;
> +
> +	rc = kstrtouint(buf, 0, &val);
> +	if (rc)
> +		return rc;
> +
> +	guard(rwsem_write)(&tsm_rwsem);
> +	rc = try_advance_write_generation(report);
> +	if (rc)
> +		return rc;
> +	report->desc.service_manifest_version = val;
> +
> +	return len;
> +}
> +CONFIGFS_ATTR_WO(tsm_report_, service_manifest_version);
> +
>  static ssize_t tsm_report_inblob_write(struct config_item *cfg,
>  				       const void *buf, size_t count)
>  {
> @@ -163,6 +232,9 @@ static ssize_t __read_report(struct tsm_report *report, void *buf, size_t count,
>  	if (select == TSM_REPORT) {
>  		out = report->outblob;
>  		len = report->outblob_len;
> +	} else if (select == TSM_MANIFEST) {
> +		out = report->manifestblob;
> +		len = report->manifestblob_len;
>  	} else {
>  		out = report->auxblob;
>  		len = report->auxblob_len;
> @@ -188,7 +260,7 @@ static ssize_t read_cached_report(struct tsm_report *report, void *buf,
>  
>  	/*
>  	 * A given TSM backend always fills in ->outblob regardless of
> -	 * whether the report includes an auxblob or not.
> +	 * whether the report includes an auxblob/manifestblob or not.
>  	 */
>  	if (!report->outblob ||
>  	    state->read_generation != state->write_generation)
> @@ -224,8 +296,10 @@ static ssize_t tsm_report_read(struct tsm_report *report, void *buf,
>  
>  	kvfree(report->outblob);
>  	kvfree(report->auxblob);
> +	kvfree(report->manifestblob);
>  	report->outblob = NULL;
>  	report->auxblob = NULL;
> +	report->manifestblob = NULL;
>  	rc = ops->report_new(report, provider.data);
>  	if (rc < 0)
>  		return rc;
> @@ -252,6 +326,15 @@ static ssize_t tsm_report_auxblob_read(struct config_item *cfg, void *buf,
>  }
>  CONFIGFS_BIN_ATTR_RO(tsm_report_, auxblob, NULL, TSM_OUTBLOB_MAX);
>  
> +static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,
> +					    size_t count)
> +{
> +	struct tsm_report *report = to_tsm_report(cfg);
> +
> +	return tsm_report_read(report, buf, count, TSM_MANIFEST);
> +}
> +CONFIGFS_BIN_ATTR_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX);
> +
>  #define TSM_DEFAULT_ATTRS() \
>  	&tsm_report_attr_generation, \
>  	&tsm_report_attr_provider
> @@ -265,6 +348,9 @@ static struct configfs_attribute *tsm_report_extra_attrs[] = {
>  	TSM_DEFAULT_ATTRS(),
>  	&tsm_report_attr_privlevel,
>  	&tsm_report_attr_privlevel_floor,
> +	&tsm_report_attr_service_provider,
> +	&tsm_report_attr_service_guid,
> +	&tsm_report_attr_service_manifest_version,

Shouldn't this patch come after the configfs dynamic visibility so there
is no point in the history where vestigial attributes show up?

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

* Re: [PATCH v3 12/14] fs/configfs: Add a callback to determine attribute visibility
  2024-03-25 22:26 ` [PATCH v3 12/14] fs/configfs: Add a callback to determine attribute visibility Tom Lendacky
@ 2024-04-16  5:46   ` Dan Williams
  2024-04-16 16:01     ` Tom Lendacky
  0 siblings, 1 reply; 61+ messages in thread
From: Dan Williams @ 2024-04-16  5:46 UTC (permalink / raw)
  To: Tom Lendacky, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra, Joel Becker, Christoph Hellwig

Tom Lendacky wrote:
> In order to support dynamic decisions as to whether an attribute should be
> created, add a callback that returns a bool to indicate whether the
> attribute should be display. If no callback is registered, the attribute

s/display/displayed/

> is displayed by default.
> 
> Cc: Joel Becker <jlbec@evilplan.org>
> Cc: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
>  fs/configfs/file.c       |   7 +++
>  include/linux/configfs.h | 111 +++++++++++++++++++++++++++------------
>  2 files changed, 84 insertions(+), 34 deletions(-)
> 
> diff --git a/fs/configfs/file.c b/fs/configfs/file.c
> index 0ad32150611e..a976c183756c 100644
> --- a/fs/configfs/file.c
> +++ b/fs/configfs/file.c
> @@ -451,6 +451,9 @@ int configfs_create_file(struct config_item * item, const struct configfs_attrib
>  	umode_t mode = (attr->ca_mode & S_IALLUGO) | S_IFREG;
>  	int error = 0;
>  
> +	if (attr->is_visible && !attr->is_visible(item, attr))
> +		return 0;
> +
>  	inode_lock_nested(d_inode(dir), I_MUTEX_NORMAL);
>  	error = configfs_make_dirent(parent_sd, NULL, (void *) attr, mode,
>  				     CONFIGFS_ITEM_ATTR, parent_sd->s_frag);
> @@ -470,9 +473,13 @@ int configfs_create_bin_file(struct config_item *item,
>  {
>  	struct dentry *dir = item->ci_dentry;
>  	struct configfs_dirent *parent_sd = dir->d_fsdata;
> +	const struct configfs_attribute *attr = &bin_attr->cb_attr;
>  	umode_t mode = (bin_attr->cb_attr.ca_mode & S_IALLUGO) | S_IFREG;
>  	int error = 0;
>  
> +	if (attr->is_visible && !attr->is_visible(item, attr))
> +		return 0;
> +
>  	inode_lock_nested(dir->d_inode, I_MUTEX_NORMAL);
>  	error = configfs_make_dirent(parent_sd, NULL, (void *) bin_attr, mode,
>  				     CONFIGFS_ITEM_BIN_ATTR, parent_sd->s_frag);
> diff --git a/include/linux/configfs.h b/include/linux/configfs.h
> index 2606711adb18..c836d7bc7c9e 100644
> --- a/include/linux/configfs.h
> +++ b/include/linux/configfs.h
> @@ -116,35 +116,57 @@ struct configfs_attribute {
>  	const char		*ca_name;
>  	struct module 		*ca_owner;
>  	umode_t			ca_mode;
> +	bool (*is_visible)(const struct config_item *, const struct configfs_attribute *);
>  	ssize_t (*show)(struct config_item *, char *);
>  	ssize_t (*store)(struct config_item *, const char *, size_t);
>  };
>  
> -#define CONFIGFS_ATTR(_pfx, _name)			\
> +#define __CONFIGFS_ATTR(_pfx, _name, _vis)		\
>  static struct configfs_attribute _pfx##attr_##_name = {	\
>  	.ca_name	= __stringify(_name),		\
>  	.ca_mode	= S_IRUGO | S_IWUSR,		\
>  	.ca_owner	= THIS_MODULE,			\
> +	.is_visible	= _vis,				\
>  	.show		= _pfx##_name##_show,		\
>  	.store		= _pfx##_name##_store,		\

Shouldn't this operation live in configfs_group_operations? That would
mirror the sysfs organization, and likely saves some memory.

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

* Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
  2024-03-25 22:26 ` [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM Tom Lendacky
  2024-04-09 18:12   ` Kuppuswamy Sathyanarayanan
@ 2024-04-16  5:47   ` Dan Williams
  2024-04-16 16:07     ` Tom Lendacky
  2024-04-16  6:03   ` Dan Williams
  2 siblings, 1 reply; 61+ messages in thread
From: Dan Williams @ 2024-04-16  5:47 UTC (permalink / raw)
  To: Tom Lendacky, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra, Joel Becker, Christoph Hellwig

Tom Lendacky wrote:
> Config-fs provides support to hide individual attribute entries. Using
> this support, base the display of the SVSM related entries on the presence
> of an SVSM.
> 
> Cc: Joel Becker <jlbec@evilplan.org>
> Cc: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
>  arch/x86/coco/core.c        |  4 ++++
>  drivers/virt/coco/tsm.c     | 14 ++++++++++----
>  include/linux/cc_platform.h |  8 ++++++++
>  3 files changed, 22 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/coco/core.c b/arch/x86/coco/core.c
> index d07be9d05cd0..efa0f648f754 100644
> --- a/arch/x86/coco/core.c
> +++ b/arch/x86/coco/core.c
> @@ -12,6 +12,7 @@
>  
>  #include <asm/coco.h>
>  #include <asm/processor.h>
> +#include <asm/sev.h>
>  
>  enum cc_vendor cc_vendor __ro_after_init = CC_VENDOR_NONE;
>  u64 cc_mask __ro_after_init;
> @@ -78,6 +79,9 @@ static bool noinstr amd_cc_platform_has(enum cc_attr attr)
>  	case CC_ATTR_GUEST_STATE_ENCRYPT:
>  		return sev_status & MSR_AMD64_SEV_ES_ENABLED;
>  
> +	case CC_ATTR_GUEST_SVSM_PRESENT:
> +		return snp_get_vmpl();
> +
>  	/*
>  	 * With SEV, the rep string I/O instructions need to be unrolled
>  	 * but SEV-ES supports them through the #VC handler.
> diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
> index 46f230bf13ac..d30471874e87 100644
> --- a/drivers/virt/coco/tsm.c
> +++ b/drivers/virt/coco/tsm.c
> @@ -64,6 +64,12 @@ static struct tsm_report_state *to_state(struct tsm_report *report)
>  	return container_of(report, struct tsm_report_state, report);
>  }
>  
> +static bool provider_visibility(const struct config_item *item,
> +				const struct configfs_attribute *attr)
> +{
> +	return cc_platform_has(CC_ATTR_GUEST_SVSM_PRESENT);
> +}
> +
>  static int try_advance_write_generation(struct tsm_report *report)
>  {
>  	struct tsm_report_state *state = to_state(report);
> @@ -144,7 +150,7 @@ static ssize_t tsm_report_service_provider_store(struct config_item *cfg,
>  
>  	return len;
>  }
> -CONFIGFS_ATTR_WO(tsm_report_, service_provider);
> +CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_provider, provider_visibility);
>  
>  static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
>  					     const char *buf, size_t len)
> @@ -165,7 +171,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
>  
>  	return len;
>  }
> -CONFIGFS_ATTR_WO(tsm_report_, service_guid);
> +CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_guid, provider_visibility);
>  
>  static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg,
>  							 const char *buf, size_t len)
> @@ -186,7 +192,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg
>  
>  	return len;
>  }
> -CONFIGFS_ATTR_WO(tsm_report_, service_manifest_version);
> +CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_manifest_version, provider_visibility);
>  
>  static ssize_t tsm_report_inblob_write(struct config_item *cfg,
>  				       const void *buf, size_t count)
> @@ -333,7 +339,7 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,
>  
>  	return tsm_report_read(report, buf, count, TSM_MANIFEST);
>  }
> -CONFIGFS_BIN_ATTR_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX);
> +CONFIGFS_BIN_ATTR_VISIBLE_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX, provider_visibility);

Yeah the same callback specified multiple times feels like something
that should only happen once at the group level.

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

* Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
  2024-03-25 22:26 ` [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM Tom Lendacky
  2024-04-09 18:12   ` Kuppuswamy Sathyanarayanan
  2024-04-16  5:47   ` Dan Williams
@ 2024-04-16  6:03   ` Dan Williams
  2024-04-16 16:10     ` Tom Lendacky
  2 siblings, 1 reply; 61+ messages in thread
From: Dan Williams @ 2024-04-16  6:03 UTC (permalink / raw)
  To: Tom Lendacky, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra, Joel Becker, Christoph Hellwig

Tom Lendacky wrote:
> Config-fs provides support to hide individual attribute entries. Using
> this support, base the display of the SVSM related entries on the presence
> of an SVSM.
> 
> Cc: Joel Becker <jlbec@evilplan.org>
> Cc: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
>  arch/x86/coco/core.c        |  4 ++++
>  drivers/virt/coco/tsm.c     | 14 ++++++++++----
>  include/linux/cc_platform.h |  8 ++++++++
>  3 files changed, 22 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/coco/core.c b/arch/x86/coco/core.c
> index d07be9d05cd0..efa0f648f754 100644
> --- a/arch/x86/coco/core.c
> +++ b/arch/x86/coco/core.c
> @@ -12,6 +12,7 @@
>  
>  #include <asm/coco.h>
>  #include <asm/processor.h>
> +#include <asm/sev.h>
>  
>  enum cc_vendor cc_vendor __ro_after_init = CC_VENDOR_NONE;
>  u64 cc_mask __ro_after_init;
> @@ -78,6 +79,9 @@ static bool noinstr amd_cc_platform_has(enum cc_attr attr)
>  	case CC_ATTR_GUEST_STATE_ENCRYPT:
>  		return sev_status & MSR_AMD64_SEV_ES_ENABLED;
>  
> +	case CC_ATTR_GUEST_SVSM_PRESENT:
> +		return snp_get_vmpl();
> +
>  	/*
>  	 * With SEV, the rep string I/O instructions need to be unrolled
>  	 * but SEV-ES supports them through the #VC handler.
> diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
> index 46f230bf13ac..d30471874e87 100644
> --- a/drivers/virt/coco/tsm.c
> +++ b/drivers/virt/coco/tsm.c
> @@ -64,6 +64,12 @@ static struct tsm_report_state *to_state(struct tsm_report *report)
>  	return container_of(report, struct tsm_report_state, report);
>  }
>  
> +static bool provider_visibility(const struct config_item *item,
> +				const struct configfs_attribute *attr)
> +{
> +	return cc_platform_has(CC_ATTR_GUEST_SVSM_PRESENT);
> +}

I expect this needs to be a callback into the provider ops because one
of the other use cases for this visibility check is to get rid of the
"extra" attributes and handle that visibility with the same mechanism.

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

* Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
  2024-04-15 19:16       ` Tom Lendacky
  2024-04-15 19:48         ` Kuppuswamy Sathyanarayanan
@ 2024-04-16  6:05         ` Dan Williams
  1 sibling, 0 replies; 61+ messages in thread
From: Dan Williams @ 2024-04-16  6:05 UTC (permalink / raw)
  To: Tom Lendacky, Kuppuswamy Sathyanarayanan, linux-kernel, x86,
	linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra, Joel Becker, Christoph Hellwig

Tom Lendacky wrote:
> On 4/12/24 10:52, Tom Lendacky wrote:
> > On 4/9/24 13:12, Kuppuswamy Sathyanarayanan wrote:
> >> On 3/25/24 3:26 PM, Tom Lendacky wrote:
> >>> Config-fs provides support to hide individual attribute entries. Using
> >>> this support, base the display of the SVSM related entries on the 
> >>> presence
> >>> of an SVSM.
> >>>
> >>> Cc: Joel Becker <jlbec@evilplan.org>
> >>> Cc: Christoph Hellwig <hch@lst.de>
> >>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> >>> ---
> >>>   arch/x86/coco/core.c        |  4 ++++
> >>>   drivers/virt/coco/tsm.c     | 14 ++++++++++----
> >>>   include/linux/cc_platform.h |  8 ++++++++
> >>>   3 files changed, 22 insertions(+), 4 deletions(-)
> >>>
> 
> >>
> >> Any comment about the following query? I think introducing a CC flag 
> >> for this use
> >> case is over kill.
> >>
> >> https://lore.kernel.org/lkml/6b90b223-46e0-4e6d-a17c-5caf72e3c949@linux.intel.com/
> > 
> > If you don't think TDX will be able to make use of the SVSM attribute I 
> > can look at adding a callback. But I was waiting to see if anyone else 
> > had comments, for or against, before re-doing it all.
> > 
> 
> What about something like this (applied on top of patch 13):
> 
> diff --git a/arch/x86/coco/core.c b/arch/x86/coco/core.c
> index efa0f648f754..d07be9d05cd0 100644
> --- a/arch/x86/coco/core.c
> +++ b/arch/x86/coco/core.c
> @@ -12,7 +12,6 @@
>   
>   #include <asm/coco.h>
>   #include <asm/processor.h>
> -#include <asm/sev.h>
>   
>   enum cc_vendor cc_vendor __ro_after_init = CC_VENDOR_NONE;
>   u64 cc_mask __ro_after_init;
> @@ -79,9 +78,6 @@ static bool noinstr amd_cc_platform_has(enum cc_attr attr)
>   	case CC_ATTR_GUEST_STATE_ENCRYPT:
>   		return sev_status & MSR_AMD64_SEV_ES_ENABLED;
>   
> -	case CC_ATTR_GUEST_SVSM_PRESENT:
> -		return snp_get_vmpl();
> -
>   	/*
>   	 * With SEV, the rep string I/O instructions need to be unrolled
>   	 * but SEV-ES supports them through the #VC handler.
> diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
> index 0d2c9926a97c..68c881a50026 100644
> --- a/drivers/virt/coco/sev-guest/sev-guest.c
> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
> @@ -1036,6 +1036,17 @@ static int sev_report_new(struct tsm_report *report, void *data)
>   	return 0;
>   }
>   
> +static bool sev_tsm_visibility(enum tsm_type type)
> +{
> +	/* Check for SVSM-related attributes */
> +	switch (type) {
> +	case TSM_TYPE_SERVICE_PROVIDER:
> +		return snp_get_vmpl();
> +	default:
> +		return false;
> +	}
> +}
> +
>   static struct tsm_ops sev_tsm_ops = {
>   	.name = KBUILD_MODNAME,
>   	.report_new = sev_report_new,
> @@ -1126,7 +1137,8 @@ static int __init sev_guest_probe(struct platform_device *pdev)
>   	/* Set the privlevel_floor attribute based on the current VMPL */
>   	sev_tsm_ops.privlevel_floor = snp_get_vmpl();
>   
> -	ret = tsm_register(&sev_tsm_ops, snp_dev, &tsm_report_extra_type);
> +	ret = tsm_register(&sev_tsm_ops, snp_dev, &tsm_report_extra_type,
> +			   sev_tsm_visibility);

I would have expected this in tsm_ops, but yes I think a callback lets
this fixup the ugly "extra" attributes situation as well.

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

* Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
  2024-04-15 20:13           ` Tom Lendacky
  2024-04-15 21:50             ` Kuppuswamy Sathyanarayanan
@ 2024-04-16  6:08             ` Dan Williams
  1 sibling, 0 replies; 61+ messages in thread
From: Dan Williams @ 2024-04-16  6:08 UTC (permalink / raw)
  To: Tom Lendacky, Kuppuswamy Sathyanarayanan, linux-kernel, x86,
	linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra, Joel Becker, Christoph Hellwig

Tom Lendacky wrote:
> On 4/15/24 14:48, Kuppuswamy Sathyanarayanan wrote:
> > Hi,
> > 
> > On 4/15/24 12:16 PM, Tom Lendacky wrote:
> >> On 4/12/24 10:52, Tom Lendacky wrote:
> >>> On 4/9/24 13:12, Kuppuswamy Sathyanarayanan wrote:
> >>>> On 3/25/24 3:26 PM, Tom Lendacky wrote:
> >>>>> Config-fs provides support to hide individual attribute entries. Using
> >>>>> this support, base the display of the SVSM related entries on the presence
> >>>>> of an SVSM.
> >>>>>
> >>>>> Cc: Joel Becker <jlbec@evilplan.org>
> >>>>> Cc: Christoph Hellwig <hch@lst.de>
> >>>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> >>>>> ---
> >>>>>    arch/x86/coco/core.c        |  4 ++++
> >>>>>    drivers/virt/coco/tsm.c     | 14 ++++++++++----
> >>>>>    include/linux/cc_platform.h |  8 ++++++++
> >>>>>    3 files changed, 22 insertions(+), 4 deletions(-)
> >>>>>
> >>
> >>>>
> >>>> Any comment about the following query? I think introducing a CC flag for this use
> >>>> case is over kill.
> >>>>
> >>>> https://lore.kernel.org/lkml/6b90b223-46e0-4e6d-a17c-5caf72e3c949@linux.intel.com/
> >>>
> >>> If you don't think TDX will be able to make use of the SVSM attribute I can look at adding a callback. But I was waiting to see if anyone else had comments, for or against, before re-doing it all.
> >>>
> >>
> >> What about something like this (applied on top of patch 13):
> >>
> 
> >> diff --git a/include/linux/tsm.h b/include/linux/tsm.h
> >> index 27cc97fe8dcd..5aaf626d178d 100644
> >> --- a/include/linux/tsm.h
> >> +++ b/include/linux/tsm.h
> >> @@ -74,7 +74,20 @@ extern const struct config_item_type tsm_report_default_type;
> >>   /* publish @privlevel, @privlevel_floor, and @auxblob attributes */
> >>   extern const struct config_item_type tsm_report_extra_type;
> >>   
> >> +/*
> >> + * Used to indicate the attribute group type to the visibility callback to
> >> + * avoid the callback having to examine the attribute name.
> > 
> > Checking the attribute name will give more flexibility, right? Since it is one time
> > check, it should not be costly, right?
> 
> I thought about checking the name(s), but what if in the future another 
> attribute is added, then you have to remember to update multiple places. 
> This way you have an enum that represents the related attributes. Is 
> there a scenario where you would want to not hide all attributes that 
> are related? String comparisons just seem awkward to me.

An enum that matches an attribute index matches what sysfs offers. I.e.
sysfs is_visible callbacks either do pointer comparisons, or attribute
index number, but not names. So I agree with you about not using an
attribute name as the key.

Using the index however does mean that providers need to assume that all
attributes are in one array (and one bin_attribute array), but I think
that's ok.

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

* Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
  2024-04-15 22:03               ` Tom Lendacky
@ 2024-04-16  6:09                 ` Dan Williams
  0 siblings, 0 replies; 61+ messages in thread
From: Dan Williams @ 2024-04-16  6:09 UTC (permalink / raw)
  To: Tom Lendacky, Kuppuswamy Sathyanarayanan, linux-kernel, x86,
	linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
	Michael Roth, Ashish Kalra, Joel Becker, Christoph Hellwig

Tom Lendacky wrote:
> On 4/15/24 16:50, Kuppuswamy Sathyanarayanan wrote:
> > 
> > On 4/15/24 1:13 PM, Tom Lendacky wrote:
> >> On 4/15/24 14:48, Kuppuswamy Sathyanarayanan wrote:
> >>> Hi,
> >>>
> >>> On 4/15/24 12:16 PM, Tom Lendacky wrote:
> >>>> On 4/12/24 10:52, Tom Lendacky wrote:
> >>>>> On 4/9/24 13:12, Kuppuswamy Sathyanarayanan wrote:
> >>>>>> On 3/25/24 3:26 PM, Tom Lendacky wrote:
> >>>>>>> Config-fs provides support to hide individual attribute entries. Using
> >>>>>>> this support, base the display of the SVSM related entries on the presence
> >>>>>>> of an SVSM.
> >>>>>>>
> >>>>>>> Cc: Joel Becker <jlbec@evilplan.org>
> >>>>>>> Cc: Christoph Hellwig <hch@lst.de>
> >>>>>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> >>>>>>> ---
> >>>>>>>     arch/x86/coco/core.c        |  4 ++++
> >>>>>>>     drivers/virt/coco/tsm.c     | 14 ++++++++++----
> >>>>>>>     include/linux/cc_platform.h |  8 ++++++++
> >>>>>>>     3 files changed, 22 insertions(+), 4 deletions(-)
> >>>>>>>
> >>>>
> >>>>>>
> >>>>>> Any comment about the following query? I think introducing a CC flag for this use
> >>>>>> case is over kill.
> >>>>>>
> >>>>>> https://lore.kernel.org/lkml/6b90b223-46e0-4e6d-a17c-5caf72e3c949@linux.intel.com/
> >>>>>
> >>>>> If you don't think TDX will be able to make use of the SVSM attribute I can look at adding a callback. But I was waiting to see if anyone else had comments, for or against, before re-doing it all.
> >>>>>
> >>>>
> >>>> What about something like this (applied on top of patch 13):
> >>>>
> >>
> >>>> diff --git a/include/linux/tsm.h b/include/linux/tsm.h
> >>>> index 27cc97fe8dcd..5aaf626d178d 100644
> >>>> --- a/include/linux/tsm.h
> >>>> +++ b/include/linux/tsm.h
> >>>> @@ -74,7 +74,20 @@ extern const struct config_item_type tsm_report_default_type;
> >>>>    /* publish @privlevel, @privlevel_floor, and @auxblob attributes */
> >>>>    extern const struct config_item_type tsm_report_extra_type;
> >>>>    +/*
> >>>> + * Used to indicate the attribute group type to the visibility callback to
> >>>> + * avoid the callback having to examine the attribute name.
> >>>
> >>> Checking the attribute name will give more flexibility, right? Since it is one time
> >>> check, it should not be costly, right?
> >>
> >> I thought about checking the name(s), but what if in the future another attribute is added, then you have to remember to update multiple places. This way you have an enum that represents the related attributes. Is there a
> > 
> > I think it depends on how you implement the visibility function. If the vendor driver allows all attributes by default and denies few selected ones, you don't have to update the vendor driver for all new attributes. Letting the vendor driver decide whether to support any new attributes makes sense to me.
> > 
> >> scenario where you would want to not hide all attributes that are related? String comparisons just seem awkward to me.
> >>
> >> I suppose the config_item and configfs_attr could also be supplied on the callback if that's a requirement.
> > 
> > 
> > I am ok with enum based checks. But lets see what others think. Personally I think checking config attr name is more flexible.
> 
> I think we can do both. Supply the enum, config_item and configfs_attr 
> and then the callback can decide using the enum and/or the attribute name.
> 
> It could be extended to the current extra attributes, too. The enum 
> could have a TSM_TYPE_EXTRA (for the privlevel, privlevel_floor and 
> auxblob) and allow those to be hidden as appropriate, too.
> 

I guess I should have read all feedback before supplying my own, but
looks like you arrived at the same result.

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

* Re: [PATCH v3 09/14] virt: sev-guest: Choose the VMPCK key based on executing VMPL
  2024-04-16  4:54   ` Dan Williams
@ 2024-04-16 15:17     ` Tom Lendacky
  2024-04-16 15:47       ` Dan Williams
  0 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-04-16 15:17 UTC (permalink / raw)
  To: Dan Williams, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
	Ashish Kalra

On 4/15/24 23:54, Dan Williams wrote:
> Hey, Tom, came looking to review the tsm_report changes and noticed
> this...
> 
> Tom Lendacky wrote:
>> Currently, the sev-guest driver uses the vmpck-0 key by default. When an
>> SVSM is present the kernel is running at a VMPL other than 0 and the
>> vmpck-0 key is no longer available. So choose the vmpck key based on the
>> active VMPL level.
> 
> The module parameter is not mentioned in the changelog. Is it not
> sufficient to always use snp_get_vmpl(), and if not should there be some
> documentation about when to specify vmpck_id?

It is possible to encounter an issue that causes the vmpck key to be 
cleared. In that situation, the guest is allowed to use a vmpck key 
associated with a lower VMPL. For that reason, the module parameter was 
added to the driver when it was initially created.

I can update the changelog to mention this.

Note that as long as the vmpck key exists, a guest running at VMPL2 
could request a VMPL0 report using the vmpck0 key, that is why it is 
important that the SVSM clear to zero any vmpck key that represents a 
higher privilege. For example, if the SVSM (running at VMPL0) launches 
the guest at VMPL2, it should zero out the vmpck0 and vmpck1 keys in the 
SNP Secrets Page supplied to the guest.

> 
> Do users know that "vmpl" and "vmpck_id" are interchangeable?

Yes, they should be aware of the relation of VMPL to VMPCK from the SNP 
specification.

Thanks,
Tom

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

* Re: [PATCH v3 10/14] configfs-tsm: Allow the privlevel_floor attribute to be updated
  2024-04-16  4:55   ` Dan Williams
@ 2024-04-16 15:23     ` Tom Lendacky
  2024-04-16 15:57       ` Dan Williams
  0 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-04-16 15:23 UTC (permalink / raw)
  To: Dan Williams, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
	Ashish Kalra

On 4/15/24 23:55, Dan Williams wrote:
> Tom Lendacky wrote:
>> With the introduction of an SVSM, Linux will be running at a non-zero
>> VMPL. Any request for an attestation report at a higher priviledge VMPL
>> than what Linux is currently running will result in an error. Allow for
>> the privlevel_floor attribute to be updated dynamically so that the
>> attribute may be set dynamically.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>>   drivers/virt/coco/sev-guest/sev-guest.c | 5 ++++-
>>   include/linux/tsm.h                     | 2 +-
>>   2 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
>> index 1ff897913bf4..bba6531cb606 100644
>> --- a/drivers/virt/coco/sev-guest/sev-guest.c
>> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
>> @@ -885,7 +885,7 @@ static int sev_report_new(struct tsm_report *report, void *data)
>>   	return 0;
>>   }
>>   
>> -static const struct tsm_ops sev_tsm_ops = {
>> +static struct tsm_ops sev_tsm_ops = {
>>   	.name = KBUILD_MODNAME,
>>   	.report_new = sev_report_new,
>>   };
>> @@ -972,6 +972,9 @@ static int __init sev_guest_probe(struct platform_device *pdev)
>>   	snp_dev->input.resp_gpa = __pa(snp_dev->response);
>>   	snp_dev->input.data_gpa = __pa(snp_dev->certs_data);
>>   
>> +	/* Set the privlevel_floor attribute based on the current VMPL */
>> +	sev_tsm_ops.privlevel_floor = snp_get_vmpl();
> 
> Why is this not vmpck_id?

Good catch, this probably should be pulled out separately and submitted 
as a Fixes: against the current support. If you think it's important 
enough, I can do that and put this at the beginning of the series. Or I 
can just modify this to use the vmpck_id value. Any preference?

Thanks,
Tom

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

* Re: [PATCH v3 09/14] virt: sev-guest: Choose the VMPCK key based on executing VMPL
  2024-04-16 15:17     ` Tom Lendacky
@ 2024-04-16 15:47       ` Dan Williams
  0 siblings, 0 replies; 61+ messages in thread
From: Dan Williams @ 2024-04-16 15:47 UTC (permalink / raw)
  To: Tom Lendacky, Dan Williams, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
	Ashish Kalra

Tom Lendacky wrote:
> On 4/15/24 23:54, Dan Williams wrote:
> > Hey, Tom, came looking to review the tsm_report changes and noticed
> > this...
> > 
> > Tom Lendacky wrote:
> >> Currently, the sev-guest driver uses the vmpck-0 key by default. When an
> >> SVSM is present the kernel is running at a VMPL other than 0 and the
> >> vmpck-0 key is no longer available. So choose the vmpck key based on the
> >> active VMPL level.
> > 
> > The module parameter is not mentioned in the changelog. Is it not
> > sufficient to always use snp_get_vmpl(), and if not should there be some
> > documentation about when to specify vmpck_id?
> 
> It is possible to encounter an issue that causes the vmpck key to be 
> cleared. In that situation, the guest is allowed to use a vmpck key 
> associated with a lower VMPL. For that reason, the module parameter was 
> added to the driver when it was initially created.

Oh, sorry, misread that the module parameter was not new.

> I can update the changelog to mention this.

I guess it is too late now, but a proper sysfs attribute rather than a
module parameter would let you do sanity checking on the writes and
allow a natural place to document behavior in
Documentation/ABI/testing/sysfs-devices-sev-guest.

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

* Re: [PATCH v3 11/14] x86/sev: Extend the config-fs attestation support for an SVSM
  2024-04-16  5:37   ` Dan Williams
@ 2024-04-16 15:53     ` Tom Lendacky
  2024-04-16 16:19       ` Dan Williams
  0 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-04-16 15:53 UTC (permalink / raw)
  To: Dan Williams, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
	Ashish Kalra

On 4/16/24 00:37, Dan Williams wrote:
> Tom Lendacky wrote:
>> When an SVSM is present, the guest can also request attestation reports
>> from the SVSM. These SVSM attestation reports can be used to attest the
>> SVSM and any services running within the SVSM.
>>
>> Extend the config-fs attestation support to allow for an SVSM attestation
>> report. This involves creating four (4) new config-fs attributes:
>>
>>    - 'service-provider' (input)
>>      This attribute is used to determine whether the attestation request
>>      should be sent to the specified service provider or to the SEV
>>      firmware. The SVSM service provider is represented by the value
>>      'svsm'.
>>
>>    - 'service_guid' (input)
>>      Used for requesting the attestation of a single service within the
>>      service provider. A null GUID implies that the SVSM_ATTEST_SERVICES
>>      call should be used to request the attestation report. A non-null
>>      GUID implies that the SVSM_ATTEST_SINGLE_SERVICE call should be used.
>>
>>    - 'service_manifest_version' (input)
>>      Used with the SVSM_ATTEST_SINGLE_SERVICE call, the service version
>>      represents a specific service manifest version be used for the
>>      attestation report.
>>
>>    - 'manifestblob' (output)
>>      Used to return the service manifest associated with the attestation
>>      report.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>>   Documentation/ABI/testing/configfs-tsm  |  69 +++++++++++
>>   arch/x86/include/asm/sev.h              |  31 ++++-
>>   arch/x86/kernel/sev.c                   |  50 ++++++++
>>   drivers/virt/coco/sev-guest/sev-guest.c | 151 ++++++++++++++++++++++++
>>   drivers/virt/coco/tsm.c                 |  93 ++++++++++++++-
>>   include/linux/tsm.h                     |  11 ++
>>   6 files changed, 402 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
>> index dd24202b5ba5..72a7acdb5258 100644
>> --- a/Documentation/ABI/testing/configfs-tsm
>> +++ b/Documentation/ABI/testing/configfs-tsm
>> @@ -31,6 +31,21 @@ Description:
>>   		Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ.
>>   		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
>>   
>> +What:		/sys/kernel/config/tsm/report/$name/manifestblob
>> +Date:		January, 2024
>> +KernelVersion:	v6.10
>> +Contact:	linux-coco@lists.linux.dev
>> +Description:
>> +		(RO) Optional supplemental data that a TSM may emit, visibility
>> +		of this attribute depends on TSM, and may be empty if no
>> +		manifest data is available.
>> +
>> +		When @provider is "sev_guest" and the @service_provider is
>> +		"svsm" this file contains the service manifest used for the SVSM
>> +		attestation report from the Secure VM Service Module for SEV-SNP
>> +		Guests v1.00 Section 7.
>> +		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
> 
> Should this be "See 'service_provider' for the format of this blob"? To
> date external "format specification" links are only referenced once in
> this file, and this one is now duplicated.

Yes, I can do that for this and the other ones you identified below.

> 
> 
>> +
>>   What:		/sys/kernel/config/tsm/report/$name/provider
>>   Date:		September, 2023
>>   KernelVersion:	v6.7
>> @@ -80,3 +95,57 @@ Contact:	linux-coco@lists.linux.dev
>>   Description:
>>   		(RO) Indicates the minimum permissible value that can be written
>>   		to @privlevel.
>> +
>> +What:		/sys/kernel/config/tsm/report/$name/service_provider
>> +Date:		January, 2024
>> +KernelVersion:	v6.10
>> +Contact:	linux-coco@lists.linux.dev
>> +Description:
>> +		(WO) Attribute is visible if a TSM implementation provider
>> +		supports the concept of attestation reports from a service
>> +		provider for TVMs, like SEV-SNP running under an SVSM.
>> +		Specifying the service provider via this attribute will create
>> +		an attestation report as specified by the service provider.
>> +		Currently supported service-providers are:
>> +			svsm
>> +
>> +		For the SVSM service provider, see the Secure VM Service Module
>> +		for SEV-SNP Guests v1.00 Section 7.
>> +		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
> 
> Given "SVSM" is a cross vendor concept should this explicitly
> callout: "For provider.service_provider == sev_guest.svsm" as
> preparation for other implementations defining their "svsm" manifest
> format?

I'm not sure. Do we need to get that specific? If SVSM is cross vendor, 
will it be using / adding to the existing SVSM specification? If not, 
then each vendor is likely to have its own name for the SVSM concept 
that would be unique enough...

> 

>> +
>> +What:		/sys/kernel/config/tsm/report/$name/service_manifest_version
>> +Date:		January, 2024
>> +KernelVersion:	v6.10
>> +Contact:	linux-coco@lists.linux.dev
>> +Description:
>> +		(WO) Attribute is visible if a TSM implementation provider
>> +		supports the concept of attestation reports from a service
>> +		provider for TVMs, like SEV-SNP running under an SVSM.
>> +		Indicates the service manifest version requested for the
>> +		attestation report. If this field is not set by the user,
>> +		the default manifest version of the service (the service's
>> +		initial/first manifest version) is returned. The initial
>> +		manifest version is always available.
> 
> ...and that number is zero? Is there any expectation that the kernel

Yes, that number is zero.

> sanity checks this version, or how does the user figure out they need to
> roll this request back?

Right now there aren't any non-zero versions, so there is nothing for 
the user to figure out. However, the service will determine when it 
creates a new version and then the user will need to understand what the 
reason for that is and decide. I'm not sure I can give you a specific 
answer at this stage, but we need to allow for a change in the manifest 
without affecting existing users.

And since the spec has been approved already, I can't really go back and 
add a requirement that manifest format always be additive.

> 
>> +
>> +		For the SVSM service provider, see the Secure VM Service Module
>> +		for SEV-SNP Guests v1.00 Section 7.
>> +		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
> 

>> +static ssize_t tsm_report_service_provider_store(struct config_item *cfg,
>> +						 const char *buf, size_t len)
>> +{
>> +	struct tsm_report *report = to_tsm_report(cfg);
>> +	size_t sp_len;
>> +	char *sp;
>> +	int rc;
>> +
>> +	guard(rwsem_write)(&tsm_rwsem);
>> +	rc = try_advance_write_generation(report);
>> +	if (rc)
>> +		return rc;
>> +
>> +	sp_len = (buf[len - 1] != '\n') ? len : len - 1;
> 
> This feels like it wants a sysfs_strdup().

If there start to be more string oriented operations in the file, then 
it might be worth it. For now I don't really see a reason.

> 
>> +
>> +	sp = kstrndup(buf, sp_len, GFP_KERNEL);
>> +	if (!sp)
>> +		return -ENOMEM;
>> +	kfree(report->desc.service_provider);
>> +
>> +	report->desc.service_provider = sp;
>> +
>> +	return len;
>> +}
>> +CONFIGFS_ATTR_WO(tsm_report_, service_provider);
>> +

>>   #define TSM_DEFAULT_ATTRS() \
>>   	&tsm_report_attr_generation, \
>>   	&tsm_report_attr_provider
>> @@ -265,6 +348,9 @@ static struct configfs_attribute *tsm_report_extra_attrs[] = {
>>   	TSM_DEFAULT_ATTRS(),
>>   	&tsm_report_attr_privlevel,
>>   	&tsm_report_attr_privlevel_floor,
>> +	&tsm_report_attr_service_provider,
>> +	&tsm_report_attr_service_guid,
>> +	&tsm_report_attr_service_manifest_version,
> 
> Shouldn't this patch come after the configfs dynamic visibility so there
> is no point in the history where vestigial attributes show up?

Sure, I can do that.

Thanks,
Tom


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

* Re: [PATCH v3 10/14] configfs-tsm: Allow the privlevel_floor attribute to be updated
  2024-04-16 15:23     ` Tom Lendacky
@ 2024-04-16 15:57       ` Dan Williams
  2024-04-16 16:17         ` Tom Lendacky
  0 siblings, 1 reply; 61+ messages in thread
From: Dan Williams @ 2024-04-16 15:57 UTC (permalink / raw)
  To: Tom Lendacky, Dan Williams, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
	Ashish Kalra

Tom Lendacky wrote:
> On 4/15/24 23:55, Dan Williams wrote:
> > Tom Lendacky wrote:
> >> With the introduction of an SVSM, Linux will be running at a non-zero
> >> VMPL. Any request for an attestation report at a higher priviledge VMPL
> >> than what Linux is currently running will result in an error. Allow for
> >> the privlevel_floor attribute to be updated dynamically so that the
> >> attribute may be set dynamically.
> >>
> >> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> >> ---
> >>   drivers/virt/coco/sev-guest/sev-guest.c | 5 ++++-
> >>   include/linux/tsm.h                     | 2 +-
> >>   2 files changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
> >> index 1ff897913bf4..bba6531cb606 100644
> >> --- a/drivers/virt/coco/sev-guest/sev-guest.c
> >> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
> >> @@ -885,7 +885,7 @@ static int sev_report_new(struct tsm_report *report, void *data)
> >>   	return 0;
> >>   }
> >>   
> >> -static const struct tsm_ops sev_tsm_ops = {
> >> +static struct tsm_ops sev_tsm_ops = {
> >>   	.name = KBUILD_MODNAME,
> >>   	.report_new = sev_report_new,
> >>   };
> >> @@ -972,6 +972,9 @@ static int __init sev_guest_probe(struct platform_device *pdev)
> >>   	snp_dev->input.resp_gpa = __pa(snp_dev->response);
> >>   	snp_dev->input.data_gpa = __pa(snp_dev->certs_data);
> >>   
> >> +	/* Set the privlevel_floor attribute based on the current VMPL */
> >> +	sev_tsm_ops.privlevel_floor = snp_get_vmpl();
> > 
> > Why is this not vmpck_id?
> 
> Good catch, this probably should be pulled out separately and submitted 
> as a Fixes: against the current support. If you think it's important 
> enough, I can do that and put this at the beginning of the series. Or I 
> can just modify this to use the vmpck_id value. Any preference?

I dunno, you tell me. What breaks if privlevel_floor is mismatched vs
vmpl and/or vmpck_id? If it warrants a "Fixes:" it should probably be
broken out.

However, I *guess* it is just adding some sanity checking precision to
userspace requests and makes some input validation not catch errors when
userspace tries to generate reports from the wrong level, right? I.e.
privlevel_floor may be lower than expected, but userspace should not be
depending on that since the report generation will fail.

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

* Re: [PATCH v3 12/14] fs/configfs: Add a callback to determine attribute visibility
  2024-04-16  5:46   ` Dan Williams
@ 2024-04-16 16:01     ` Tom Lendacky
  2024-04-16 18:25       ` Dan Williams
  0 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-04-16 16:01 UTC (permalink / raw)
  To: Dan Williams, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
	Ashish Kalra, Joel Becker, Christoph Hellwig

On 4/16/24 00:46, Dan Williams wrote:
> Tom Lendacky wrote:
>> In order to support dynamic decisions as to whether an attribute should be
>> created, add a callback that returns a bool to indicate whether the
>> attribute should be display. If no callback is registered, the attribute
> 
> s/display/displayed/

Will fix.

> 
>> is displayed by default.
>>
>> Cc: Joel Becker <jlbec@evilplan.org>
>> Cc: Christoph Hellwig <hch@lst.de>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>>   fs/configfs/file.c       |   7 +++
>>   include/linux/configfs.h | 111 +++++++++++++++++++++++++++------------
>>   2 files changed, 84 insertions(+), 34 deletions(-)
>>
>> diff --git a/fs/configfs/file.c b/fs/configfs/file.c
>> index 0ad32150611e..a976c183756c 100644
>> --- a/fs/configfs/file.c
>> +++ b/fs/configfs/file.c
>> @@ -451,6 +451,9 @@ int configfs_create_file(struct config_item * item, const struct configfs_attrib
>>   	umode_t mode = (attr->ca_mode & S_IALLUGO) | S_IFREG;
>>   	int error = 0;
>>   
>> +	if (attr->is_visible && !attr->is_visible(item, attr))
>> +		return 0;
>> +
>>   	inode_lock_nested(d_inode(dir), I_MUTEX_NORMAL);
>>   	error = configfs_make_dirent(parent_sd, NULL, (void *) attr, mode,
>>   				     CONFIGFS_ITEM_ATTR, parent_sd->s_frag);
>> @@ -470,9 +473,13 @@ int configfs_create_bin_file(struct config_item *item,
>>   {
>>   	struct dentry *dir = item->ci_dentry;
>>   	struct configfs_dirent *parent_sd = dir->d_fsdata;
>> +	const struct configfs_attribute *attr = &bin_attr->cb_attr;
>>   	umode_t mode = (bin_attr->cb_attr.ca_mode & S_IALLUGO) | S_IFREG;
>>   	int error = 0;
>>   
>> +	if (attr->is_visible && !attr->is_visible(item, attr))
>> +		return 0;
>> +
>>   	inode_lock_nested(dir->d_inode, I_MUTEX_NORMAL);
>>   	error = configfs_make_dirent(parent_sd, NULL, (void *) bin_attr, mode,
>>   				     CONFIGFS_ITEM_BIN_ATTR, parent_sd->s_frag);
>> diff --git a/include/linux/configfs.h b/include/linux/configfs.h
>> index 2606711adb18..c836d7bc7c9e 100644
>> --- a/include/linux/configfs.h
>> +++ b/include/linux/configfs.h
>> @@ -116,35 +116,57 @@ struct configfs_attribute {
>>   	const char		*ca_name;
>>   	struct module 		*ca_owner;
>>   	umode_t			ca_mode;
>> +	bool (*is_visible)(const struct config_item *, const struct configfs_attribute *);
>>   	ssize_t (*show)(struct config_item *, char *);
>>   	ssize_t (*store)(struct config_item *, const char *, size_t);
>>   };
>>   
>> -#define CONFIGFS_ATTR(_pfx, _name)			\
>> +#define __CONFIGFS_ATTR(_pfx, _name, _vis)		\
>>   static struct configfs_attribute _pfx##attr_##_name = {	\
>>   	.ca_name	= __stringify(_name),		\
>>   	.ca_mode	= S_IRUGO | S_IWUSR,		\
>>   	.ca_owner	= THIS_MODULE,			\
>> +	.is_visible	= _vis,				\
>>   	.show		= _pfx##_name##_show,		\
>>   	.store		= _pfx##_name##_store,		\
> 
> Shouldn't this operation live in configfs_group_operations? That would
> mirror the sysfs organization, and likely saves some memory.

I suppose it can, but then you lose the grouping of attributes within 
the same directory, right? A configfs group will result in moving the 
entries into a subdirectory, right? If we go with the group level, then 
we will be moving the existing TSM extra attributes and the new TSM SVSM 
attributes into new, separate sub-directories.

Thanks,
Tom



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

* Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
  2024-04-16  5:47   ` Dan Williams
@ 2024-04-16 16:07     ` Tom Lendacky
  0 siblings, 0 replies; 61+ messages in thread
From: Tom Lendacky @ 2024-04-16 16:07 UTC (permalink / raw)
  To: Dan Williams, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
	Ashish Kalra, Joel Becker, Christoph Hellwig

On 4/16/24 00:47, Dan Williams wrote:
> Tom Lendacky wrote:
>> Config-fs provides support to hide individual attribute entries. Using
>> this support, base the display of the SVSM related entries on the presence
>> of an SVSM.
>>
>> Cc: Joel Becker <jlbec@evilplan.org>
>> Cc: Christoph Hellwig <hch@lst.de>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>>   arch/x86/coco/core.c        |  4 ++++
>>   drivers/virt/coco/tsm.c     | 14 ++++++++++----
>>   include/linux/cc_platform.h |  8 ++++++++
>>   3 files changed, 22 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/coco/core.c b/arch/x86/coco/core.c
>> index d07be9d05cd0..efa0f648f754 100644
>> --- a/arch/x86/coco/core.c
>> +++ b/arch/x86/coco/core.c
>> @@ -12,6 +12,7 @@
>>   
>>   #include <asm/coco.h>
>>   #include <asm/processor.h>
>> +#include <asm/sev.h>
>>   
>>   enum cc_vendor cc_vendor __ro_after_init = CC_VENDOR_NONE;
>>   u64 cc_mask __ro_after_init;
>> @@ -78,6 +79,9 @@ static bool noinstr amd_cc_platform_has(enum cc_attr attr)
>>   	case CC_ATTR_GUEST_STATE_ENCRYPT:
>>   		return sev_status & MSR_AMD64_SEV_ES_ENABLED;
>>   
>> +	case CC_ATTR_GUEST_SVSM_PRESENT:
>> +		return snp_get_vmpl();
>> +
>>   	/*
>>   	 * With SEV, the rep string I/O instructions need to be unrolled
>>   	 * but SEV-ES supports them through the #VC handler.
>> diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
>> index 46f230bf13ac..d30471874e87 100644
>> --- a/drivers/virt/coco/tsm.c
>> +++ b/drivers/virt/coco/tsm.c
>> @@ -64,6 +64,12 @@ static struct tsm_report_state *to_state(struct tsm_report *report)
>>   	return container_of(report, struct tsm_report_state, report);
>>   }
>>   
>> +static bool provider_visibility(const struct config_item *item,
>> +				const struct configfs_attribute *attr)
>> +{
>> +	return cc_platform_has(CC_ATTR_GUEST_SVSM_PRESENT);
>> +}
>> +
>>   static int try_advance_write_generation(struct tsm_report *report)
>>   {
>>   	struct tsm_report_state *state = to_state(report);
>> @@ -144,7 +150,7 @@ static ssize_t tsm_report_service_provider_store(struct config_item *cfg,
>>   
>>   	return len;
>>   }
>> -CONFIGFS_ATTR_WO(tsm_report_, service_provider);
>> +CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_provider, provider_visibility);
>>   
>>   static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
>>   					     const char *buf, size_t len)
>> @@ -165,7 +171,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
>>   
>>   	return len;
>>   }
>> -CONFIGFS_ATTR_WO(tsm_report_, service_guid);
>> +CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_guid, provider_visibility);
>>   
>>   static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg,
>>   							 const char *buf, size_t len)
>> @@ -186,7 +192,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg
>>   
>>   	return len;
>>   }
>> -CONFIGFS_ATTR_WO(tsm_report_, service_manifest_version);
>> +CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, service_manifest_version, provider_visibility);
>>   
>>   static ssize_t tsm_report_inblob_write(struct config_item *cfg,
>>   				       const void *buf, size_t count)
>> @@ -333,7 +339,7 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,
>>   
>>   	return tsm_report_read(report, buf, count, TSM_MANIFEST);
>>   }
>> -CONFIGFS_BIN_ATTR_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX);
>> +CONFIGFS_BIN_ATTR_VISIBLE_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX, provider_visibility);
> 
> Yeah the same callback specified multiple times feels like something
> that should only happen once at the group level.

I went with this to keep compatibility of all the attributes existing at 
the same level in the report sub-directory. Moving the existing extra 
attributes will break backwards compatibility if we want to apply 
visibility to them.

If we don't want to apply visibility to the existing extra attributes, 
then, yes, the the visibility support can be done at the group level 
instead of the file/attribute level.

Thoughts?

Thanks,
Tom

> 

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

* Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
  2024-04-16  6:03   ` Dan Williams
@ 2024-04-16 16:10     ` Tom Lendacky
  0 siblings, 0 replies; 61+ messages in thread
From: Tom Lendacky @ 2024-04-16 16:10 UTC (permalink / raw)
  To: Dan Williams, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
	Ashish Kalra, Joel Becker, Christoph Hellwig



On 4/16/24 01:03, Dan Williams wrote:
> Tom Lendacky wrote:
>> Config-fs provides support to hide individual attribute entries. Using
>> this support, base the display of the SVSM related entries on the presence
>> of an SVSM.
>>
>> Cc: Joel Becker <jlbec@evilplan.org>
>> Cc: Christoph Hellwig <hch@lst.de>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>>   arch/x86/coco/core.c        |  4 ++++
>>   drivers/virt/coco/tsm.c     | 14 ++++++++++----
>>   include/linux/cc_platform.h |  8 ++++++++
>>   3 files changed, 22 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/coco/core.c b/arch/x86/coco/core.c
>> index d07be9d05cd0..efa0f648f754 100644
>> --- a/arch/x86/coco/core.c
>> +++ b/arch/x86/coco/core.c
>> @@ -12,6 +12,7 @@
>>   
>>   #include <asm/coco.h>
>>   #include <asm/processor.h>
>> +#include <asm/sev.h>
>>   
>>   enum cc_vendor cc_vendor __ro_after_init = CC_VENDOR_NONE;
>>   u64 cc_mask __ro_after_init;
>> @@ -78,6 +79,9 @@ static bool noinstr amd_cc_platform_has(enum cc_attr attr)
>>   	case CC_ATTR_GUEST_STATE_ENCRYPT:
>>   		return sev_status & MSR_AMD64_SEV_ES_ENABLED;
>>   
>> +	case CC_ATTR_GUEST_SVSM_PRESENT:
>> +		return snp_get_vmpl();
>> +
>>   	/*
>>   	 * With SEV, the rep string I/O instructions need to be unrolled
>>   	 * but SEV-ES supports them through the #VC handler.
>> diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
>> index 46f230bf13ac..d30471874e87 100644
>> --- a/drivers/virt/coco/tsm.c
>> +++ b/drivers/virt/coco/tsm.c
>> @@ -64,6 +64,12 @@ static struct tsm_report_state *to_state(struct tsm_report *report)
>>   	return container_of(report, struct tsm_report_state, report);
>>   }
>>   
>> +static bool provider_visibility(const struct config_item *item,
>> +				const struct configfs_attribute *attr)
>> +{
>> +	return cc_platform_has(CC_ATTR_GUEST_SVSM_PRESENT);
>> +}
> 
> I expect this needs to be a callback into the provider ops because one
> of the other use cases for this visibility check is to get rid of the
> "extra" attributes and handle that visibility with the same mechanism.

Yes, worked through on the other thread.

But the "extra" attributes are likely to remain visible if we go in the 
group visibility direction, to provide compatibility.

Thanks,
Tom


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

* Re: [PATCH v3 10/14] configfs-tsm: Allow the privlevel_floor attribute to be updated
  2024-04-16 15:57       ` Dan Williams
@ 2024-04-16 16:17         ` Tom Lendacky
  0 siblings, 0 replies; 61+ messages in thread
From: Tom Lendacky @ 2024-04-16 16:17 UTC (permalink / raw)
  To: Dan Williams, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
	Ashish Kalra

On 4/16/24 10:57, Dan Williams wrote:
> Tom Lendacky wrote:
>> On 4/15/24 23:55, Dan Williams wrote:
>>> Tom Lendacky wrote:
>>>> With the introduction of an SVSM, Linux will be running at a non-zero
>>>> VMPL. Any request for an attestation report at a higher priviledge VMPL
>>>> than what Linux is currently running will result in an error. Allow for
>>>> the privlevel_floor attribute to be updated dynamically so that the
>>>> attribute may be set dynamically.
>>>>
>>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>>>> ---
>>>>    drivers/virt/coco/sev-guest/sev-guest.c | 5 ++++-
>>>>    include/linux/tsm.h                     | 2 +-
>>>>    2 files changed, 5 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
>>>> index 1ff897913bf4..bba6531cb606 100644
>>>> --- a/drivers/virt/coco/sev-guest/sev-guest.c
>>>> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
>>>> @@ -885,7 +885,7 @@ static int sev_report_new(struct tsm_report *report, void *data)
>>>>    	return 0;
>>>>    }
>>>>    
>>>> -static const struct tsm_ops sev_tsm_ops = {
>>>> +static struct tsm_ops sev_tsm_ops = {
>>>>    	.name = KBUILD_MODNAME,
>>>>    	.report_new = sev_report_new,
>>>>    };
>>>> @@ -972,6 +972,9 @@ static int __init sev_guest_probe(struct platform_device *pdev)
>>>>    	snp_dev->input.resp_gpa = __pa(snp_dev->response);
>>>>    	snp_dev->input.data_gpa = __pa(snp_dev->certs_data);
>>>>    
>>>> +	/* Set the privlevel_floor attribute based on the current VMPL */
>>>> +	sev_tsm_ops.privlevel_floor = snp_get_vmpl();
>>>
>>> Why is this not vmpck_id?
>>
>> Good catch, this probably should be pulled out separately and submitted
>> as a Fixes: against the current support. If you think it's important
>> enough, I can do that and put this at the beginning of the series. Or I
>> can just modify this to use the vmpck_id value. Any preference?
> 
> I dunno, you tell me. What breaks if privlevel_floor is mismatched vs
> vmpl and/or vmpck_id? If it warrants a "Fixes:" it should probably be
> broken out.
> 
> However, I *guess* it is just adding some sanity checking precision to
> userspace requests and makes some input validation not catch errors when
> userspace tries to generate reports from the wrong level, right? I.e.
> privlevel_floor may be lower than expected, but userspace should not be
> depending on that since the report generation will fail.

Yeah, it just results in a different type of error. If the VMPL 
specified by the user is numerically lower than the vmpck_id, then the 
request will fail with a specific return code value. With the change to 
privlevel_floor to use vmpck_id, then you would just get the error that 
much sooner when trying to set a value that is lower than the floor.

Since I don't think the vmpck_id module parameter is a common case 
today, let's just leave that change in this patch.

Thanks,
Tom

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

* Re: [PATCH v3 11/14] x86/sev: Extend the config-fs attestation support for an SVSM
  2024-04-16 15:53     ` Tom Lendacky
@ 2024-04-16 16:19       ` Dan Williams
  0 siblings, 0 replies; 61+ messages in thread
From: Dan Williams @ 2024-04-16 16:19 UTC (permalink / raw)
  To: Tom Lendacky, Dan Williams, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
	Ashish Kalra

Tom Lendacky wrote:
> On 4/16/24 00:37, Dan Williams wrote:
> > Tom Lendacky wrote:
> >> When an SVSM is present, the guest can also request attestation reports
> >> from the SVSM. These SVSM attestation reports can be used to attest the
> >> SVSM and any services running within the SVSM.
> >>
> >> Extend the config-fs attestation support to allow for an SVSM attestation
> >> report. This involves creating four (4) new config-fs attributes:
> >>
> >>    - 'service-provider' (input)
> >>      This attribute is used to determine whether the attestation request
> >>      should be sent to the specified service provider or to the SEV
> >>      firmware. The SVSM service provider is represented by the value
> >>      'svsm'.
> >>
> >>    - 'service_guid' (input)
> >>      Used for requesting the attestation of a single service within the
> >>      service provider. A null GUID implies that the SVSM_ATTEST_SERVICES
> >>      call should be used to request the attestation report. A non-null
> >>      GUID implies that the SVSM_ATTEST_SINGLE_SERVICE call should be used.
> >>
> >>    - 'service_manifest_version' (input)
> >>      Used with the SVSM_ATTEST_SINGLE_SERVICE call, the service version
> >>      represents a specific service manifest version be used for the
> >>      attestation report.
> >>
> >>    - 'manifestblob' (output)
> >>      Used to return the service manifest associated with the attestation
> >>      report.
> >>
> >> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
[..]
> >> +What:		/sys/kernel/config/tsm/report/$name/service_provider
> >> +Date:		January, 2024
> >> +KernelVersion:	v6.10
> >> +Contact:	linux-coco@lists.linux.dev
> >> +Description:
> >> +		(WO) Attribute is visible if a TSM implementation provider
> >> +		supports the concept of attestation reports from a service
> >> +		provider for TVMs, like SEV-SNP running under an SVSM.
> >> +		Specifying the service provider via this attribute will create
> >> +		an attestation report as specified by the service provider.
> >> +		Currently supported service-providers are:
> >> +			svsm
> >> +
> >> +		For the SVSM service provider, see the Secure VM Service Module
> >> +		for SEV-SNP Guests v1.00 Section 7.
> >> +		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
> > 
> > Given "SVSM" is a cross vendor concept should this explicitly
> > callout: "For provider.service_provider == sev_guest.svsm" as
> > preparation for other implementations defining their "svsm" manifest
> > format?
> 
> I'm not sure. Do we need to get that specific? If SVSM is cross vendor, 
> will it be using / adding to the existing SVSM specification? If not, 
> then each vendor is likely to have its own name for the SVSM concept 
> that would be unique enough...

Yeah, I guess we can kick can that down the road and see what other
vendors do. I know the coconut-svsm project is cross vendor, but I do
not know the details.

> >> +
> >> +What:		/sys/kernel/config/tsm/report/$name/service_manifest_version
> >> +Date:		January, 2024
> >> +KernelVersion:	v6.10
> >> +Contact:	linux-coco@lists.linux.dev
> >> +Description:
> >> +		(WO) Attribute is visible if a TSM implementation provider
> >> +		supports the concept of attestation reports from a service
> >> +		provider for TVMs, like SEV-SNP running under an SVSM.
> >> +		Indicates the service manifest version requested for the
> >> +		attestation report. If this field is not set by the user,
> >> +		the default manifest version of the service (the service's
> >> +		initial/first manifest version) is returned. The initial
> >> +		manifest version is always available.
> > 
> > ...and that number is zero? Is there any expectation that the kernel
> 
> Yes, that number is zero.
> 
> > sanity checks this version, or how does the user figure out they need to
> > roll this request back?
> 
> Right now there aren't any non-zero versions, so there is nothing for 
> the user to figure out. However, the service will determine when it 
> creates a new version and then the user will need to understand what the 
> reason for that is and decide. I'm not sure I can give you a specific 
> answer at this stage, but we need to allow for a change in the manifest 
> without affecting existing users.

Right, but it feels odd that userspace could write UINT_MAX to this
value and the kernel says, "yup, looks like a valid manifest version to
me".

> And since the spec has been approved already, I can't really go back and 
> add a requirement that manifest format always be additive.

Those breaking changes have not arrived yet so still a chance to
influence, no?

The documentation here at least guarantees that the initial manifest
version is always valid, and I expect the spec authors to realize that
the kernel has a role to play in not breaking existing userspace. I.e.
it is not in the spec's interest to disallow fallback to any
version between 0 and N-1 where N is the latest.

The kernel need not tolerate version induced breakage from ACPI
specification updates because that spec is committed to compatibility,
why does this spec need to be less disciplined than that?

> >> +
> >> +		For the SVSM service provider, see the Secure VM Service Module
> >> +		for SEV-SNP Guests v1.00 Section 7.
> >> +		https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
> > 
> 
> >> +static ssize_t tsm_report_service_provider_store(struct config_item *cfg,
> >> +						 const char *buf, size_t len)
> >> +{
> >> +	struct tsm_report *report = to_tsm_report(cfg);
> >> +	size_t sp_len;
> >> +	char *sp;
> >> +	int rc;
> >> +
> >> +	guard(rwsem_write)(&tsm_rwsem);
> >> +	rc = try_advance_write_generation(report);
> >> +	if (rc)
> >> +		return rc;
> >> +
> >> +	sp_len = (buf[len - 1] != '\n') ? len : len - 1;
> > 
> > This feels like it wants a sysfs_strdup().
> 
> If there start to be more string oriented operations in the file, then 
> it might be worth it. For now I don't really see a reason.

To be clear I was thinking of occurrences of this patten outside of this
file. Turns out this pattern is not as prevalent as I would have
guessed, resource_alignment_store() was the only occurrence I could
find. Skip for now works for me.

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

* Re: [PATCH v3 12/14] fs/configfs: Add a callback to determine attribute visibility
  2024-04-16 16:01     ` Tom Lendacky
@ 2024-04-16 18:25       ` Dan Williams
  2024-04-16 19:54         ` Tom Lendacky
  0 siblings, 1 reply; 61+ messages in thread
From: Dan Williams @ 2024-04-16 18:25 UTC (permalink / raw)
  To: Tom Lendacky, Dan Williams, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
	Ashish Kalra, Joel Becker, Christoph Hellwig

Tom Lendacky wrote:
> On 4/16/24 00:46, Dan Williams wrote:
> > Tom Lendacky wrote:
> >> In order to support dynamic decisions as to whether an attribute should be
> >> created, add a callback that returns a bool to indicate whether the
> >> attribute should be display. If no callback is registered, the attribute
[..]
> >> Cc: Joel Becker <jlbec@evilplan.org>
> >> Cc: Christoph Hellwig <hch@lst.de>
> >> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> >> ---
> >>   fs/configfs/file.c       |   7 +++
> >>   include/linux/configfs.h | 111 +++++++++++++++++++++++++++------------
> >>   2 files changed, 84 insertions(+), 34 deletions(-)
> >>
[..]
> >> diff --git a/include/linux/configfs.h b/include/linux/configfs.h
> >> index 2606711adb18..c836d7bc7c9e 100644
> >> --- a/include/linux/configfs.h
> >> +++ b/include/linux/configfs.h
> >> @@ -116,35 +116,57 @@ struct configfs_attribute {
> >>   	const char		*ca_name;
> >>   	struct module 		*ca_owner;
> >>   	umode_t			ca_mode;
> >> +	bool (*is_visible)(const struct config_item *, const struct configfs_attribute *);
> >>   	ssize_t (*show)(struct config_item *, char *);
> >>   	ssize_t (*store)(struct config_item *, const char *, size_t);
> >>   };
> >>   
> >> -#define CONFIGFS_ATTR(_pfx, _name)			\
> >> +#define __CONFIGFS_ATTR(_pfx, _name, _vis)		\
> >>   static struct configfs_attribute _pfx##attr_##_name = {	\
> >>   	.ca_name	= __stringify(_name),		\
> >>   	.ca_mode	= S_IRUGO | S_IWUSR,		\
> >>   	.ca_owner	= THIS_MODULE,			\
> >> +	.is_visible	= _vis,				\
> >>   	.show		= _pfx##_name##_show,		\
> >>   	.store		= _pfx##_name##_store,		\
> > 
> > Shouldn't this operation live in configfs_group_operations? That would
> > mirror the sysfs organization, and likely saves some memory.
> 
> I suppose it can, but then you lose the grouping of attributes within 
> the same directory, right? A configfs group will result in moving the 
> entries into a subdirectory, right? If we go with the group level, then 
> we will be moving the existing TSM extra attributes and the new TSM SVSM 
> attributes into new, separate sub-directories.

I am not following the concern about "losing the grouping"? Here is what
I was thinking with having the visibility routines in group operations.
This is just the broard strokes, it compiles, but still needs the finer
detail work to make tdx-guest skip all the attributes that do not apply
to it.  Might need to be broken up a bit more, but hopefully conveys the
idea. Does this address your grouping concern?

diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
index 87f241825bc3..39b8455f0ba5 100644
--- a/drivers/virt/coco/sev-guest/sev-guest.c
+++ b/drivers/virt/coco/sev-guest/sev-guest.c
@@ -968,7 +968,7 @@ static int __init sev_guest_probe(struct platform_device *pdev)
 	snp_dev->input.resp_gpa = __pa(snp_dev->response);
 	snp_dev->input.data_gpa = __pa(snp_dev->certs_data);
 
-	ret = tsm_register(&sev_tsm_ops, snp_dev, &tsm_report_extra_type);
+	ret = tsm_register(&sev_tsm_ops, snp_dev);
 	if (ret)
 		goto e_free_cert_data;
 
diff --git a/drivers/virt/coco/tdx-guest/tdx-guest.c b/drivers/virt/coco/tdx-guest/tdx-guest.c
index 1253bf76b570..654d20ea524a 100644
--- a/drivers/virt/coco/tdx-guest/tdx-guest.c
+++ b/drivers/virt/coco/tdx-guest/tdx-guest.c
@@ -301,7 +301,7 @@ static int __init tdx_guest_init(void)
 		goto free_misc;
 	}
 
-	ret = tsm_register(&tdx_tsm_ops, NULL, NULL);
+	ret = tsm_register(&tdx_tsm_ops, NULL);
 	if (ret)
 		goto free_quote;
 
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
index d1c2db83a8ca..b31be0e61728 100644
--- a/drivers/virt/coco/tsm.c
+++ b/drivers/virt/coco/tsm.c
@@ -14,7 +14,6 @@
 
 static struct tsm_provider {
 	const struct tsm_ops *ops;
-	const struct config_item_type *type;
 	void *data;
 } provider;
 static DECLARE_RWSEM(tsm_rwsem);
@@ -252,34 +251,18 @@ static ssize_t tsm_report_auxblob_read(struct config_item *cfg, void *buf,
 }
 CONFIGFS_BIN_ATTR_RO(tsm_report_, auxblob, NULL, TSM_OUTBLOB_MAX);
 
-#define TSM_DEFAULT_ATTRS() \
-	&tsm_report_attr_generation, \
-	&tsm_report_attr_provider
-
 static struct configfs_attribute *tsm_report_attrs[] = {
-	TSM_DEFAULT_ATTRS(),
-	NULL,
-};
-
-static struct configfs_attribute *tsm_report_extra_attrs[] = {
-	TSM_DEFAULT_ATTRS(),
-	&tsm_report_attr_privlevel,
-	&tsm_report_attr_privlevel_floor,
+	[TSM_REPORT_GENERATION] = &tsm_report_attr_generation,
+	[TSM_REPORT_PROVIDER] = &tsm_report_attr_provider,
+	[TSM_REPORT_PRIVLEVEL] = &tsm_report_attr_privlevel,
+	[TSM_REPORT_PRIVLEVEL_FLOOR] = &tsm_report_attr_privlevel_floor,
 	NULL,
 };
 
-#define TSM_DEFAULT_BIN_ATTRS() \
-	&tsm_report_attr_inblob, \
-	&tsm_report_attr_outblob
-
 static struct configfs_bin_attribute *tsm_report_bin_attrs[] = {
-	TSM_DEFAULT_BIN_ATTRS(),
-	NULL,
-};
-
-static struct configfs_bin_attribute *tsm_report_bin_extra_attrs[] = {
-	TSM_DEFAULT_BIN_ATTRS(),
-	&tsm_report_attr_auxblob,
+	[TSM_REPORT_INBLOB] = &tsm_report_attr_inblob,
+	[TSM_REPORT_OUTBLOB] = &tsm_report_attr_outblob,
+	[TSM_REPORT_AUXBLOB] = &tsm_report_attr_auxblob,
 	NULL,
 };
 
@@ -297,21 +280,12 @@ static struct configfs_item_operations tsm_report_item_ops = {
 	.release = tsm_report_item_release,
 };
 
-const struct config_item_type tsm_report_default_type = {
+static const struct config_item_type tsm_report_type = {
 	.ct_owner = THIS_MODULE,
 	.ct_bin_attrs = tsm_report_bin_attrs,
 	.ct_attrs = tsm_report_attrs,
 	.ct_item_ops = &tsm_report_item_ops,
 };
-EXPORT_SYMBOL_GPL(tsm_report_default_type);
-
-const struct config_item_type tsm_report_extra_type = {
-	.ct_owner = THIS_MODULE,
-	.ct_bin_attrs = tsm_report_bin_extra_attrs,
-	.ct_attrs = tsm_report_extra_attrs,
-	.ct_item_ops = &tsm_report_item_ops,
-};
-EXPORT_SYMBOL_GPL(tsm_report_extra_type);
 
 static struct config_item *tsm_report_make_item(struct config_group *group,
 						const char *name)
@@ -326,12 +300,38 @@ static struct config_item *tsm_report_make_item(struct config_group *group,
 	if (!state)
 		return ERR_PTR(-ENOMEM);
 
-	config_item_init_type_name(&state->cfg, name, provider.type);
+	config_item_init_type_name(&state->cfg, name, &tsm_report_type);
 	return &state->cfg;
 }
 
+static bool tsm_report_attr_visible(struct configfs_attribute *attr, int n)
+{
+	guard(rwsem_read)(&tsm_rwsem);
+	if (!provider.ops)
+		return false;
+
+	if (!provider.ops->is_visible)
+		return true;
+
+	return provider.ops->is_visible(n);
+}
+
+static bool tsm_report_bin_attr_visible(struct configfs_bin_attribute *attr,
+					int n)
+{
+	if (!provider.ops)
+		return false;
+
+	if (!provider.ops->is_bin_visible)
+		return true;
+
+	return provider.ops->is_bin_visible(n);
+}
+
 static struct configfs_group_operations tsm_report_group_ops = {
 	.make_item = tsm_report_make_item,
+	.is_visible = tsm_report_attr_visible,
+	.is_bin_visible = tsm_report_bin_attr_visible,
 };
 
 static const struct config_item_type tsm_reports_type = {
@@ -353,16 +353,10 @@ static struct configfs_subsystem tsm_configfs = {
 	.su_mutex = __MUTEX_INITIALIZER(tsm_configfs.su_mutex),
 };
 
-int tsm_register(const struct tsm_ops *ops, void *priv,
-		 const struct config_item_type *type)
+int tsm_register(const struct tsm_ops *ops, void *priv)
 {
 	const struct tsm_ops *conflict;
 
-	if (!type)
-		type = &tsm_report_default_type;
-	if (!(type == &tsm_report_default_type || type == &tsm_report_extra_type))
-		return -EINVAL;
-
 	guard(rwsem_write)(&tsm_rwsem);
 	conflict = provider.ops;
 	if (conflict) {
@@ -372,7 +366,6 @@ int tsm_register(const struct tsm_ops *ops, void *priv,
 
 	provider.ops = ops;
 	provider.data = priv;
-	provider.type = type;
 	return 0;
 }
 EXPORT_SYMBOL_GPL(tsm_register);
@@ -384,7 +377,6 @@ int tsm_unregister(const struct tsm_ops *ops)
 		return -EBUSY;
 	provider.ops = NULL;
 	provider.data = NULL;
-	provider.type = NULL;
 	return 0;
 }
 EXPORT_SYMBOL_GPL(tsm_unregister);
diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index 18677cd4e62f..213e88f4cec2 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -580,6 +580,7 @@ static void detach_attrs(struct config_item * item)
 static int populate_attrs(struct config_item *item)
 {
 	const struct config_item_type *t = item->ci_type;
+	struct configfs_group_operations *ops = t->ct_group_ops;
 	struct configfs_attribute *attr;
 	struct configfs_bin_attribute *bin_attr;
 	int error = 0;
@@ -589,12 +590,17 @@ static int populate_attrs(struct config_item *item)
 		return -EINVAL;
 	if (t->ct_attrs) {
 		for (i = 0; (attr = t->ct_attrs[i]) != NULL; i++) {
+			if (ops && ops->is_visible && !ops->is_visible(attr, i))
+				continue;
 			if ((error = configfs_create_file(item, attr)))
 				break;
 		}
 	}
 	if (t->ct_bin_attrs) {
 		for (i = 0; (bin_attr = t->ct_bin_attrs[i]) != NULL; i++) {
+			if (ops && ops->is_bin_visible &&
+			    !ops->is_bin_visible(bin_attr, i))
+				continue;
 			error = configfs_create_bin_file(item, bin_attr);
 			if (error)
 				break;
diff --git a/fs/configfs/file.c b/fs/configfs/file.c
index 0ad32150611e..356d23b6b9cf 100644
--- a/fs/configfs/file.c
+++ b/fs/configfs/file.c
@@ -444,7 +444,8 @@ const struct file_operations configfs_bin_file_operations = {
  *	@attr:	atrribute descriptor.
  */
 
-int configfs_create_file(struct config_item * item, const struct configfs_attribute * attr)
+int configfs_create_file(struct config_item *item,
+			 const struct configfs_attribute *attr)
 {
 	struct dentry *dir = item->ci_dentry;
 	struct configfs_dirent *parent_sd = dir->d_fsdata;
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 2606711adb18..31553f12db7c 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -216,6 +216,8 @@ struct configfs_group_operations {
 	struct config_group *(*make_group)(struct config_group *group, const char *name);
 	void (*disconnect_notify)(struct config_group *group, struct config_item *item);
 	void (*drop_item)(struct config_group *group, struct config_item *item);
+	bool (*is_visible)(struct configfs_attribute *attr, int n);
+	bool (*is_bin_visible)(struct configfs_bin_attribute *attr, int n);
 };
 
 struct configfs_subsystem {
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
index de8324a2223c..a45b12943223 100644
--- a/include/linux/tsm.h
+++ b/include/linux/tsm.h
@@ -42,6 +42,19 @@ struct tsm_report {
 	u8 *auxblob;
 };
 
+enum tsm_attr_index {
+	TSM_REPORT_GENERATION,
+	TSM_REPORT_PROVIDER,
+	TSM_REPORT_PRIVLEVEL,
+	TSM_REPORT_PRIVLEVEL_FLOOR,
+};
+
+enum tsm_bin_attr_index {
+	TSM_REPORT_INBLOB,
+	TSM_REPORT_OUTBLOB,
+	TSM_REPORT_AUXBLOB,
+};
+
 /**
  * struct tsm_ops - attributes and operations for tsm instances
  * @name: tsm id reflected in /sys/kernel/config/tsm/report/$report/provider
@@ -55,15 +68,11 @@ struct tsm_report {
 struct tsm_ops {
 	const char *name;
 	const unsigned int privlevel_floor;
+	bool (*is_visible)(enum tsm_attr_index index);
+	bool (*is_bin_visible)(enum tsm_bin_attr_index index);
 	int (*report_new)(struct tsm_report *report, void *data);
 };
 
-extern const struct config_item_type tsm_report_default_type;
-
-/* publish @privlevel, @privlevel_floor, and @auxblob attributes */
-extern const struct config_item_type tsm_report_extra_type;
-
-int tsm_register(const struct tsm_ops *ops, void *priv,
-		 const struct config_item_type *type);
+int tsm_register(const struct tsm_ops *ops, void *priv);
 int tsm_unregister(const struct tsm_ops *ops);
 #endif /* __TSM_H */

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

* Re: [PATCH v3 12/14] fs/configfs: Add a callback to determine attribute visibility
  2024-04-16 18:25       ` Dan Williams
@ 2024-04-16 19:54         ` Tom Lendacky
  2024-04-16 20:03           ` Dan Williams
  0 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-04-16 19:54 UTC (permalink / raw)
  To: Dan Williams, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
	Ashish Kalra, Joel Becker, Christoph Hellwig

On 4/16/24 13:25, Dan Williams wrote:
> Tom Lendacky wrote:
>> On 4/16/24 00:46, Dan Williams wrote:
>>> Tom Lendacky wrote:
>>>> In order to support dynamic decisions as to whether an attribute should be
>>>> created, add a callback that returns a bool to indicate whether the
>>>> attribute should be display. If no callback is registered, the attribute
> [..]
>>>> Cc: Joel Becker <jlbec@evilplan.org>
>>>> Cc: Christoph Hellwig <hch@lst.de>
>>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>>>> ---
>>>>    fs/configfs/file.c       |   7 +++
>>>>    include/linux/configfs.h | 111 +++++++++++++++++++++++++++------------
>>>>    2 files changed, 84 insertions(+), 34 deletions(-)
>>>>
> [..]
>>>> diff --git a/include/linux/configfs.h b/include/linux/configfs.h
>>>> index 2606711adb18..c836d7bc7c9e 100644
>>>> --- a/include/linux/configfs.h
>>>> +++ b/include/linux/configfs.h
>>>> @@ -116,35 +116,57 @@ struct configfs_attribute {
>>>>    	const char		*ca_name;
>>>>    	struct module 		*ca_owner;
>>>>    	umode_t			ca_mode;
>>>> +	bool (*is_visible)(const struct config_item *, const struct configfs_attribute *);
>>>>    	ssize_t (*show)(struct config_item *, char *);
>>>>    	ssize_t (*store)(struct config_item *, const char *, size_t);
>>>>    };
>>>>    
>>>> -#define CONFIGFS_ATTR(_pfx, _name)			\
>>>> +#define __CONFIGFS_ATTR(_pfx, _name, _vis)		\
>>>>    static struct configfs_attribute _pfx##attr_##_name = {	\
>>>>    	.ca_name	= __stringify(_name),		\
>>>>    	.ca_mode	= S_IRUGO | S_IWUSR,		\
>>>>    	.ca_owner	= THIS_MODULE,			\
>>>> +	.is_visible	= _vis,				\
>>>>    	.show		= _pfx##_name##_show,		\
>>>>    	.store		= _pfx##_name##_store,		\
>>>
>>> Shouldn't this operation live in configfs_group_operations? That would
>>> mirror the sysfs organization, and likely saves some memory.
>>
>> I suppose it can, but then you lose the grouping of attributes within
>> the same directory, right? A configfs group will result in moving the
>> entries into a subdirectory, right? If we go with the group level, then
>> we will be moving the existing TSM extra attributes and the new TSM SVSM
>> attributes into new, separate sub-directories.
> 
> I am not following the concern about "losing the grouping"? Here is what
> I was thinking with having the visibility routines in group operations.
> This is just the broard strokes, it compiles, but still needs the finer
> detail work to make tdx-guest skip all the attributes that do not apply
> to it.  Might need to be broken up a bit more, but hopefully conveys the
> idea. Does this address your grouping concern?

Yes and no. Basically the is_visible()/is_bin_visible() callback will 
have to check every index value for a "group" against the passed in 
value. I was trying to group the values together using an enum in order 
to make it a bit easier and more readable in the callback. Adding 
another attribute to the group requires updates in multiple places. But 
thats just how I was looking at it. I can also see where you might want 
to selectively hide/show entries and this method works well for that.

I'll follow this approach (add you as Co-developed-by: or Suggested-by:, 
whichever you prefer) and submit a v4.

Thanks,
Tom

> 
> diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
> index 87f241825bc3..39b8455f0ba5 100644
> --- a/drivers/virt/coco/sev-guest/sev-guest.c
> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
> @@ -968,7 +968,7 @@ static int __init sev_guest_probe(struct platform_device *pdev)
>   	snp_dev->input.resp_gpa = __pa(snp_dev->response);
>   	snp_dev->input.data_gpa = __pa(snp_dev->certs_data);
>   
> -	ret = tsm_register(&sev_tsm_ops, snp_dev, &tsm_report_extra_type);
> +	ret = tsm_register(&sev_tsm_ops, snp_dev);
>   	if (ret)
>   		goto e_free_cert_data;
>   
> diff --git a/drivers/virt/coco/tdx-guest/tdx-guest.c b/drivers/virt/coco/tdx-guest/tdx-guest.c
> index 1253bf76b570..654d20ea524a 100644
> --- a/drivers/virt/coco/tdx-guest/tdx-guest.c
> +++ b/drivers/virt/coco/tdx-guest/tdx-guest.c
> @@ -301,7 +301,7 @@ static int __init tdx_guest_init(void)
>   		goto free_misc;
>   	}
>   
> -	ret = tsm_register(&tdx_tsm_ops, NULL, NULL);
> +	ret = tsm_register(&tdx_tsm_ops, NULL);
>   	if (ret)
>   		goto free_quote;
>   
> diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
> index d1c2db83a8ca..b31be0e61728 100644
> --- a/drivers/virt/coco/tsm.c
> +++ b/drivers/virt/coco/tsm.c
> @@ -14,7 +14,6 @@
>   
>   static struct tsm_provider {
>   	const struct tsm_ops *ops;
> -	const struct config_item_type *type;
>   	void *data;
>   } provider;
>   static DECLARE_RWSEM(tsm_rwsem);
> @@ -252,34 +251,18 @@ static ssize_t tsm_report_auxblob_read(struct config_item *cfg, void *buf,
>   }
>   CONFIGFS_BIN_ATTR_RO(tsm_report_, auxblob, NULL, TSM_OUTBLOB_MAX);
>   
> -#define TSM_DEFAULT_ATTRS() \
> -	&tsm_report_attr_generation, \
> -	&tsm_report_attr_provider
> -
>   static struct configfs_attribute *tsm_report_attrs[] = {
> -	TSM_DEFAULT_ATTRS(),
> -	NULL,
> -};
> -
> -static struct configfs_attribute *tsm_report_extra_attrs[] = {
> -	TSM_DEFAULT_ATTRS(),
> -	&tsm_report_attr_privlevel,
> -	&tsm_report_attr_privlevel_floor,
> +	[TSM_REPORT_GENERATION] = &tsm_report_attr_generation,
> +	[TSM_REPORT_PROVIDER] = &tsm_report_attr_provider,
> +	[TSM_REPORT_PRIVLEVEL] = &tsm_report_attr_privlevel,
> +	[TSM_REPORT_PRIVLEVEL_FLOOR] = &tsm_report_attr_privlevel_floor,
>   	NULL,
>   };
>   
> -#define TSM_DEFAULT_BIN_ATTRS() \
> -	&tsm_report_attr_inblob, \
> -	&tsm_report_attr_outblob
> -
>   static struct configfs_bin_attribute *tsm_report_bin_attrs[] = {
> -	TSM_DEFAULT_BIN_ATTRS(),
> -	NULL,
> -};
> -
> -static struct configfs_bin_attribute *tsm_report_bin_extra_attrs[] = {
> -	TSM_DEFAULT_BIN_ATTRS(),
> -	&tsm_report_attr_auxblob,
> +	[TSM_REPORT_INBLOB] = &tsm_report_attr_inblob,
> +	[TSM_REPORT_OUTBLOB] = &tsm_report_attr_outblob,
> +	[TSM_REPORT_AUXBLOB] = &tsm_report_attr_auxblob,
>   	NULL,
>   };
>   
> @@ -297,21 +280,12 @@ static struct configfs_item_operations tsm_report_item_ops = {
>   	.release = tsm_report_item_release,
>   };
>   
> -const struct config_item_type tsm_report_default_type = {
> +static const struct config_item_type tsm_report_type = {
>   	.ct_owner = THIS_MODULE,
>   	.ct_bin_attrs = tsm_report_bin_attrs,
>   	.ct_attrs = tsm_report_attrs,
>   	.ct_item_ops = &tsm_report_item_ops,
>   };
> -EXPORT_SYMBOL_GPL(tsm_report_default_type);
> -
> -const struct config_item_type tsm_report_extra_type = {
> -	.ct_owner = THIS_MODULE,
> -	.ct_bin_attrs = tsm_report_bin_extra_attrs,
> -	.ct_attrs = tsm_report_extra_attrs,
> -	.ct_item_ops = &tsm_report_item_ops,
> -};
> -EXPORT_SYMBOL_GPL(tsm_report_extra_type);
>   
>   static struct config_item *tsm_report_make_item(struct config_group *group,
>   						const char *name)
> @@ -326,12 +300,38 @@ static struct config_item *tsm_report_make_item(struct config_group *group,
>   	if (!state)
>   		return ERR_PTR(-ENOMEM);
>   
> -	config_item_init_type_name(&state->cfg, name, provider.type);
> +	config_item_init_type_name(&state->cfg, name, &tsm_report_type);
>   	return &state->cfg;
>   }
>   
> +static bool tsm_report_attr_visible(struct configfs_attribute *attr, int n)
> +{
> +	guard(rwsem_read)(&tsm_rwsem);
> +	if (!provider.ops)
> +		return false;
> +
> +	if (!provider.ops->is_visible)
> +		return true;
> +
> +	return provider.ops->is_visible(n);
> +}
> +
> +static bool tsm_report_bin_attr_visible(struct configfs_bin_attribute *attr,
> +					int n)
> +{
> +	if (!provider.ops)
> +		return false;
> +
> +	if (!provider.ops->is_bin_visible)
> +		return true;
> +
> +	return provider.ops->is_bin_visible(n);
> +}
> +
>   static struct configfs_group_operations tsm_report_group_ops = {
>   	.make_item = tsm_report_make_item,
> +	.is_visible = tsm_report_attr_visible,
> +	.is_bin_visible = tsm_report_bin_attr_visible,
>   };
>   
>   static const struct config_item_type tsm_reports_type = {
> @@ -353,16 +353,10 @@ static struct configfs_subsystem tsm_configfs = {
>   	.su_mutex = __MUTEX_INITIALIZER(tsm_configfs.su_mutex),
>   };
>   
> -int tsm_register(const struct tsm_ops *ops, void *priv,
> -		 const struct config_item_type *type)
> +int tsm_register(const struct tsm_ops *ops, void *priv)
>   {
>   	const struct tsm_ops *conflict;
>   
> -	if (!type)
> -		type = &tsm_report_default_type;
> -	if (!(type == &tsm_report_default_type || type == &tsm_report_extra_type))
> -		return -EINVAL;
> -
>   	guard(rwsem_write)(&tsm_rwsem);
>   	conflict = provider.ops;
>   	if (conflict) {
> @@ -372,7 +366,6 @@ int tsm_register(const struct tsm_ops *ops, void *priv,
>   
>   	provider.ops = ops;
>   	provider.data = priv;
> -	provider.type = type;
>   	return 0;
>   }
>   EXPORT_SYMBOL_GPL(tsm_register);
> @@ -384,7 +377,6 @@ int tsm_unregister(const struct tsm_ops *ops)
>   		return -EBUSY;
>   	provider.ops = NULL;
>   	provider.data = NULL;
> -	provider.type = NULL;
>   	return 0;
>   }
>   EXPORT_SYMBOL_GPL(tsm_unregister);
> diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
> index 18677cd4e62f..213e88f4cec2 100644
> --- a/fs/configfs/dir.c
> +++ b/fs/configfs/dir.c
> @@ -580,6 +580,7 @@ static void detach_attrs(struct config_item * item)
>   static int populate_attrs(struct config_item *item)
>   {
>   	const struct config_item_type *t = item->ci_type;
> +	struct configfs_group_operations *ops = t->ct_group_ops;
>   	struct configfs_attribute *attr;
>   	struct configfs_bin_attribute *bin_attr;
>   	int error = 0;
> @@ -589,12 +590,17 @@ static int populate_attrs(struct config_item *item)
>   		return -EINVAL;
>   	if (t->ct_attrs) {
>   		for (i = 0; (attr = t->ct_attrs[i]) != NULL; i++) {
> +			if (ops && ops->is_visible && !ops->is_visible(attr, i))
> +				continue;
>   			if ((error = configfs_create_file(item, attr)))
>   				break;
>   		}
>   	}
>   	if (t->ct_bin_attrs) {
>   		for (i = 0; (bin_attr = t->ct_bin_attrs[i]) != NULL; i++) {
> +			if (ops && ops->is_bin_visible &&
> +			    !ops->is_bin_visible(bin_attr, i))
> +				continue;
>   			error = configfs_create_bin_file(item, bin_attr);
>   			if (error)
>   				break;
> diff --git a/fs/configfs/file.c b/fs/configfs/file.c
> index 0ad32150611e..356d23b6b9cf 100644
> --- a/fs/configfs/file.c
> +++ b/fs/configfs/file.c
> @@ -444,7 +444,8 @@ const struct file_operations configfs_bin_file_operations = {
>    *	@attr:	atrribute descriptor.
>    */
>   
> -int configfs_create_file(struct config_item * item, const struct configfs_attribute * attr)
> +int configfs_create_file(struct config_item *item,
> +			 const struct configfs_attribute *attr)
>   {
>   	struct dentry *dir = item->ci_dentry;
>   	struct configfs_dirent *parent_sd = dir->d_fsdata;
> diff --git a/include/linux/configfs.h b/include/linux/configfs.h
> index 2606711adb18..31553f12db7c 100644
> --- a/include/linux/configfs.h
> +++ b/include/linux/configfs.h
> @@ -216,6 +216,8 @@ struct configfs_group_operations {
>   	struct config_group *(*make_group)(struct config_group *group, const char *name);
>   	void (*disconnect_notify)(struct config_group *group, struct config_item *item);
>   	void (*drop_item)(struct config_group *group, struct config_item *item);
> +	bool (*is_visible)(struct configfs_attribute *attr, int n);
> +	bool (*is_bin_visible)(struct configfs_bin_attribute *attr, int n);
>   };
>   
>   struct configfs_subsystem {
> diff --git a/include/linux/tsm.h b/include/linux/tsm.h
> index de8324a2223c..a45b12943223 100644
> --- a/include/linux/tsm.h
> +++ b/include/linux/tsm.h
> @@ -42,6 +42,19 @@ struct tsm_report {
>   	u8 *auxblob;
>   };
>   
> +enum tsm_attr_index {
> +	TSM_REPORT_GENERATION,
> +	TSM_REPORT_PROVIDER,
> +	TSM_REPORT_PRIVLEVEL,
> +	TSM_REPORT_PRIVLEVEL_FLOOR,
> +};
> +
> +enum tsm_bin_attr_index {
> +	TSM_REPORT_INBLOB,
> +	TSM_REPORT_OUTBLOB,
> +	TSM_REPORT_AUXBLOB,
> +};
> +
>   /**
>    * struct tsm_ops - attributes and operations for tsm instances
>    * @name: tsm id reflected in /sys/kernel/config/tsm/report/$report/provider
> @@ -55,15 +68,11 @@ struct tsm_report {
>   struct tsm_ops {
>   	const char *name;
>   	const unsigned int privlevel_floor;
> +	bool (*is_visible)(enum tsm_attr_index index);
> +	bool (*is_bin_visible)(enum tsm_bin_attr_index index);
>   	int (*report_new)(struct tsm_report *report, void *data);
>   };
>   
> -extern const struct config_item_type tsm_report_default_type;
> -
> -/* publish @privlevel, @privlevel_floor, and @auxblob attributes */
> -extern const struct config_item_type tsm_report_extra_type;
> -
> -int tsm_register(const struct tsm_ops *ops, void *priv,
> -		 const struct config_item_type *type);
> +int tsm_register(const struct tsm_ops *ops, void *priv);
>   int tsm_unregister(const struct tsm_ops *ops);
>   #endif /* __TSM_H */

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

* Re: [PATCH v3 12/14] fs/configfs: Add a callback to determine attribute visibility
  2024-04-16 19:54         ` Tom Lendacky
@ 2024-04-16 20:03           ` Dan Williams
  0 siblings, 0 replies; 61+ messages in thread
From: Dan Williams @ 2024-04-16 20:03 UTC (permalink / raw)
  To: Tom Lendacky, Dan Williams, linux-kernel, x86, linux-coco, svsm-devel
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
	Ashish Kalra, Joel Becker, Christoph Hellwig

Tom Lendacky wrote:
> On 4/16/24 13:25, Dan Williams wrote:
> > Tom Lendacky wrote:
> >> On 4/16/24 00:46, Dan Williams wrote:
> >>> Tom Lendacky wrote:
> >>>> In order to support dynamic decisions as to whether an attribute should be
> >>>> created, add a callback that returns a bool to indicate whether the
> >>>> attribute should be display. If no callback is registered, the attribute
> > [..]
> >>>> Cc: Joel Becker <jlbec@evilplan.org>
> >>>> Cc: Christoph Hellwig <hch@lst.de>
> >>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> >>>> ---
> >>>>    fs/configfs/file.c       |   7 +++
> >>>>    include/linux/configfs.h | 111 +++++++++++++++++++++++++++------------
> >>>>    2 files changed, 84 insertions(+), 34 deletions(-)
> >>>>
> > [..]
> >>>> diff --git a/include/linux/configfs.h b/include/linux/configfs.h
> >>>> index 2606711adb18..c836d7bc7c9e 100644
> >>>> --- a/include/linux/configfs.h
> >>>> +++ b/include/linux/configfs.h
> >>>> @@ -116,35 +116,57 @@ struct configfs_attribute {
> >>>>    	const char		*ca_name;
> >>>>    	struct module 		*ca_owner;
> >>>>    	umode_t			ca_mode;
> >>>> +	bool (*is_visible)(const struct config_item *, const struct configfs_attribute *);
> >>>>    	ssize_t (*show)(struct config_item *, char *);
> >>>>    	ssize_t (*store)(struct config_item *, const char *, size_t);
> >>>>    };
> >>>>    
> >>>> -#define CONFIGFS_ATTR(_pfx, _name)			\
> >>>> +#define __CONFIGFS_ATTR(_pfx, _name, _vis)		\
> >>>>    static struct configfs_attribute _pfx##attr_##_name = {	\
> >>>>    	.ca_name	= __stringify(_name),		\
> >>>>    	.ca_mode	= S_IRUGO | S_IWUSR,		\
> >>>>    	.ca_owner	= THIS_MODULE,			\
> >>>> +	.is_visible	= _vis,				\
> >>>>    	.show		= _pfx##_name##_show,		\
> >>>>    	.store		= _pfx##_name##_store,		\
> >>>
> >>> Shouldn't this operation live in configfs_group_operations? That would
> >>> mirror the sysfs organization, and likely saves some memory.
> >>
> >> I suppose it can, but then you lose the grouping of attributes within
> >> the same directory, right? A configfs group will result in moving the
> >> entries into a subdirectory, right? If we go with the group level, then
> >> we will be moving the existing TSM extra attributes and the new TSM SVSM
> >> attributes into new, separate sub-directories.
> > 
> > I am not following the concern about "losing the grouping"? Here is what
> > I was thinking with having the visibility routines in group operations.
> > This is just the broard strokes, it compiles, but still needs the finer
> > detail work to make tdx-guest skip all the attributes that do not apply
> > to it.  Might need to be broken up a bit more, but hopefully conveys the
> > idea. Does this address your grouping concern?
> 
> Yes and no. Basically the is_visible()/is_bin_visible() callback will 
> have to check every index value for a "group" against the passed in 
> value. I was trying to group the values together using an enum in order 
> to make it a bit easier and more readable in the callback. Adding 
> another attribute to the group requires updates in multiple places. But 
> thats just how I was looking at it. I can also see where you might want 
> to selectively hide/show entries and this method works well for that.
> 
> I'll follow this approach (add you as Co-developed-by: or Suggested-by:, 
> whichever you prefer) and submit a v4.

Sure, you can add:

Co-developed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

...if you want to reuse any of this sample patch.

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

* Re: [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic
  2024-03-25 22:26 ` [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic Tom Lendacky
  2024-04-12 16:41   ` Gupta, Pankaj
@ 2024-04-17 11:46   ` Borislav Petkov
  2024-04-17 20:35     ` Tom Lendacky
  1 sibling, 1 reply; 61+ messages in thread
From: Borislav Petkov @ 2024-04-17 11:46 UTC (permalink / raw)
  To: Tom Lendacky
  Cc: linux-kernel, x86, linux-coco, svsm-devel, Thomas Gleixner,
	Ingo Molnar, Dave Hansen, H. Peter Anvin, Andy Lutomirski,
	Peter Zijlstra, Dan Williams, Michael Roth, Ashish Kalra

On Mon, Mar 25, 2024 at 05:26:21PM -0500, Tom Lendacky wrote:
> -static void enforce_vmpl0(void)
> +static bool running_at_vmpl0(void *va)

Not too crazy about it: you're turning it into a function which runs in
boolean context but takes a void *?!

And the boolean result is only a side-effect or what it does to the
argument - modify its permissions. Which is weird and not really
obvious.

I'd prefer it if you made it into

static void vmpl0_modify_permissions(void *va)

which basically says, modify the permissions of @va in vmpl0, which is
a lot closer to what the function does.

And then do

#define running_at_vmpl0(va)	vmpl0_modify_permissions((va))

because then through the indirection is at least clear how that "am
I running at VMPL0?" check is being done.

And later, if we need other VMPLs, we can extend
vmpl0_modify_permissions() and even do a more generic

vmpl_modify_permissions(unsigned int vmpl_level, void *va)

and so on and kill the silly macro.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

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

* Re: [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic
  2024-04-17 11:46   ` Borislav Petkov
@ 2024-04-17 20:35     ` Tom Lendacky
  2024-04-17 20:50       ` Borislav Petkov
  0 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-04-17 20:35 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: linux-kernel, x86, linux-coco, svsm-devel, Thomas Gleixner,
	Ingo Molnar, Dave Hansen, H. Peter Anvin, Andy Lutomirski,
	Peter Zijlstra, Dan Williams, Michael Roth, Ashish Kalra

On 4/17/24 06:46, Borislav Petkov wrote:
> On Mon, Mar 25, 2024 at 05:26:21PM -0500, Tom Lendacky wrote:
>> -static void enforce_vmpl0(void)
>> +static bool running_at_vmpl0(void *va)
> 
> Not too crazy about it: you're turning it into a function which runs in
> boolean context but takes a void *?!
> 
> And the boolean result is only a side-effect or what it does to the
> argument - modify its permissions. Which is weird and not really
> obvious.

Well, it doesn't really modify any permissions that matter. It tries to 
change the permission of a lesser privileged VMPL level. Since the 
kernel only runs at a single VMPL it would never be effected. The 
operation performed here is to update VMPL1 permission levels (which can 
only be done successfully at VMPL0) and return the result of the 
operation. A success implies running at VMPL0 and failure implies not 
running at VMPL0.

> 
> I'd prefer it if you made it into
> 
> static void vmpl0_modify_permissions(void *va)

I guess this confuses me, since it sounds like you're trying to modify 
the VMPL0 permissions, which you can't do. Maybe calling it 
modify_vmpl1_permissions() would be better. And a void return doesn't 
tell me whether it was successful and, therefore, whether the kernel is 
running at VMPL0.

Thanks,
Tom

> 
> which basically says, modify the permissions of @va in vmpl0, which is
> a lot closer to what the function does.
> 
> And then do
> 
> #define running_at_vmpl0(va)	vmpl0_modify_permissions((va))
> 
> because then through the indirection is at least clear how that "am
> I running at VMPL0?" check is being done.
> 
> And later, if we need other VMPLs, we can extend
> vmpl0_modify_permissions() and even do a more generic
> 
> vmpl_modify_permissions(unsigned int vmpl_level, void *va)
> 
> and so on and kill the silly macro.
> 
> Thx.
> 

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

* Re: [PATCH v3 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page
  2024-03-25 22:26 ` [PATCH v3 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page Tom Lendacky
  2024-04-12 17:03   ` Gupta, Pankaj
@ 2024-04-17 20:40   ` Borislav Petkov
  2024-04-18 21:17     ` Tom Lendacky
  1 sibling, 1 reply; 61+ messages in thread
From: Borislav Petkov @ 2024-04-17 20:40 UTC (permalink / raw)
  To: Tom Lendacky
  Cc: linux-kernel, x86, linux-coco, svsm-devel, Thomas Gleixner,
	Ingo Molnar, Dave Hansen, H. Peter Anvin, Andy Lutomirski,
	Peter Zijlstra, Dan Williams, Michael Roth, Ashish Kalra

On Mon, Mar 25, 2024 at 05:26:22PM -0500, Tom Lendacky wrote:
> During early boot phases, check for the presence of an SVSM when running
> as an SEV-SNP guest.
> 
> An SVSM is present if the 64-bit value at offset 0x148 into the secrets
> page is non-zero. If an SVSM is present, save the SVSM Calling Area
> address (CAA), located at offset 0x150 into the secrets page, and set
> the VMPL level of the guest, which should be non-zero, to indicate the
> presence of an SVSM.

Where are we pointing to the SVSM spec?

This is in the 0th message

https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf

but pls add it to our documentation here:

Documentation/arch/x86/amd-memory-encryption.rst

> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
>  arch/x86/boot/compressed/sev.c    | 35 ++++++++---------
>  arch/x86/include/asm/sev-common.h |  4 ++
>  arch/x86/include/asm/sev.h        | 25 +++++++++++-
>  arch/x86/kernel/sev-shared.c      | 64 +++++++++++++++++++++++++++++++
>  arch/x86/kernel/sev.c             | 16 ++++++++
>  5 files changed, 125 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
> index 49dc9661176d..fe61ff630c7e 100644
> --- a/arch/x86/boot/compressed/sev.c
> +++ b/arch/x86/boot/compressed/sev.c
> @@ -12,6 +12,7 @@
>   */
>  #include "misc.h"
>  
> +#include <linux/mm.h>
>  #include <asm/bootparam.h>
>  #include <asm/pgtable_types.h>
>  #include <asm/sev.h>
> @@ -29,6 +30,15 @@
>  static struct ghcb boot_ghcb_page __aligned(PAGE_SIZE);
>  struct ghcb *boot_ghcb;
>  
> +/*
> + * SVSM related information:
> + *   When running under an SVSM, the VMPL that Linux is executing at must be
> + *   non-zero. The VMPL is therefore used to indicate the presence of an SVSM.
> + */
> +static u8 vmpl __section(".data");
> +static u64 boot_svsm_caa_pa __section(".data");
> +static struct svsm_ca *boot_svsm_caa __section(".data");

Explain what those last 2 are in comments above it pls.

>  /*
>   * SNP_FEATURES_IMPL_REQ is the mask of SNP features that will need
>   * guest side implementation for proper functioning of the guest. If any
> @@ -480,6 +472,13 @@ static bool early_snp_init(struct boot_params *bp)
>  	 */
>  	setup_cpuid_table(cc_info);
>  
> +	/*
> +	 * Record the SVSM Calling Area address (CAA) if the guest is not

			Calling Area (CA) address

> +	 * running at VMPL0. The CA will be used to communicate with the

and then you can use "CA" here.

> +	 * SVSM to perform the SVSM services.
> +	 */
> +	setup_svsm_ca(cc_info);
> +
>  	/*
>  	 * Pass run-time kernel a pointer to CC info via boot_params so EFI
>  	 * config table doesn't need to be searched again during early startup
> diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h
> index b463fcbd4b90..68a8cdf6fd6a 100644
> --- a/arch/x86/include/asm/sev-common.h
> +++ b/arch/x86/include/asm/sev-common.h
> @@ -159,6 +159,10 @@ struct snp_psc_desc {
>  #define GHCB_TERM_NOT_VMPL0		3	/* SNP guest is not running at VMPL-0 */
>  #define GHCB_TERM_CPUID			4	/* CPUID-validation failure */
>  #define GHCB_TERM_CPUID_HV		5	/* CPUID failure during hypervisor fallback */
> +#define GHCB_TERM_SECRETS_PAGE		6	/* Secrets page failure */
> +#define GHCB_TERM_NO_SVSM		7	/* SVSM is not advertised in the secrets page */
> +#define GHCB_TERM_SVSM_VMPL0		8	/* SVSM is present but has set VMPL to 0 */
> +#define GHCB_TERM_SVSM_CAA		9	/* SVSM is present but the CA is not page aligned */

"CAA" in the comment I guess. :)

> +/*
> + * Maintain the GPA of the SVSM Calling Area (CA) in order to utilize the SVSM
> + * services needed when not running in VMPL0.
> + */
> +static void __head setup_svsm_ca(const struct cc_blob_sev_info *cc_info)
> +{
> +	struct snp_secrets_page_layout *secrets_page;

Why was that thing ever called "_layout" and not simply
snp_secrets_page?

Fix it?

> +	u64 caa;
> +
> +	BUILD_BUG_ON(sizeof(*secrets_page) != PAGE_SIZE);

Put it in the header under the struct definition I guess.

> +	/*
> +	 * Use __pa() since this routine is running identity mapped when
> +	 * called, both by the decompressor code and the early kernel code.
> +	 */
> +	if (running_at_vmpl0((void *)__pa(&boot_ghcb_page)))
> +		return;
> +
> +	/*
> +	 * Not running at VMPL0, ensure everything has been properly supplied
> +	 * for running under an SVSM.
> +	 */
> +	if (!cc_info || !cc_info->secrets_phys || cc_info->secrets_len != PAGE_SIZE)
> +		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_SECRETS_PAGE);
> +
> +	secrets_page = (struct snp_secrets_page_layout *)cc_info->secrets_phys;
> +	if (!secrets_page->svsm_size)
> +		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_NO_SVSM);
> +
> +	if (!secrets_page->svsm_guest_vmpl)
> +		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_SVSM_VMPL0);
> +
> +	vmpl = secrets_page->svsm_guest_vmpl;
> +
> +	caa = secrets_page->svsm_caa;
> +	if (!PAGE_ALIGNED(caa))
> +		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_SVSM_CAA);
> +
> +	/*
> +	 * The CA is identity mapped when this routine is called, both by the
> +	 * decompressor code and the early kernel code.
> +	 */
> +	boot_svsm_caa = (struct svsm_ca *)caa;
> +	boot_svsm_caa_pa = caa;
> +}
> diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
> index b59b09c2f284..64799a04feb4 100644
> --- a/arch/x86/kernel/sev.c
> +++ b/arch/x86/kernel/sev.c
> @@ -135,6 +135,15 @@ struct ghcb_state {
>  static DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data);
>  static DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa);
>  
> +/*
> + * SVSM related information:
> + *   When running under an SVSM, the VMPL that Linux is executing at must be
> + *   non-zero. The VMPL is therefore used to indicate the presence of an SVSM.
> + */
> +static u8 vmpl __ro_after_init;
> +static struct svsm_ca *boot_svsm_caa __ro_after_init;
> +static u64 boot_svsm_caa_pa __ro_after_init;

Uff, duplication.

Let's put them in sev-shared.c pls and avoid that.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

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

* Re: [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic
  2024-04-17 20:35     ` Tom Lendacky
@ 2024-04-17 20:50       ` Borislav Petkov
  2024-04-18 18:38         ` Tom Lendacky
  0 siblings, 1 reply; 61+ messages in thread
From: Borislav Petkov @ 2024-04-17 20:50 UTC (permalink / raw)
  To: Tom Lendacky
  Cc: linux-kernel, x86, linux-coco, svsm-devel, Thomas Gleixner,
	Ingo Molnar, Dave Hansen, H. Peter Anvin, Andy Lutomirski,
	Peter Zijlstra, Dan Williams, Michael Roth, Ashish Kalra

On Wed, Apr 17, 2024 at 03:35:53PM -0500, Tom Lendacky wrote:
> Well, it doesn't really modify any permissions that matter. It tries to
> change the permission of a lesser privileged VMPL level.

Potato potato. :-P

> Since the kernel only runs at a single VMPL it would never be
> effected. The operation performed here is to update VMPL1 permission
> levels (which can only be done successfully at VMPL0) and return the
> result of the operation.  A success implies running at VMPL0 and
> failure implies not running at VMPL0.

Yap.

The point is, it is calling RMPADJUST. And it does modify RMP
permissions of a guest page.

Thus, if you prefer, you can go all out and call the helper

	rmp_adjust_permissions(unsigned int tgt_vmpl, void *pa)

and make it generic from the get-go.

And then have the macro wrap around it in order to explain that
particular use with the macro name.

If it is still not clear what I mean, lemme know and I'll do a diff
ontop.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

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

* Re: [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic
  2024-04-17 20:50       ` Borislav Petkov
@ 2024-04-18 18:38         ` Tom Lendacky
  2024-04-21  7:12           ` Borislav Petkov
  0 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-04-18 18:38 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: linux-kernel, x86, linux-coco, svsm-devel, Thomas Gleixner,
	Ingo Molnar, Dave Hansen, H. Peter Anvin, Andy Lutomirski,
	Peter Zijlstra, Dan Williams, Michael Roth, Ashish Kalra

On 4/17/24 15:50, Borislav Petkov wrote:
> On Wed, Apr 17, 2024 at 03:35:53PM -0500, Tom Lendacky wrote:
> 
> Yap.
> 
> The point is, it is calling RMPADJUST. And it does modify RMP
> permissions of a guest page.
> 
> Thus, if you prefer, you can go all out and call the helper
> 
> 	rmp_adjust_permissions(unsigned int tgt_vmpl, void *pa)
> 
> and make it generic from the get-go.

I think I'll just eliminate the function then and call rmpadjust directly, 
that should make it clear.

Thanks,
Tom

> 
> And then have the macro wrap around it in order to explain that
> particular use with the macro name.
> 
> If it is still not clear what I mean, lemme know and I'll do a diff
> ontop.
> 
> Thx.
> 

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

* Re: [PATCH v3 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page
  2024-04-17 20:40   ` Borislav Petkov
@ 2024-04-18 21:17     ` Tom Lendacky
  2024-04-22 22:07       ` Borislav Petkov
  0 siblings, 1 reply; 61+ messages in thread
From: Tom Lendacky @ 2024-04-18 21:17 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: linux-kernel, x86, linux-coco, svsm-devel, Thomas Gleixner,
	Ingo Molnar, Dave Hansen, H. Peter Anvin, Andy Lutomirski,
	Peter Zijlstra, Dan Williams, Michael Roth, Ashish Kalra

On 4/17/24 15:40, Borislav Petkov wrote:
> On Mon, Mar 25, 2024 at 05:26:22PM -0500, Tom Lendacky wrote:
>> During early boot phases, check for the presence of an SVSM when running
>> as an SEV-SNP guest.
>>
>> An SVSM is present if the 64-bit value at offset 0x148 into the secrets
>> page is non-zero. If an SVSM is present, save the SVSM Calling Area
>> address (CAA), located at offset 0x150 into the secrets page, and set
>> the VMPL level of the guest, which should be non-zero, to indicate the
>> presence of an SVSM.
> 
> Where are we pointing to the SVSM spec?
> 
> This is in the 0th message
> 
> https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
> 
> but pls add it to our documentation here:
> 
> Documentation/arch/x86/amd-memory-encryption.rst

Do you want it added as a in this patch or in a documentation patch at the 
end of the series?

> 
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>>   arch/x86/boot/compressed/sev.c    | 35 ++++++++---------
>>   arch/x86/include/asm/sev-common.h |  4 ++
>>   arch/x86/include/asm/sev.h        | 25 +++++++++++-
>>   arch/x86/kernel/sev-shared.c      | 64 +++++++++++++++++++++++++++++++
>>   arch/x86/kernel/sev.c             | 16 ++++++++
>>   5 files changed, 125 insertions(+), 19 deletions(-)
>>
>> diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
>> index 49dc9661176d..fe61ff630c7e 100644
>> --- a/arch/x86/boot/compressed/sev.c
>> +++ b/arch/x86/boot/compressed/sev.c
>> @@ -12,6 +12,7 @@
>>    */
>>   #include "misc.h"
>>   
>> +#include <linux/mm.h>
>>   #include <asm/bootparam.h>
>>   #include <asm/pgtable_types.h>
>>   #include <asm/sev.h>
>> @@ -29,6 +30,15 @@
>>   static struct ghcb boot_ghcb_page __aligned(PAGE_SIZE);
>>   struct ghcb *boot_ghcb;
>>   
>> +/*
>> + * SVSM related information:
>> + *   When running under an SVSM, the VMPL that Linux is executing at must be
>> + *   non-zero. The VMPL is therefore used to indicate the presence of an SVSM.
>> + */
>> +static u8 vmpl __section(".data");
>> +static u64 boot_svsm_caa_pa __section(".data");
>> +static struct svsm_ca *boot_svsm_caa __section(".data");
> 
> Explain what those last 2 are in comments above it pls.

Will do.

> 
>>   /*
>>    * SNP_FEATURES_IMPL_REQ is the mask of SNP features that will need
>>    * guest side implementation for proper functioning of the guest. If any
>> @@ -480,6 +472,13 @@ static bool early_snp_init(struct boot_params *bp)
>>   	 */
>>   	setup_cpuid_table(cc_info);
>>   
>> +	/*
>> +	 * Record the SVSM Calling Area address (CAA) if the guest is not
> 
> 			Calling Area (CA) address
> 
>> +	 * running at VMPL0. The CA will be used to communicate with the
> 
> and then you can use "CA" here.

Will do.

> 
>> +	 * SVSM to perform the SVSM services.
>> +	 */
>> +	setup_svsm_ca(cc_info);
>> +
>>   	/*
>>   	 * Pass run-time kernel a pointer to CC info via boot_params so EFI
>>   	 * config table doesn't need to be searched again during early startup
>> diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h
>> index b463fcbd4b90..68a8cdf6fd6a 100644
>> --- a/arch/x86/include/asm/sev-common.h
>> +++ b/arch/x86/include/asm/sev-common.h
>> @@ -159,6 +159,10 @@ struct snp_psc_desc {
>>   #define GHCB_TERM_NOT_VMPL0		3	/* SNP guest is not running at VMPL-0 */
>>   #define GHCB_TERM_CPUID			4	/* CPUID-validation failure */
>>   #define GHCB_TERM_CPUID_HV		5	/* CPUID failure during hypervisor fallback */
>> +#define GHCB_TERM_SECRETS_PAGE		6	/* Secrets page failure */
>> +#define GHCB_TERM_NO_SVSM		7	/* SVSM is not advertised in the secrets page */
>> +#define GHCB_TERM_SVSM_VMPL0		8	/* SVSM is present but has set VMPL to 0 */
>> +#define GHCB_TERM_SVSM_CAA		9	/* SVSM is present but the CA is not page aligned */
> 
> "CAA" in the comment I guess. :)

Will do.

> 
>> +/*
>> + * Maintain the GPA of the SVSM Calling Area (CA) in order to utilize the SVSM
>> + * services needed when not running in VMPL0.
>> + */
>> +static void __head setup_svsm_ca(const struct cc_blob_sev_info *cc_info)
>> +{
>> +	struct snp_secrets_page_layout *secrets_page;
> 
> Why was that thing ever called "_layout" and not simply
> snp_secrets_page?
> 
> Fix it?

Sure, I can change that as a pre-patch to the series.

> 
>> +	u64 caa;
>> +
>> +	BUILD_BUG_ON(sizeof(*secrets_page) != PAGE_SIZE);
> 
> Put it in the header under the struct definition I guess.

It can't stand on it's own in the header file. I'd have to put it in a 
#define or an inline function and then use that in some code. So it's 
probably best to keep it here.

> 
>> +	/*
>> +	 * Use __pa() since this routine is running identity mapped when
>> +	 * called, both by the decompressor code and the early kernel code.
>> +	 */
>> +	if (running_at_vmpl0((void *)__pa(&boot_ghcb_page)))
>> +		return;
>> +
>> +	/*
>> +	 * Not running at VMPL0, ensure everything has been properly supplied
>> +	 * for running under an SVSM.
>> +	 */
>> +	if (!cc_info || !cc_info->secrets_phys || cc_info->secrets_len != PAGE_SIZE)
>> +		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_SECRETS_PAGE);
>> +
>> +	secrets_page = (struct snp_secrets_page_layout *)cc_info->secrets_phys;
>> +	if (!secrets_page->svsm_size)
>> +		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_NO_SVSM);
>> +
>> +	if (!secrets_page->svsm_guest_vmpl)
>> +		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_SVSM_VMPL0);
>> +
>> +	vmpl = secrets_page->svsm_guest_vmpl;
>> +
>> +	caa = secrets_page->svsm_caa;
>> +	if (!PAGE_ALIGNED(caa))
>> +		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_SVSM_CAA);
>> +
>> +	/*
>> +	 * The CA is identity mapped when this routine is called, both by the
>> +	 * decompressor code and the early kernel code.
>> +	 */
>> +	boot_svsm_caa = (struct svsm_ca *)caa;
>> +	boot_svsm_caa_pa = caa;
>> +}
>> diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
>> index b59b09c2f284..64799a04feb4 100644
>> --- a/arch/x86/kernel/sev.c
>> +++ b/arch/x86/kernel/sev.c
>> @@ -135,6 +135,15 @@ struct ghcb_state {
>>   static DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data);
>>   static DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa);
>>   
>> +/*
>> + * SVSM related information:
>> + *   When running under an SVSM, the VMPL that Linux is executing at must be
>> + *   non-zero. The VMPL is therefore used to indicate the presence of an SVSM.
>> + */
>> +static u8 vmpl __ro_after_init;
>> +static struct svsm_ca *boot_svsm_caa __ro_after_init;
>> +static u64 boot_svsm_caa_pa __ro_after_init;
> 
> Uff, duplication.
> 
> Let's put them in sev-shared.c pls and avoid that.

Ok, but it will require moving some functions after the inclusion of 
sev-shared.c and then (later) adding some advance function declarations.

Thanks,
Tom

> 
> Thx.
> 

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

* Re: [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic
  2024-04-18 18:38         ` Tom Lendacky
@ 2024-04-21  7:12           ` Borislav Petkov
  0 siblings, 0 replies; 61+ messages in thread
From: Borislav Petkov @ 2024-04-21  7:12 UTC (permalink / raw)
  To: Tom Lendacky
  Cc: linux-kernel, x86, linux-coco, svsm-devel, Thomas Gleixner,
	Ingo Molnar, Dave Hansen, H. Peter Anvin, Andy Lutomirski,
	Peter Zijlstra, Dan Williams, Michael Roth, Ashish Kalra

On Thu, Apr 18, 2024 at 01:38:49PM -0500, Tom Lendacky wrote:
> I think I'll just eliminate the function then and call rmpadjust directly,
> that should make it clear.

Your call.

However, if we're anticipating more uses around RMPADJUST like that we
might as well design the interface properly from the very beginning.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

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

* Re: [PATCH v3 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page
  2024-04-18 21:17     ` Tom Lendacky
@ 2024-04-22 22:07       ` Borislav Petkov
  0 siblings, 0 replies; 61+ messages in thread
From: Borislav Petkov @ 2024-04-22 22:07 UTC (permalink / raw)
  To: Tom Lendacky
  Cc: linux-kernel, x86, linux-coco, svsm-devel, Thomas Gleixner,
	Ingo Molnar, Dave Hansen, H. Peter Anvin, Andy Lutomirski,
	Peter Zijlstra, Dan Williams, Michael Roth, Ashish Kalra

On Thu, Apr 18, 2024 at 04:17:36PM -0500, Tom Lendacky wrote:
> Do you want it added as a in this patch or in a documentation patch at the
> end of the series?

Either way's fine.

> > Why was that thing ever called "_layout" and not simply
> > snp_secrets_page?
> > 
> > Fix it?
> 
> Sure, I can change that as a pre-patch to the series.

Ack.

> 
> > 
> > > +	u64 caa;
> > > +
> > > +	BUILD_BUG_ON(sizeof(*secrets_page) != PAGE_SIZE);
> > 
> > Put it in the header under the struct definition I guess.
> 
> It can't stand on it's own in the header file. I'd have to put it in a
> #define or an inline function and then use that in some code. So it's
> probably best to keep it here.

You can always put it in an inline function in the header to move this
macro out of the way but ok, one macro is not too nasty yet. :-)

> > Uff, duplication.
> > 
> > Let's put them in sev-shared.c pls and avoid that.
> 
> Ok, but it will require moving some functions after the inclusion of
> sev-shared.c and then (later) adding some advance function declarations.

I guess I'll have to see it.

I get the feeling that this sev-shared.c is starting to get problematic
and we have to do some dancing to get it all to work nicely.

In this particular case, those decompressor and kernel proper variables
should probably be passed explicitly to the shared function or returned
from it so that there's no "magic" fitting of the shared function
touching external variables of the same name and thus those names are
kept the same and it all becomes fragile.

IOW:

	svsm_ca = setup_svsm_ca(...);
	svsm_ca_pa = (unsigned long)svsm_ca;

or whatever needs to happen. But you get the idea...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

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

end of thread, other threads:[~2024-04-22 22:07 UTC | newest]

Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
2024-03-25 22:26 ` [PATCH v3 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file Tom Lendacky
2024-04-09 17:09   ` Borislav Petkov
2024-04-09 17:44     ` Tom Lendacky
2024-04-09 17:57       ` Borislav Petkov
2024-04-12 16:19   ` Gupta, Pankaj
2024-03-25 22:26 ` [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic Tom Lendacky
2024-04-12 16:41   ` Gupta, Pankaj
2024-04-17 11:46   ` Borislav Petkov
2024-04-17 20:35     ` Tom Lendacky
2024-04-17 20:50       ` Borislav Petkov
2024-04-18 18:38         ` Tom Lendacky
2024-04-21  7:12           ` Borislav Petkov
2024-03-25 22:26 ` [PATCH v3 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page Tom Lendacky
2024-04-12 17:03   ` Gupta, Pankaj
2024-04-17 20:40   ` Borislav Petkov
2024-04-18 21:17     ` Tom Lendacky
2024-04-22 22:07       ` Borislav Petkov
2024-03-25 22:26 ` [PATCH v3 04/14] x86/sev: Use kernel provided SVSM Calling Areas Tom Lendacky
2024-04-12 16:04   ` Gupta, Pankaj
2024-03-25 22:26 ` [PATCH v3 05/14] x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0 Tom Lendacky
2024-03-25 22:26 ` [PATCH v3 06/14] x86/sev: Use the SVSM to create a vCPU when not in VMPL0 Tom Lendacky
2024-04-12 15:28   ` Gupta, Pankaj
2024-03-25 22:26 ` [PATCH v3 07/14] x86/sev: Provide SVSM discovery support Tom Lendacky
2024-04-15 16:12   ` Gupta, Pankaj
2024-03-25 22:26 ` [PATCH v3 08/14] x86/sev: Provide guest VMPL level to userspace Tom Lendacky
2024-03-25 22:26 ` [PATCH v3 09/14] virt: sev-guest: Choose the VMPCK key based on executing VMPL Tom Lendacky
2024-04-16  4:54   ` Dan Williams
2024-04-16 15:17     ` Tom Lendacky
2024-04-16 15:47       ` Dan Williams
2024-03-25 22:26 ` [PATCH v3 10/14] configfs-tsm: Allow the privlevel_floor attribute to be updated Tom Lendacky
2024-04-16  4:55   ` Dan Williams
2024-04-16 15:23     ` Tom Lendacky
2024-04-16 15:57       ` Dan Williams
2024-04-16 16:17         ` Tom Lendacky
2024-03-25 22:26 ` [PATCH v3 11/14] x86/sev: Extend the config-fs attestation support for an SVSM Tom Lendacky
2024-04-16  5:37   ` Dan Williams
2024-04-16 15:53     ` Tom Lendacky
2024-04-16 16:19       ` Dan Williams
2024-03-25 22:26 ` [PATCH v3 12/14] fs/configfs: Add a callback to determine attribute visibility Tom Lendacky
2024-04-16  5:46   ` Dan Williams
2024-04-16 16:01     ` Tom Lendacky
2024-04-16 18:25       ` Dan Williams
2024-04-16 19:54         ` Tom Lendacky
2024-04-16 20:03           ` Dan Williams
2024-03-25 22:26 ` [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM Tom Lendacky
2024-04-09 18:12   ` Kuppuswamy Sathyanarayanan
2024-04-12 15:52     ` Tom Lendacky
2024-04-15 19:16       ` Tom Lendacky
2024-04-15 19:48         ` Kuppuswamy Sathyanarayanan
2024-04-15 20:13           ` Tom Lendacky
2024-04-15 21:50             ` Kuppuswamy Sathyanarayanan
2024-04-15 22:03               ` Tom Lendacky
2024-04-16  6:09                 ` Dan Williams
2024-04-16  6:08             ` Dan Williams
2024-04-16  6:05         ` Dan Williams
2024-04-16  5:47   ` Dan Williams
2024-04-16 16:07     ` Tom Lendacky
2024-04-16  6:03   ` Dan Williams
2024-04-16 16:10     ` Tom Lendacky
2024-03-25 22:26 ` [PATCH v3 14/14] x86/sev: Allow non-VMPL0 execution when an SVSM is present Tom Lendacky

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