* [PATCH 01/11] x86/sev: Rename snp_init() in the boot/compressed/sev.c file
2024-01-26 22:15 [PATCH 00/11] Provide SEV-SNP support for running under an SVSM Tom Lendacky
@ 2024-01-26 22:15 ` Tom Lendacky
2024-01-27 0:05 ` Dionna Amalie Glaze
2024-01-26 22:15 ` [PATCH 02/11] x86/sev: Make the VMPL0 checking function more generic Tom Lendacky
` (10 subsequent siblings)
11 siblings, 1 reply; 42+ messages in thread
From: Tom Lendacky @ 2024-01-26 22:15 UTC (permalink / raw)
To: linux-kernel, x86
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() function is local to the boot/compressed/sev.c 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 454acd7a2daf..c3030cfb6484 100644
--- a/arch/x86/boot/compressed/sev.c
+++ b/arch/x86/boot/compressed/sev.c
@@ -405,6 +405,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 snp_setup(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
*
@@ -455,7 +534,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 snp_setup() which
* loads the CPUID page and the same checks afterwards are done
* without the hypervisor and are trustworthy.
*
@@ -470,7 +549,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 = snp_setup(bp);
/* Now repeat the checks with the SNP CPUID table. */
@@ -527,85 +606,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.42.0
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH 01/11] x86/sev: Rename snp_init() in the boot/compressed/sev.c file
2024-01-26 22:15 ` [PATCH 01/11] x86/sev: Rename snp_init() in the boot/compressed/sev.c file Tom Lendacky
@ 2024-01-27 0:05 ` Dionna Amalie Glaze
2024-01-27 14:38 ` Tom Lendacky
0 siblings, 1 reply; 42+ messages in thread
From: Dionna Amalie Glaze @ 2024-01-27 0:05 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-kernel, x86, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Dan Williams, Michael Roth, Ashish Kalra
On Fri, Jan 26, 2024 at 2:16 PM Tom Lendacky <thomas.lendacky@amd.com> wrote:
>
> The snp_init() function is local to the boot/compressed/sev.c 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 454acd7a2daf..c3030cfb6484 100644
> --- a/arch/x86/boot/compressed/sev.c
> +++ b/arch/x86/boot/compressed/sev.c
> @@ -405,6 +405,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 snp_setup(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
> *
> @@ -455,7 +534,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 snp_setup() which
> * loads the CPUID page and the same checks afterwards are done
> * without the hypervisor and are trustworthy.
> *
> @@ -470,7 +549,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 = snp_setup(bp);
>
> /* Now repeat the checks with the SNP CPUID table. */
>
> @@ -527,85 +606,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;
> -}
> -
Did some kind of whitespace replacement happen accidentally? There's a
lot that isn't changed but the diff is quite big.
> void sev_prep_identity_maps(unsigned long top_level_pgt)
> {
> /*
> --
> 2.42.0
>
>
--
-Dionna Glaze, PhD (she/her)
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 01/11] x86/sev: Rename snp_init() in the boot/compressed/sev.c file
2024-01-27 0:05 ` Dionna Amalie Glaze
@ 2024-01-27 14:38 ` Tom Lendacky
0 siblings, 0 replies; 42+ messages in thread
From: Tom Lendacky @ 2024-01-27 14:38 UTC (permalink / raw)
To: Dionna Amalie Glaze
Cc: linux-kernel, x86, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Dan Williams, Michael Roth, Ashish Kalra
On 1/26/24 18:05, Dionna Amalie Glaze wrote:
> On Fri, Jan 26, 2024 at 2:16 PM Tom Lendacky <thomas.lendacky@amd.com> wrote:
>>
>> The snp_init() function is local to the boot/compressed/sev.c 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 454acd7a2daf..c3030cfb6484 100644
>> --- a/arch/x86/boot/compressed/sev.c
>> +++ b/arch/x86/boot/compressed/sev.c
>
> Did some kind of whitespace replacement happen accidentally? There's a
> lot that isn't changed but the diff is quite big.
No whitespace damage. As mentioned in the commit log, the functions were
moved within the file to avoid forward declarations.
Thanks,
Tom
>
>> void sev_prep_identity_maps(unsigned long top_level_pgt)
>> {
>> /*
>> --
>> 2.42.0
>>
>>
>
>
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 02/11] x86/sev: Make the VMPL0 checking function more generic
2024-01-26 22:15 [PATCH 00/11] Provide SEV-SNP support for running under an SVSM Tom Lendacky
2024-01-26 22:15 ` [PATCH 01/11] x86/sev: Rename snp_init() in the boot/compressed/sev.c file Tom Lendacky
@ 2024-01-26 22:15 ` Tom Lendacky
2024-01-26 22:15 ` [PATCH 03/11] x86/sev: Check for the presence of an SVSM in the SNP Secrets page Tom Lendacky
` (9 subsequent siblings)
11 siblings, 0 replies; 42+ messages in thread
From: Tom Lendacky @ 2024-01-26 22:15 UTC (permalink / raw)
To: linux-kernel, x86
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 c3030cfb6484..c44fa52d2914 100644
--- a/arch/x86/boot/compressed/sev.c
+++ b/arch/x86/boot/compressed/sev.c
@@ -327,10 +327,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
@@ -339,12 +338,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);
}
/*
@@ -580,7 +578,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.42.0
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 03/11] x86/sev: Check for the presence of an SVSM in the SNP Secrets page
2024-01-26 22:15 [PATCH 00/11] Provide SEV-SNP support for running under an SVSM Tom Lendacky
2024-01-26 22:15 ` [PATCH 01/11] x86/sev: Rename snp_init() in the boot/compressed/sev.c file Tom Lendacky
2024-01-26 22:15 ` [PATCH 02/11] x86/sev: Make the VMPL0 checking function more generic Tom Lendacky
@ 2024-01-26 22:15 ` Tom Lendacky
2024-01-26 22:15 ` [PATCH 04/11] x86/sev: Use kernel provided SVSM Calling Areas Tom Lendacky
` (8 subsequent siblings)
11 siblings, 0 replies; 42+ messages in thread
From: Tom Lendacky @ 2024-01-26 22:15 UTC (permalink / raw)
To: linux-kernel, x86
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 c44fa52d2914..5d2403914ceb 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/pgtable_types.h>
#include <asm/sev.h>
#include <asm/trapnr.h>
@@ -28,6 +29,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.
@@ -327,24 +337,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
@@ -472,6 +464,13 @@ static bool snp_setup(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 5b4a1ce3d368..207c315041ba 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -137,9 +137,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 1d24ec679915..99170f129eef 100644
--- a/arch/x86/kernel/sev-shared.c
+++ b/arch/x86/kernel/sev-shared.c
@@ -104,6 +104,24 @@ static void __noreturn 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.
*/
@@ -1170,3 +1188,49 @@ static int vmgexit_psc(struct ghcb *ghcb, struct snp_psc_desc *desc)
out:
return ret;
}
+
+/*
+ * Maintain the GPA of the SVSM Calling Area (CA) in order to utilize the SVSM
+ * services needed when not runnuing in VMPL0.
+ */
+static void __init 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 c67285824e82..7066afaa8133 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -115,6 +115,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,
@@ -2098,6 +2107,13 @@ bool __init 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.42.0
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 04/11] x86/sev: Use kernel provided SVSM Calling Areas
2024-01-26 22:15 [PATCH 00/11] Provide SEV-SNP support for running under an SVSM Tom Lendacky
` (2 preceding siblings ...)
2024-01-26 22:15 ` [PATCH 03/11] x86/sev: Check for the presence of an SVSM in the SNP Secrets page Tom Lendacky
@ 2024-01-26 22:15 ` Tom Lendacky
2024-01-27 0:45 ` Dionna Amalie Glaze
2024-01-26 22:15 ` [PATCH 05/11] x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0 Tom Lendacky
` (7 subsequent siblings)
11 siblings, 1 reply; 42+ messages in thread
From: Tom Lendacky @ 2024-01-26 22:15 UTC (permalink / raw)
To: linux-kernel, x86
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_CAA 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 | 207 +++++++++++++++++++++++++-----
arch/x86/mm/mem_encrypt_amd.c | 8 +-
6 files changed, 320 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 207c315041ba..2f1e583769fc 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -163,6 +163,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);
@@ -236,6 +266,7 @@ int snp_issue_guest_request(u64 exit_code, struct snp_req_data *input, struct sn
void snp_accept_memory(phys_addr_t start, phys_addr_t end);
u64 snp_get_unsupported_features(u64 status);
u64 sev_get_status(void);
+void __init 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) { }
@@ -264,6 +295,7 @@ static inline int snp_issue_guest_request(u64 exit_code, struct snp_req_data *in
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; }
+static inline void snp_remap_svsm_ca(void) { }
#endif
#endif
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 99170f129eef..7e9fa5d8889b 100644
--- a/arch/x86/kernel/sev-shared.c
+++ b/arch/x86/kernel/sev-shared.c
@@ -14,7 +14,9 @@
#define has_cpuflag(f) boot_cpu_has(f)
#else
#undef WARN
-#define WARN(condition, format...) (!!(condition))
+#define WARN(condition, format...) (!!(condition))
+#undef vc_forward_exception
+#define vc_forward_exception(c) panic("SNP: Hypervisor requested exception\n")
#endif
/* I/O parameters for CPUID-related helpers */
@@ -240,6 +242,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 7066afaa8133..3bd7860fbfe1 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -114,6 +114,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:
@@ -121,6 +123,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;
@@ -138,11 +141,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;
@@ -560,6 +578,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"
@@ -588,6 +633,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;
@@ -1348,6 +1429,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)
@@ -1397,6 +1490,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 */
@@ -1818,33 +1936,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));
@@ -2094,6 +2185,52 @@ static __init struct cc_blob_sev_info *find_cc_blob(struct boot_params *bp)
return cc_info;
}
+static __init 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.
+ */
+ asm volatile ("lea boot_svsm_ca_page(%%rip), %0"
+ : "=r" (pa)
+ : "p" (&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 __init snp_init(struct boot_params *bp)
{
struct cc_blob_sev_info *cc_info;
@@ -2107,12 +2244,7 @@ bool __init 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
@@ -2278,3 +2410,12 @@ static int __init snp_init_platform_device(void)
return 0;
}
device_initcall(snp_init_platform_device);
+
+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.42.0
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH 04/11] x86/sev: Use kernel provided SVSM Calling Areas
2024-01-26 22:15 ` [PATCH 04/11] x86/sev: Use kernel provided SVSM Calling Areas Tom Lendacky
@ 2024-01-27 0:45 ` Dionna Amalie Glaze
2024-01-27 14:43 ` Tom Lendacky
0 siblings, 1 reply; 42+ messages in thread
From: Dionna Amalie Glaze @ 2024-01-27 0:45 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-kernel, x86, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Dan Williams, Michael Roth, Ashish Kalra
On Fri, Jan 26, 2024 at 2:17 PM Tom Lendacky <thomas.lendacky@amd.com> 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_CAA call.
REMAP_CA, not CAA.
>
> 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 | 207 +++++++++++++++++++++++++-----
> arch/x86/mm/mem_encrypt_amd.c | 8 +-
> 6 files changed, 320 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 207c315041ba..2f1e583769fc 100644
> --- a/arch/x86/include/asm/sev.h
> +++ b/arch/x86/include/asm/sev.h
> @@ -163,6 +163,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))
Given that we should expect to see other SVSM protocols used in the
kernel, should we not have
#define SVSM_PROTOCOL_CALL(protocol, call) (((unsigned long)(protocol)
<< 32) | (call))
#define SVSM_CORE_PROTOCOL 0
#define SVSM_ATTESTATION_PROTOCOL 1
#define SVSM_VTPM_PROTOCOL 2
And then
#define SVSM_CORE_CALL(x) SVSM_PROTOCOL_CALL(SVSM_CORE_PROTOCOL, x)
or be cute and use symbol concatenation like
#define SVSM_PROTOCOL_ID(id) SVSM_##id##_PROTOCOL
#define SVSM_CALL(id, call) SVSM_PROTOCOL_CALL(SVSM_PROTOCOL_ID(id), call)
So you can just do SVSM_CALL(CORE, 0) ?
> +#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);
> @@ -236,6 +266,7 @@ int snp_issue_guest_request(u64 exit_code, struct snp_req_data *input, struct sn
> void snp_accept_memory(phys_addr_t start, phys_addr_t end);
> u64 snp_get_unsupported_features(u64 status);
> u64 sev_get_status(void);
> +void __init 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) { }
> @@ -264,6 +295,7 @@ static inline int snp_issue_guest_request(u64 exit_code, struct snp_req_data *in
> 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; }
> +static inline void snp_remap_svsm_ca(void) { }
> #endif
>
> #endif
> 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 99170f129eef..7e9fa5d8889b 100644
> --- a/arch/x86/kernel/sev-shared.c
> +++ b/arch/x86/kernel/sev-shared.c
> @@ -14,7 +14,9 @@
> #define has_cpuflag(f) boot_cpu_has(f)
> #else
> #undef WARN
> -#define WARN(condition, format...) (!!(condition))
> +#define WARN(condition, format...) (!!(condition))
> +#undef vc_forward_exception
> +#define vc_forward_exception(c) panic("SNP: Hypervisor requested exception\n")
> #endif
>
> /* I/O parameters for CPUID-related helpers */
> @@ -240,6 +242,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 7066afaa8133..3bd7860fbfe1 100644
> --- a/arch/x86/kernel/sev.c
> +++ b/arch/x86/kernel/sev.c
> @@ -114,6 +114,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:
> @@ -121,6 +123,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;
>
> @@ -138,11 +141,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;
> @@ -560,6 +578,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"
>
> @@ -588,6 +633,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;
> @@ -1348,6 +1429,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)
> @@ -1397,6 +1490,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 */
> @@ -1818,33 +1936,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));
> @@ -2094,6 +2185,52 @@ static __init struct cc_blob_sev_info *find_cc_blob(struct boot_params *bp)
> return cc_info;
> }
>
> +static __init 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
the get the -> get the
> + * RIP-relative addressing.
> + */
> + asm volatile ("lea boot_svsm_ca_page(%%rip), %0"
> + : "=r" (pa)
> + : "p" (&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 __init snp_init(struct boot_params *bp)
> {
> struct cc_blob_sev_info *cc_info;
> @@ -2107,12 +2244,7 @@ bool __init 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
> @@ -2278,3 +2410,12 @@ static int __init snp_init_platform_device(void)
> return 0;
> }
> device_initcall(snp_init_platform_device);
> +
> +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.42.0
>
>
--
-Dionna Glaze, PhD (she/her)
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 04/11] x86/sev: Use kernel provided SVSM Calling Areas
2024-01-27 0:45 ` Dionna Amalie Glaze
@ 2024-01-27 14:43 ` Tom Lendacky
0 siblings, 0 replies; 42+ messages in thread
From: Tom Lendacky @ 2024-01-27 14:43 UTC (permalink / raw)
To: Dionna Amalie Glaze
Cc: linux-kernel, x86, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Dan Williams, Michael Roth, Ashish Kalra
On 1/26/24 18:45, Dionna Amalie Glaze wrote:
> On Fri, Jan 26, 2024 at 2:17 PM Tom Lendacky <thomas.lendacky@amd.com> 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_CAA call.
>
> REMAP_CA, not CAA.
Will fix.
>
>>
>> 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 | 207 +++++++++++++++++++++++++-----
>> arch/x86/mm/mem_encrypt_amd.c | 8 +-
>> 6 files changed, 320 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
>> +
>> +#define SVSM_CORE_CALL(x) ((0ULL << 32) | (x))
>
> Given that we should expect to see other SVSM protocols used in the
> kernel, should we not have
>
> #define SVSM_PROTOCOL_CALL(protocol, call) (((unsigned long)(protocol)
> << 32) | (call))
> #define SVSM_CORE_PROTOCOL 0
> #define SVSM_ATTESTATION_PROTOCOL 1
> #define SVSM_VTPM_PROTOCOL 2
>
> And then
>
> #define SVSM_CORE_CALL(x) SVSM_PROTOCOL_CALL(SVSM_CORE_PROTOCOL, x)
>
> or be cute and use symbol concatenation like
>
> #define SVSM_PROTOCOL_ID(id) SVSM_##id##_PROTOCOL
> #define SVSM_CALL(id, call) SVSM_PROTOCOL_CALL(SVSM_PROTOCOL_ID(id), call)
>
> So you can just do SVSM_CALL(CORE, 0) ?
I thought about doing things along that line. You could do it any number
of ways, but it really just comes down to preference. I decided with just
the explicit SVSM_CORE_CALL() form.
Thanks,
Tom
>
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 05/11] x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0
2024-01-26 22:15 [PATCH 00/11] Provide SEV-SNP support for running under an SVSM Tom Lendacky
` (3 preceding siblings ...)
2024-01-26 22:15 ` [PATCH 04/11] x86/sev: Use kernel provided SVSM Calling Areas Tom Lendacky
@ 2024-01-26 22:15 ` Tom Lendacky
2024-01-27 0:59 ` Dionna Amalie Glaze
2024-01-26 22:15 ` [PATCH 06/11] x86/sev: Use the SVSM to create a vCPU when not in VMPL0 Tom Lendacky
` (6 subsequent siblings)
11 siblings, 1 reply; 42+ messages in thread
From: Tom Lendacky @ 2024-01-26 22:15 UTC (permalink / raw)
To: linux-kernel, x86
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 | 42 +++++++-
arch/x86/include/asm/sev.h | 22 +++++
arch/x86/kernel/sev-shared.c | 176 ++++++++++++++++++++++++++++++++-
arch/x86/kernel/sev.c | 25 +++--
4 files changed, 247 insertions(+), 18 deletions(-)
diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
index 5d2403914ceb..3fbb614c31e0 100644
--- a/arch/x86/boot/compressed/sev.c
+++ b/arch/x86/boot/compressed/sev.c
@@ -38,6 +38,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.
@@ -135,6 +145,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;
@@ -151,8 +179,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));
@@ -167,8 +195,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)
@@ -261,6 +289,12 @@ void sev_es_shutdown_ghcb(void)
if (!sev_es_check_cpu_features())
error("SEV-ES CPU Features missing.");
+ /*
+ * Ensure that the boot GHCB isn't used for the PVALIDATE when running
+ * under an SVSM.
+ */
+ 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 2f1e583769fc..dbd7fd041689 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -172,6 +172,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
@@ -192,6 +213,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 7e9fa5d8889b..f26e872bc5d0 100644
--- a/arch/x86/kernel/sev-shared.c
+++ b/arch/x86/kernel/sev-shared.c
@@ -81,6 +81,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)) {
@@ -1181,7 +1183,65 @@ static void __init 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;
@@ -1215,6 +1275,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 3bd7860fbfe1..2fd21090ef6b 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -161,6 +161,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;
@@ -777,7 +783,6 @@ static void early_set_pages_state(unsigned long vaddr, unsigned long paddr,
{
unsigned long paddr_end;
u64 val;
- int ret;
vaddr = vaddr & PAGE_MASK;
@@ -785,12 +790,9 @@ static void 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
@@ -812,12 +814,9 @@ static void 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.42.0
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH 05/11] x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0
2024-01-26 22:15 ` [PATCH 05/11] x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0 Tom Lendacky
@ 2024-01-27 0:59 ` Dionna Amalie Glaze
2024-01-27 15:18 ` Tom Lendacky
0 siblings, 1 reply; 42+ messages in thread
From: Dionna Amalie Glaze @ 2024-01-27 0:59 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-kernel, x86, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Dan Williams, Michael Roth, Ashish Kalra
On Fri, Jan 26, 2024 at 2:18 PM Tom Lendacky <thomas.lendacky@amd.com> wrote:
>
> 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 | 42 +++++++-
> arch/x86/include/asm/sev.h | 22 +++++
> arch/x86/kernel/sev-shared.c | 176 ++++++++++++++++++++++++++++++++-
> arch/x86/kernel/sev.c | 25 +++--
> 4 files changed, 247 insertions(+), 18 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
> index 5d2403914ceb..3fbb614c31e0 100644
> --- a/arch/x86/boot/compressed/sev.c
> +++ b/arch/x86/boot/compressed/sev.c
> @@ -38,6 +38,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.
> @@ -135,6 +145,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);
Should this loop forever or eventually give up and panic?
> +
> + return ret;
> +}
> +
> bool sev_snp_enabled(void)
> {
> return sev_status & MSR_AMD64_SEV_SNP_ENABLED;
> @@ -151,8 +179,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));
> @@ -167,8 +195,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)
> @@ -261,6 +289,12 @@ void sev_es_shutdown_ghcb(void)
> if (!sev_es_check_cpu_features())
> error("SEV-ES CPU Features missing.");
>
> + /*
> + * Ensure that the boot GHCB isn't used for the PVALIDATE when running
Why the definite article? Which PVALIDATE is this referring to?
> + * under an SVSM.
> + */
> + 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 2f1e583769fc..dbd7fd041689 100644
> --- a/arch/x86/include/asm/sev.h
> +++ b/arch/x86/include/asm/sev.h
> @@ -172,6 +172,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
> @@ -192,6 +213,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 7e9fa5d8889b..f26e872bc5d0 100644
> --- a/arch/x86/kernel/sev-shared.c
> +++ b/arch/x86/kernel/sev-shared.c
> @@ -81,6 +81,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)) {
> @@ -1181,7 +1183,65 @@ static void __init 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;
> @@ -1215,6 +1275,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 3bd7860fbfe1..2fd21090ef6b 100644
> --- a/arch/x86/kernel/sev.c
> +++ b/arch/x86/kernel/sev.c
> @@ -161,6 +161,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;
> @@ -777,7 +783,6 @@ static void early_set_pages_state(unsigned long vaddr, unsigned long paddr,
> {
> unsigned long paddr_end;
> u64 val;
> - int ret;
>
> vaddr = vaddr & PAGE_MASK;
>
> @@ -785,12 +790,9 @@ static void 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
> @@ -812,12 +814,9 @@ static void 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.42.0
>
>
--
-Dionna Glaze, PhD (she/her)
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 05/11] x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0
2024-01-27 0:59 ` Dionna Amalie Glaze
@ 2024-01-27 15:18 ` Tom Lendacky
0 siblings, 0 replies; 42+ messages in thread
From: Tom Lendacky @ 2024-01-27 15:18 UTC (permalink / raw)
To: Dionna Amalie Glaze
Cc: linux-kernel, x86, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Dan Williams, Michael Roth, Ashish Kalra
On 1/26/24 18:59, Dionna Amalie Glaze wrote:
> On Fri, Jan 26, 2024 at 2:18 PM Tom Lendacky <thomas.lendacky@amd.com> wrote:
>>
>> 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 | 42 +++++++-
>> arch/x86/include/asm/sev.h | 22 +++++
>> arch/x86/kernel/sev-shared.c | 176 ++++++++++++++++++++++++++++++++-
>> arch/x86/kernel/sev.c | 25 +++--
>> 4 files changed, 247 insertions(+), 18 deletions(-)
>>
>> diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
>> index 5d2403914ceb..3fbb614c31e0 100644
>> --- a/arch/x86/boot/compressed/sev.c
>> +++ b/arch/x86/boot/compressed/sev.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);
>
> Should this loop forever or eventually give up and panic?
The question becomes how many times before giving up. This would likely
only happen if the hypervisor is causing an issue for the SVSM, so it
would be similar to a DoS. I'm open to suggestions, though.
On a side not, that does remind that this should also be checking for
SVSM_ERR_INCOMPLETE.
>
>> void snp_set_page_private(unsigned long paddr)
>> @@ -261,6 +289,12 @@ void sev_es_shutdown_ghcb(void)
>> if (!sev_es_check_cpu_features())
>> error("SEV-ES CPU Features missing.");
>>
>> + /*
>> + * Ensure that the boot GHCB isn't used for the PVALIDATE when running
>
> Why the definite article? Which PVALIDATE is this referring to?
I'll clarify the comment, but it is specifically relates to the
set_page_encrypted() for the boot_ghcb_page that immediately follows.
Since the GHCB page is being changed to encrypted, we need to use the MSR
protocol by zeroing out the boot_ghcb variable. The comment should have
said for the Page State Change and not PVALIDATE.
Thanks,
Tom
>
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 06/11] x86/sev: Use the SVSM to create a vCPU when not in VMPL0
2024-01-26 22:15 [PATCH 00/11] Provide SEV-SNP support for running under an SVSM Tom Lendacky
` (4 preceding siblings ...)
2024-01-26 22:15 ` [PATCH 05/11] x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0 Tom Lendacky
@ 2024-01-26 22:15 ` Tom Lendacky
2024-01-26 22:16 ` [PATCH 07/11] x86/sev: Provide SVSM discovery support Tom Lendacky
` (5 subsequent siblings)
11 siblings, 0 replies; 42+ messages in thread
From: Tom Lendacky @ 2024-01-26 22:15 UTC (permalink / raw)
To: linux-kernel, x86
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 dbd7fd041689..372bc6183b29 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -214,6 +214,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 2fd21090ef6b..ddb9141f0959 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -995,7 +995,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;
@@ -1013,6 +1013,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)
@@ -1044,11 +1078,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
@@ -1059,6 +1093,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;
@@ -1105,6 +1140,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;
@@ -1152,11 +1193,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);
@@ -1172,7 +1213,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));
@@ -1190,13 +1234,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.42.0
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 07/11] x86/sev: Provide SVSM discovery support
2024-01-26 22:15 [PATCH 00/11] Provide SEV-SNP support for running under an SVSM Tom Lendacky
` (5 preceding siblings ...)
2024-01-26 22:15 ` [PATCH 06/11] x86/sev: Use the SVSM to create a vCPU when not in VMPL0 Tom Lendacky
@ 2024-01-26 22:16 ` Tom Lendacky
2024-01-29 10:41 ` Jeremi Piotrowski
2024-01-26 22:16 ` [PATCH 08/11] x86/sev: Provide guest VMPL level to userspace Tom Lendacky
` (4 subsequent siblings)
11 siblings, 1 reply; 42+ messages in thread
From: Tom Lendacky @ 2024-01-26 22:16 UTC (permalink / raw)
To: linux-kernel, x86
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 #VC handler of an SEV-SNP guest should modify
the returned value in the EAX register for the 0x8000001f CPUID function
by setting bit 28 when an SVSM is present.
For the MSR support, 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/msr-index.h | 2 ++
arch/x86/kernel/sev-shared.c | 4 ++++
arch/x86/kernel/sev.c | 17 +++++++++++++++++
3 files changed, 23 insertions(+)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index f1bd7b91b3c6..4746135cbe21 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -622,6 +622,8 @@
#define MSR_AMD64_VIRT_SPEC_CTRL 0xc001011f
+#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 f26e872bc5d0..9bd7d7e75b31 100644
--- a/arch/x86/kernel/sev-shared.c
+++ b/arch/x86/kernel/sev-shared.c
@@ -628,6 +628,10 @@ static int snp_cpuid_postprocess(struct ghcb *ghcb, struct es_em_ctxt *ctxt,
/* node ID */
leaf->ecx = (leaf->ecx & GENMASK(31, 8)) | (leaf_hv.ecx & GENMASK(7, 0));
break;
+ case 0x8000001f:
+ if (vmpl)
+ leaf->eax |= BIT(28);
+ break;
default:
/* No fix-ups needed, use values as-is. */
break;
diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index ddb9141f0959..121a9bad86c9 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -1326,12 +1326,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.42.0
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH 07/11] x86/sev: Provide SVSM discovery support
2024-01-26 22:16 ` [PATCH 07/11] x86/sev: Provide SVSM discovery support Tom Lendacky
@ 2024-01-29 10:41 ` Jeremi Piotrowski
2024-01-29 15:18 ` Tom Lendacky
0 siblings, 1 reply; 42+ messages in thread
From: Jeremi Piotrowski @ 2024-01-29 10:41 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-kernel, x86, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Dan Williams, Michael Roth, Ashish Kalra
On Fri, Jan 26, 2024 at 04:16:00PM -0600, 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 #VC handler of an SEV-SNP guest should modify
> the returned value in the EAX register for the 0x8000001f CPUID function
> by setting bit 28 when an SVSM is present.
>
It seems awkward that the guest would have to set the bit in the CPUID response
itself. Is there no way for the SVSM to fixup the CPUID page contents, or the
CPUID instruction return?
Could you also add a definition for the feature to arch/x86/include/asm/cpufeatures.h.
> For the MSR support, 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/msr-index.h | 2 ++
> arch/x86/kernel/sev-shared.c | 4 ++++
> arch/x86/kernel/sev.c | 17 +++++++++++++++++
> 3 files changed, 23 insertions(+)
>
> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> index f1bd7b91b3c6..4746135cbe21 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -622,6 +622,8 @@
>
> #define MSR_AMD64_VIRT_SPEC_CTRL 0xc001011f
>
> +#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 f26e872bc5d0..9bd7d7e75b31 100644
> --- a/arch/x86/kernel/sev-shared.c
> +++ b/arch/x86/kernel/sev-shared.c
> @@ -628,6 +628,10 @@ static int snp_cpuid_postprocess(struct ghcb *ghcb, struct es_em_ctxt *ctxt,
> /* node ID */
> leaf->ecx = (leaf->ecx & GENMASK(31, 8)) | (leaf_hv.ecx & GENMASK(7, 0));
> break;
> + case 0x8000001f:
> + if (vmpl)
> + leaf->eax |= BIT(28);
> + break;
> default:
> /* No fix-ups needed, use values as-is. */
> break;
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 07/11] x86/sev: Provide SVSM discovery support
2024-01-29 10:41 ` Jeremi Piotrowski
@ 2024-01-29 15:18 ` Tom Lendacky
0 siblings, 0 replies; 42+ messages in thread
From: Tom Lendacky @ 2024-01-29 15:18 UTC (permalink / raw)
To: Jeremi Piotrowski
Cc: linux-kernel, x86, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Dan Williams, Michael Roth, Ashish Kalra
On 1/29/24 04:41, Jeremi Piotrowski wrote:
> On Fri, Jan 26, 2024 at 04:16:00PM -0600, 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 #VC handler of an SEV-SNP guest should modify
>> the returned value in the EAX register for the 0x8000001f CPUID function
>> by setting bit 28 when an SVSM is present.
>>
>
> It seems awkward that the guest would have to set the bit in the CPUID response
> itself. Is there no way for the SVSM to fixup the CPUID page contents, or the
> CPUID instruction return?
It's possible for the SVSM to update the CPUID information provided to the
guest, but it hasn't been specifically called out as a requirement in the
SVSM spec. That is why snp_cpuid_postprocess() is used to ensure that the
bit is set. But, yes, we could update the CPUID information in the CPUID
page directly instead of the snp_cpuid_postprocess() change.
I'll look into that and see what it takes.
>
> Could you also add a definition for the feature to arch/x86/include/asm/cpufeatures.h.
Yes, I missed that, will add it.
Thanks,
Tom
>
>> For the MSR support, 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/msr-index.h | 2 ++
>> arch/x86/kernel/sev-shared.c | 4 ++++
>> arch/x86/kernel/sev.c | 17 +++++++++++++++++
>> 3 files changed, 23 insertions(+)
>>
>> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
>> index f1bd7b91b3c6..4746135cbe21 100644
>> --- a/arch/x86/include/asm/msr-index.h
>> +++ b/arch/x86/include/asm/msr-index.h
>> @@ -622,6 +622,8 @@
>>
>> #define MSR_AMD64_VIRT_SPEC_CTRL 0xc001011f
>>
>> +#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 f26e872bc5d0..9bd7d7e75b31 100644
>> --- a/arch/x86/kernel/sev-shared.c
>> +++ b/arch/x86/kernel/sev-shared.c
>> @@ -628,6 +628,10 @@ static int snp_cpuid_postprocess(struct ghcb *ghcb, struct es_em_ctxt *ctxt,
>> /* node ID */
>> leaf->ecx = (leaf->ecx & GENMASK(31, 8)) | (leaf_hv.ecx & GENMASK(7, 0));
>> break;
>> + case 0x8000001f:
>> + if (vmpl)
>> + leaf->eax |= BIT(28);
>> + break;
>> default:
>> /* No fix-ups needed, use values as-is. */
>> break;
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 08/11] x86/sev: Provide guest VMPL level to userspace
2024-01-26 22:15 [PATCH 00/11] Provide SEV-SNP support for running under an SVSM Tom Lendacky
` (6 preceding siblings ...)
2024-01-26 22:16 ` [PATCH 07/11] x86/sev: Provide SVSM discovery support Tom Lendacky
@ 2024-01-26 22:16 ` Tom Lendacky
2024-01-27 1:06 ` Dionna Amalie Glaze
2024-01-26 22:16 ` [PATCH 09/11] virt: sev-guest: Choose the VMPCK key based on executing VMPL Tom Lendacky
` (3 subsequent siblings)
11 siblings, 1 reply; 42+ messages in thread
From: Tom Lendacky @ 2024-01-26 22:16 UTC (permalink / raw)
To: linux-kernel, x86
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 121a9bad86c9..9844c772099c 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -2479,3 +2479,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.42.0
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH 08/11] x86/sev: Provide guest VMPL level to userspace
2024-01-26 22:16 ` [PATCH 08/11] x86/sev: Provide guest VMPL level to userspace Tom Lendacky
@ 2024-01-27 1:06 ` Dionna Amalie Glaze
2024-01-27 15:43 ` Tom Lendacky
0 siblings, 1 reply; 42+ messages in thread
From: Dionna Amalie Glaze @ 2024-01-27 1:06 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-kernel, x86, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Dan Williams, Michael Roth, Ashish Kalra
On Fri, Jan 26, 2024 at 2:19 PM Tom Lendacky <thomas.lendacky@amd.com> wrote:
>
> 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.
Is this not the intended meaning of privlevel_floor in
/sys/kernel/config/tsm/report/$report0/privlevel_floor?
>
> 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 121a9bad86c9..9844c772099c 100644
> --- a/arch/x86/kernel/sev.c
> +++ b/arch/x86/kernel/sev.c
> @@ -2479,3 +2479,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.42.0
>
>
--
-Dionna Glaze, PhD (she/her)
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 08/11] x86/sev: Provide guest VMPL level to userspace
2024-01-27 1:06 ` Dionna Amalie Glaze
@ 2024-01-27 15:43 ` Tom Lendacky
0 siblings, 0 replies; 42+ messages in thread
From: Tom Lendacky @ 2024-01-27 15:43 UTC (permalink / raw)
To: Dionna Amalie Glaze
Cc: linux-kernel, x86, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Dan Williams, Michael Roth, Ashish Kalra
On 1/26/24 19:06, Dionna Amalie Glaze wrote:
> On Fri, Jan 26, 2024 at 2:19 PM Tom Lendacky <thomas.lendacky@amd.com> wrote:
>>
>> 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.
>
> Is this not the intended meaning of privlevel_floor in
> /sys/kernel/config/tsm/report/$report0/privlevel_floor?
Hmmm... possibly. But that would make someone using the ioctl() (which is
still available) have to use the config-tsm support to get the value. If
the overall consensus is not to have a sysfs entry, I'll remove it, but it
could be useful beyond just attestation.
Your comment does make me realize that I did miss changing privlevel_floor
for the TSM support. I need to set privlevel_floor to the current VMPL level.
Thanks,
Tom
>
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 09/11] virt: sev-guest: Choose the VMPCK key based on executing VMPL
2024-01-26 22:15 [PATCH 00/11] Provide SEV-SNP support for running under an SVSM Tom Lendacky
` (7 preceding siblings ...)
2024-01-26 22:16 ` [PATCH 08/11] x86/sev: Provide guest VMPL level to userspace Tom Lendacky
@ 2024-01-26 22:16 ` Tom Lendacky
2024-01-26 22:16 ` [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM Tom Lendacky
` (2 subsequent siblings)
11 siblings, 0 replies; 42+ messages in thread
From: Tom Lendacky @ 2024-01-26 22:16 UTC (permalink / raw)
To: linux-kernel, x86
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 372bc6183b29..b126e50a1358 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -291,6 +291,7 @@ void snp_accept_memory(phys_addr_t start, phys_addr_t end);
u64 snp_get_unsupported_features(u64 status);
u64 sev_get_status(void);
void __init 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) { }
@@ -320,6 +321,7 @@ 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; }
static inline void snp_remap_svsm_ca(void) { }
+static inline int snp_get_vmpl(void) { return 0; }
#endif
#endif
diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index 9844c772099c..849df3aae4e1 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -2442,6 +2442,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.42.0
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
2024-01-26 22:15 [PATCH 00/11] Provide SEV-SNP support for running under an SVSM Tom Lendacky
` (8 preceding siblings ...)
2024-01-26 22:16 ` [PATCH 09/11] virt: sev-guest: Choose the VMPCK key based on executing VMPL Tom Lendacky
@ 2024-01-26 22:16 ` Tom Lendacky
2024-01-27 1:27 ` Dionna Amalie Glaze
2024-02-02 7:10 ` Dan Williams
2024-01-26 22:16 ` [PATCH 11/11] x86/sev: Allow non-VMPL0 execution when an SVSM is present Tom Lendacky
2024-02-12 10:40 ` [PATCH 00/11] Provide SEV-SNP support for running under an SVSM Reshetova, Elena
11 siblings, 2 replies; 42+ messages in thread
From: Tom Lendacky @ 2024-01-26 22:16 UTC (permalink / raw)
To: linux-kernel, x86
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:
- 'svsm' (input)
This attribute is used to determine whether the attestation request
should be sent to the SVSM or to the SEV firmware.
- 'service_guid' (input)
Used for requesting the attestation of a single service within the
SVSM. 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_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 | 55 ++++++++++
arch/x86/include/asm/sev.h | 31 +++++-
arch/x86/kernel/sev.c | 50 +++++++++
drivers/virt/coco/sev-guest/sev-guest.c | 137 ++++++++++++++++++++++++
drivers/virt/coco/tsm.c | 95 +++++++++++++++-
include/linux/tsm.h | 11 ++
6 files changed, 376 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
index dd24202b5ba5..c5423987d323 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.9
+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 "svsm" attribute is set
+ this file contains the service manifest used for the SVSM
+ attestation report from 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,43 @@ 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/svsm
+Date: January, 2024
+KernelVersion: v6.9
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports for TVMs running
+ under an SVSM, like SEV-SNP. Specifying any non-zero value
+ implies that the attestation report should come from the SVSM.
+ 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.9
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports for TVMs running
+ under an SVSM, like SEV-SNP. Specifying a empty or null GUID
+ (00000000-0000-0000-0000-000000) requests all active services
+ within the SVSM be part of the attestation report. Specifying
+ a non-null GUID requests an attestation report of just the
+ specified service using the manifest form specified by the
+ service_version attribute.
+ 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_version
+Date: January, 2024
+KernelVersion: v6.9
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports for TVMs running
+ under an SVSM, like SEV-SNP. Indicates the service manifest
+ version requested for the attestation report.
+ 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 b126e50a1358..4cafa92d1d3e 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -194,6 +194,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_version;
+ u8 rsvd[4];
+};
+
/*
* SVSM protocol structure
*/
@@ -217,6 +238,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);
@@ -287,6 +312,7 @@ void snp_set_wakeup_secondary_cpu(void);
bool snp_init(struct boot_params *bp);
void __init __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);
@@ -316,7 +342,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 849df3aae4e1..83bc5efa8fcf 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -2378,6 +2378,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);
+
+ memcpy(attest_call, input, sizeof(*attest_call));
+
+ /*
+ * 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 1ff897913bf4..3693373c4227 100644
--- a/drivers/virt/coco/sev-guest/sev-guest.c
+++ b/drivers/virt/coco/sev-guest/sev-guest.c
@@ -783,6 +783,140 @@ 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 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;
+
+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;
+
+ 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_version = desc->service_version;
+
+ call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SINGLE_SERVICE);
+ }
+
+ ret = snp_issue_svsm_attestation_request(call_id, &attest_call);
+ switch (ret) {
+ case SVSM_SUCCESS:
+ break;
+ case SVSM_ERR_INVALID_PARAMETER:
+ 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);
+ goto retry;
+ }
+
+ ret = -EINVAL;
+ 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 +931,9 @@ static int sev_report_new(struct tsm_report *report, void *data)
if (desc->inblob_len != SNP_REPORT_USER_DATA_SIZE)
return -EINVAL;
+ if (desc->svsm)
+ 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..33fa26406bc6 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,77 @@ static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
}
CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
+static ssize_t tsm_report_svsm_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.svsm = !!val;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, svsm);
+
+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);
+ size_t guid_len;
+ int rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+
+ /* Obtain the GUID string length */
+ guid_len = (len && buf[len - 1] == '\n') ? len - 1 : len;
+ if (guid_len && guid_len != UUID_STRING_LEN)
+ return -EINVAL;
+
+ if (guid_len == UUID_STRING_LEN) {
+ rc = guid_parse(buf, &report->desc.service_guid);
+ if (rc)
+ return rc;
+ } else {
+ report->desc.service_guid = guid_null;
+ }
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, service_guid);
+
+static ssize_t tsm_report_service_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_version = val;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, service_version);
+
static ssize_t tsm_report_inblob_write(struct config_item *cfg,
const void *buf, size_t count)
{
@@ -163,6 +235,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 +263,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 +299,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 +329,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 +351,9 @@ static struct configfs_attribute *tsm_report_extra_attrs[] = {
TSM_DEFAULT_ATTRS(),
&tsm_report_attr_privlevel,
&tsm_report_attr_privlevel_floor,
+ &tsm_report_attr_svsm,
+ &tsm_report_attr_service_guid,
+ &tsm_report_attr_service_version,
NULL,
};
@@ -280,6 +369,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,6 +378,7 @@ 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(state);
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
index de8324a2223c..7c36b8448b4f 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
+ * @svsm: optional indicator of where to obtain the tsm report blob
+ * @service_guid: optional SVSM service guid to attest
+ * @service_version: optional SVSM service manifest version requested
*/
struct tsm_desc {
unsigned int privlevel;
size_t inblob_len;
u8 inblob[TSM_INBLOB_MAX];
+ bool svsm;
+ guid_t service_guid;
+ unsigned int service_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.42.0
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
2024-01-26 22:16 ` [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM Tom Lendacky
@ 2024-01-27 1:27 ` Dionna Amalie Glaze
2024-01-29 15:02 ` Tom Lendacky
2024-02-02 7:10 ` Dan Williams
1 sibling, 1 reply; 42+ messages in thread
From: Dionna Amalie Glaze @ 2024-01-27 1:27 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-kernel, x86, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Dan Williams, Michael Roth, Ashish Kalra
On Fri, Jan 26, 2024 at 2:19 PM Tom Lendacky <thomas.lendacky@amd.com> 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:
>
> - 'svsm' (input)
> This attribute is used to determine whether the attestation request
> should be sent to the SVSM or to the SEV firmware.
This is where I'm torn. If there's an SVSM, it's there to provide
paravirtualization for unenlightened guests /or/ it's there to protect
runtime measurement registers. I don't see there being any particular
value in bifurcating the attestation report space by adding this
option. If there's an SVSM present, the configfs-tsm report should
return the full SVSM attestation only.
>
> - 'service_guid' (input)
> Used for requesting the attestation of a single service within the
> SVSM. 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_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.
I know that this is specified for the SVSM, but I still don't know
what the intended use case is such that we wouldn't simply always
return the full service manifest.
I can see an argument for an evidence requester not being ready for a
new manifest version and wanting the older version until they can
bridge the gap. I don't see that as needing configuration from the
user space. We can either require new service GUIDs for new versions,
require manifest ABIs to be internally versioned to be additive-only
to not break verifiers that understand up to manifest byte X, or we
allow breaking version changes through control plane configuration
that's passed directly to the SVSM.
New versions get new GUIDs allows for gradual deprecation at the
expense of size. I think that is a reasonable trade-off to keep from
making tsm/report vendor-specific.
>
> - 'manifestblob' (output)
> Used to return the service manifest associated with the attestation
> report.
Given the above, I think we can just append the manifest to the report
since the report size is known a priori.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> Documentation/ABI/testing/configfs-tsm | 55 ++++++++++
> arch/x86/include/asm/sev.h | 31 +++++-
> arch/x86/kernel/sev.c | 50 +++++++++
> drivers/virt/coco/sev-guest/sev-guest.c | 137 ++++++++++++++++++++++++
> drivers/virt/coco/tsm.c | 95 +++++++++++++++-
> include/linux/tsm.h | 11 ++
> 6 files changed, 376 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
> index dd24202b5ba5..c5423987d323 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.9
> +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 "svsm" attribute is set
> + this file contains the service manifest used for the SVSM
> + attestation report from 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,43 @@ 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/svsm
> +Date: January, 2024
> +KernelVersion: v6.9
> +Contact: linux-coco@lists.linux.dev
> +Description:
> + (WO) Attribute is visible if a TSM implementation provider
> + supports the concept of attestation reports for TVMs running
> + under an SVSM, like SEV-SNP. Specifying any non-zero value
> + implies that the attestation report should come from the SVSM.
> + 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.9
> +Contact: linux-coco@lists.linux.dev
> +Description:
> + (WO) Attribute is visible if a TSM implementation provider
> + supports the concept of attestation reports for TVMs running
> + under an SVSM, like SEV-SNP. Specifying a empty or null GUID
> + (00000000-0000-0000-0000-000000) requests all active services
> + within the SVSM be part of the attestation report. Specifying
> + a non-null GUID requests an attestation report of just the
> + specified service using the manifest form specified by the
> + service_version attribute.
> + 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_version
> +Date: January, 2024
> +KernelVersion: v6.9
> +Contact: linux-coco@lists.linux.dev
> +Description:
> + (WO) Attribute is visible if a TSM implementation provider
> + supports the concept of attestation reports for TVMs running
> + under an SVSM, like SEV-SNP. Indicates the service manifest
> + version requested for the attestation report.
> + 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 b126e50a1358..4cafa92d1d3e 100644
> --- a/arch/x86/include/asm/sev.h
> +++ b/arch/x86/include/asm/sev.h
> @@ -194,6 +194,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_version;
> + u8 rsvd[4];
> +};
> +
> /*
> * SVSM protocol structure
> */
> @@ -217,6 +238,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);
> @@ -287,6 +312,7 @@ void snp_set_wakeup_secondary_cpu(void);
> bool snp_init(struct boot_params *bp);
> void __init __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);
> @@ -316,7 +342,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 849df3aae4e1..83bc5efa8fcf 100644
> --- a/arch/x86/kernel/sev.c
> +++ b/arch/x86/kernel/sev.c
> @@ -2378,6 +2378,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);
> +
> + memcpy(attest_call, input, sizeof(*attest_call));
> +
> + /*
> + * 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 1ff897913bf4..3693373c4227 100644
> --- a/drivers/virt/coco/sev-guest/sev-guest.c
> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
> @@ -783,6 +783,140 @@ 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 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;
> +
> +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;
> +
> + 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_version = desc->service_version;
> +
> + call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SINGLE_SERVICE);
> + }
> +
> + ret = snp_issue_svsm_attestation_request(call_id, &attest_call);
> + switch (ret) {
> + case SVSM_SUCCESS:
> + break;
> + case SVSM_ERR_INVALID_PARAMETER:
> + 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);
> + goto retry;
> + }
> +
> + ret = -EINVAL;
> + 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 +931,9 @@ static int sev_report_new(struct tsm_report *report, void *data)
> if (desc->inblob_len != SNP_REPORT_USER_DATA_SIZE)
> return -EINVAL;
>
> + if (desc->svsm)
> + 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..33fa26406bc6 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,77 @@ static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
> }
> CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
>
> +static ssize_t tsm_report_svsm_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.svsm = !!val;
> +
> + return len;
> +}
> +CONFIGFS_ATTR_WO(tsm_report_, svsm);
> +
> +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);
> + size_t guid_len;
> + int rc;
> +
> + guard(rwsem_write)(&tsm_rwsem);
> + rc = try_advance_write_generation(report);
> + if (rc)
> + return rc;
> +
> + /* Obtain the GUID string length */
> + guid_len = (len && buf[len - 1] == '\n') ? len - 1 : len;
> + if (guid_len && guid_len != UUID_STRING_LEN)
> + return -EINVAL;
> +
> + if (guid_len == UUID_STRING_LEN) {
> + rc = guid_parse(buf, &report->desc.service_guid);
> + if (rc)
> + return rc;
> + } else {
> + report->desc.service_guid = guid_null;
> + }
> +
> + return len;
> +}
> +CONFIGFS_ATTR_WO(tsm_report_, service_guid);
> +
> +static ssize_t tsm_report_service_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_version = val;
> +
> + return len;
> +}
> +CONFIGFS_ATTR_WO(tsm_report_, service_version);
> +
> static ssize_t tsm_report_inblob_write(struct config_item *cfg,
> const void *buf, size_t count)
> {
> @@ -163,6 +235,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 +263,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 +299,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 +329,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 +351,9 @@ static struct configfs_attribute *tsm_report_extra_attrs[] = {
> TSM_DEFAULT_ATTRS(),
> &tsm_report_attr_privlevel,
> &tsm_report_attr_privlevel_floor,
> + &tsm_report_attr_svsm,
> + &tsm_report_attr_service_guid,
> + &tsm_report_attr_service_version,
> NULL,
> };
>
> @@ -280,6 +369,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,6 +378,7 @@ 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(state);
> diff --git a/include/linux/tsm.h b/include/linux/tsm.h
> index de8324a2223c..7c36b8448b4f 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
> + * @svsm: optional indicator of where to obtain the tsm report blob
> + * @service_guid: optional SVSM service guid to attest
> + * @service_version: optional SVSM service manifest version requested
> */
> struct tsm_desc {
> unsigned int privlevel;
> size_t inblob_len;
> u8 inblob[TSM_INBLOB_MAX];
> + bool svsm;
> + guid_t service_guid;
> + unsigned int service_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.42.0
>
>
--
-Dionna Glaze, PhD (she/her)
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
2024-01-27 1:27 ` Dionna Amalie Glaze
@ 2024-01-29 15:02 ` Tom Lendacky
2024-01-29 20:04 ` Dionna Amalie Glaze
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lendacky @ 2024-01-29 15:02 UTC (permalink / raw)
To: Dionna Amalie Glaze
Cc: linux-kernel, x86, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Dan Williams, Michael Roth, Ashish Kalra
On 1/26/24 19:27, Dionna Amalie Glaze wrote:
> On Fri, Jan 26, 2024 at 2:19 PM Tom Lendacky <thomas.lendacky@amd.com> 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:
>>
>> - 'svsm' (input)
>> This attribute is used to determine whether the attestation request
>> should be sent to the SVSM or to the SEV firmware.
>
> This is where I'm torn. If there's an SVSM, it's there to provide
> paravirtualization for unenlightened guests /or/ it's there to protect
An SVSM is for enlightened guests. A para-visor would be for unenlightened
guests.
> runtime measurement registers. I don't see there being any particular
> value in bifurcating the attestation report space by adding this
> option. If there's an SVSM present, the configfs-tsm report should
> return the full SVSM attestation only.
I don't necessarily agree with that. The guest should still be able to
request a traditional attestation report.
Maybe I can remove the SVSM attribute and direct the call based on
requested VMPL level. If VMPL0 is requested, it goes through the SVSM.
If VMPL1+ is requested, it goes to the ASP.
That would mean that the privlevel_floor would need to stay at zero.
>
>>
>> - 'service_guid' (input)
>> Used for requesting the attestation of a single service within the
>> SVSM. 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_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.
>
> I know that this is specified for the SVSM, but I still don't know
> what the intended use case is such that we wouldn't simply always
> return the full service manifest.
> I can see an argument for an evidence requester not being ready for a
> new manifest version and wanting the older version until they can
> bridge the gap. I don't see that as needing configuration from the
> user space. We can either require new service GUIDs for new versions,
> require manifest ABIs to be internally versioned to be additive-only
> to not break verifiers that understand up to manifest byte X, or we
> allow breaking version changes through control plane configuration
> that's passed directly to the SVSM.
>
> New versions get new GUIDs allows for gradual deprecation at the
> expense of size. I think that is a reasonable trade-off to keep from
> making tsm/report vendor-specific.
This was requested and discussed during the SVSM spec review and there
were no objections raised. See the this thread where this was discussed:
https://lore.kernel.org/linux-coco/09819cb3-1938-fe86-b948-28aaffbe584e@amd.com/
The changes you're requesting would require a new version of the spec
and updates to the protocol.
>
>>
>> - 'manifestblob' (output)
>> Used to return the service manifest associated with the attestation
>> report.
>
> Given the above, I think we can just append the manifest to the report
> since the report size is known a priori.
We could have theoretically done the same thing with the auxblob (certs
data), but that is separate. I prefer the idea of having an individual
entry per piece of data being returned.
Thanks,
Tom
>
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>> Documentation/ABI/testing/configfs-tsm | 55 ++++++++++
>> arch/x86/include/asm/sev.h | 31 +++++-
>> arch/x86/kernel/sev.c | 50 +++++++++
>> drivers/virt/coco/sev-guest/sev-guest.c | 137 ++++++++++++++++++++++++
>> drivers/virt/coco/tsm.c | 95 +++++++++++++++-
>> include/linux/tsm.h | 11 ++
>> 6 files changed, 376 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
>> index dd24202b5ba5..c5423987d323 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.9
>> +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 "svsm" attribute is set
>> + this file contains the service manifest used for the SVSM
>> + attestation report from 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,43 @@ 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/svsm
>> +Date: January, 2024
>> +KernelVersion: v6.9
>> +Contact: linux-coco@lists.linux.dev
>> +Description:
>> + (WO) Attribute is visible if a TSM implementation provider
>> + supports the concept of attestation reports for TVMs running
>> + under an SVSM, like SEV-SNP. Specifying any non-zero value
>> + implies that the attestation report should come from the SVSM.
>> + 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.9
>> +Contact: linux-coco@lists.linux.dev
>> +Description:
>> + (WO) Attribute is visible if a TSM implementation provider
>> + supports the concept of attestation reports for TVMs running
>> + under an SVSM, like SEV-SNP. Specifying a empty or null GUID
>> + (00000000-0000-0000-0000-000000) requests all active services
>> + within the SVSM be part of the attestation report. Specifying
>> + a non-null GUID requests an attestation report of just the
>> + specified service using the manifest form specified by the
>> + service_version attribute.
>> + 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_version
>> +Date: January, 2024
>> +KernelVersion: v6.9
>> +Contact: linux-coco@lists.linux.dev
>> +Description:
>> + (WO) Attribute is visible if a TSM implementation provider
>> + supports the concept of attestation reports for TVMs running
>> + under an SVSM, like SEV-SNP. Indicates the service manifest
>> + version requested for the attestation report.
>> + 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 b126e50a1358..4cafa92d1d3e 100644
>> --- a/arch/x86/include/asm/sev.h
>> +++ b/arch/x86/include/asm/sev.h
>> @@ -194,6 +194,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_version;
>> + u8 rsvd[4];
>> +};
>> +
>> /*
>> * SVSM protocol structure
>> */
>> @@ -217,6 +238,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);
>> @@ -287,6 +312,7 @@ void snp_set_wakeup_secondary_cpu(void);
>> bool snp_init(struct boot_params *bp);
>> void __init __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);
>> @@ -316,7 +342,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 849df3aae4e1..83bc5efa8fcf 100644
>> --- a/arch/x86/kernel/sev.c
>> +++ b/arch/x86/kernel/sev.c
>> @@ -2378,6 +2378,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);
>> +
>> + memcpy(attest_call, input, sizeof(*attest_call));
>> +
>> + /*
>> + * 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 1ff897913bf4..3693373c4227 100644
>> --- a/drivers/virt/coco/sev-guest/sev-guest.c
>> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
>> @@ -783,6 +783,140 @@ 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 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;
>> +
>> +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;
>> +
>> + 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_version = desc->service_version;
>> +
>> + call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SINGLE_SERVICE);
>> + }
>> +
>> + ret = snp_issue_svsm_attestation_request(call_id, &attest_call);
>> + switch (ret) {
>> + case SVSM_SUCCESS:
>> + break;
>> + case SVSM_ERR_INVALID_PARAMETER:
>> + 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);
>> + goto retry;
>> + }
>> +
>> + ret = -EINVAL;
>> + 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 +931,9 @@ static int sev_report_new(struct tsm_report *report, void *data)
>> if (desc->inblob_len != SNP_REPORT_USER_DATA_SIZE)
>> return -EINVAL;
>>
>> + if (desc->svsm)
>> + 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..33fa26406bc6 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,77 @@ static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
>> }
>> CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
>>
>> +static ssize_t tsm_report_svsm_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.svsm = !!val;
>> +
>> + return len;
>> +}
>> +CONFIGFS_ATTR_WO(tsm_report_, svsm);
>> +
>> +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);
>> + size_t guid_len;
>> + int rc;
>> +
>> + guard(rwsem_write)(&tsm_rwsem);
>> + rc = try_advance_write_generation(report);
>> + if (rc)
>> + return rc;
>> +
>> + /* Obtain the GUID string length */
>> + guid_len = (len && buf[len - 1] == '\n') ? len - 1 : len;
>> + if (guid_len && guid_len != UUID_STRING_LEN)
>> + return -EINVAL;
>> +
>> + if (guid_len == UUID_STRING_LEN) {
>> + rc = guid_parse(buf, &report->desc.service_guid);
>> + if (rc)
>> + return rc;
>> + } else {
>> + report->desc.service_guid = guid_null;
>> + }
>> +
>> + return len;
>> +}
>> +CONFIGFS_ATTR_WO(tsm_report_, service_guid);
>> +
>> +static ssize_t tsm_report_service_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_version = val;
>> +
>> + return len;
>> +}
>> +CONFIGFS_ATTR_WO(tsm_report_, service_version);
>> +
>> static ssize_t tsm_report_inblob_write(struct config_item *cfg,
>> const void *buf, size_t count)
>> {
>> @@ -163,6 +235,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 +263,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 +299,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 +329,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 +351,9 @@ static struct configfs_attribute *tsm_report_extra_attrs[] = {
>> TSM_DEFAULT_ATTRS(),
>> &tsm_report_attr_privlevel,
>> &tsm_report_attr_privlevel_floor,
>> + &tsm_report_attr_svsm,
>> + &tsm_report_attr_service_guid,
>> + &tsm_report_attr_service_version,
>> NULL,
>> };
>>
>> @@ -280,6 +369,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,6 +378,7 @@ 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(state);
>> diff --git a/include/linux/tsm.h b/include/linux/tsm.h
>> index de8324a2223c..7c36b8448b4f 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
>> + * @svsm: optional indicator of where to obtain the tsm report blob
>> + * @service_guid: optional SVSM service guid to attest
>> + * @service_version: optional SVSM service manifest version requested
>> */
>> struct tsm_desc {
>> unsigned int privlevel;
>> size_t inblob_len;
>> u8 inblob[TSM_INBLOB_MAX];
>> + bool svsm;
>> + guid_t service_guid;
>> + unsigned int service_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.42.0
>>
>>
>
>
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
2024-01-29 15:02 ` Tom Lendacky
@ 2024-01-29 20:04 ` Dionna Amalie Glaze
2024-02-01 21:14 ` Tom Lendacky
0 siblings, 1 reply; 42+ messages in thread
From: Dionna Amalie Glaze @ 2024-01-29 20:04 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-kernel, x86, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Dan Williams, Michael Roth, Ashish Kalra
On Mon, Jan 29, 2024 at 7:02 AM Tom Lendacky <thomas.lendacky@amd.com> wrote:
>
> On 1/26/24 19:27, Dionna Amalie Glaze wrote:
> > On Fri, Jan 26, 2024 at 2:19 PM Tom Lendacky <thomas.lendacky@amd.com> 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:
> >>
> >> - 'svsm' (input)
> >> This attribute is used to determine whether the attestation request
> >> should be sent to the SVSM or to the SEV firmware.
> >
> > This is where I'm torn. If there's an SVSM, it's there to provide
> > paravirtualization for unenlightened guests /or/ it's there to protect
>
> An SVSM is for enlightened guests. A para-visor would be for unenlightened
> guests.
>
> > runtime measurement registers. I don't see there being any particular
> > value in bifurcating the attestation report space by adding this
> > option. If there's an SVSM present, the configfs-tsm report should
> > return the full SVSM attestation only.
>
> I don't necessarily agree with that. The guest should still be able to
> request a traditional attestation report.
>
> Maybe I can remove the SVSM attribute and direct the call based on
> requested VMPL level. If VMPL0 is requested, it goes through the SVSM.
> If VMPL1+ is requested, it goes to the ASP.
>
> That would mean that the privlevel_floor would need to stay at zero.
>
> >
> >>
> >> - 'service_guid' (input)
> >> Used for requesting the attestation of a single service within the
> >> SVSM. 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_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.
> >
> > I know that this is specified for the SVSM, but I still don't know
> > what the intended use case is such that we wouldn't simply always
> > return the full service manifest.
> > I can see an argument for an evidence requester not being ready for a
> > new manifest version and wanting the older version until they can
> > bridge the gap. I don't see that as needing configuration from the
> > user space. We can either require new service GUIDs for new versions,
> > require manifest ABIs to be internally versioned to be additive-only
> > to not break verifiers that understand up to manifest byte X, or we
> > allow breaking version changes through control plane configuration
> > that's passed directly to the SVSM.
> >
> > New versions get new GUIDs allows for gradual deprecation at the
> > expense of size. I think that is a reasonable trade-off to keep from
> > making tsm/report vendor-specific.
>
> This was requested and discussed during the SVSM spec review and there
> were no objections raised. See the this thread where this was discussed:
>
> https://lore.kernel.org/linux-coco/09819cb3-1938-fe86-b948-28aaffbe584e@amd.com/
>
We also hadn't had the configfs-tsm unification point, so I think it's
worth folding in that discussion.
In terms of querying specific services, would you help me with a
concrete example of where the evidence collector ought to query a
specific version instead of the service enumeration?
> The changes you're requesting would require a new version of the spec
> and updates to the protocol.
>
I think the changes I'm requesting are to just limit the exposure of
the protocol to linux. What specifically about what I wrote requires a
change to the spec? Is it the lack of plural handling of 'its GUID
value' in "Each service will document its GUID value and the format of
its manifest content."?
> >
> >>
> >> - 'manifestblob' (output)
> >> Used to return the service manifest associated with the attestation
> >> report.
> >
> > Given the above, I think we can just append the manifest to the report
> > since the report size is known a priori.
>
> We could have theoretically done the same thing with the auxblob (certs
> data), but that is separate. I prefer the idea of having an individual
> entry per piece of data being returned.
Fair enough, another RO blob seems okay enough.
>
> Thanks,
> Tom
>
> >
> >>
> >> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> >> ---
> >> Documentation/ABI/testing/configfs-tsm | 55 ++++++++++
> >> arch/x86/include/asm/sev.h | 31 +++++-
> >> arch/x86/kernel/sev.c | 50 +++++++++
> >> drivers/virt/coco/sev-guest/sev-guest.c | 137 ++++++++++++++++++++++++
> >> drivers/virt/coco/tsm.c | 95 +++++++++++++++-
> >> include/linux/tsm.h | 11 ++
> >> 6 files changed, 376 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
> >> index dd24202b5ba5..c5423987d323 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.9
> >> +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 "svsm" attribute is set
> >> + this file contains the service manifest used for the SVSM
> >> + attestation report from 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,43 @@ 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/svsm
> >> +Date: January, 2024
> >> +KernelVersion: v6.9
> >> +Contact: linux-coco@lists.linux.dev
> >> +Description:
> >> + (WO) Attribute is visible if a TSM implementation provider
> >> + supports the concept of attestation reports for TVMs running
> >> + under an SVSM, like SEV-SNP. Specifying any non-zero value
> >> + implies that the attestation report should come from the SVSM.
> >> + 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.9
> >> +Contact: linux-coco@lists.linux.dev
> >> +Description:
> >> + (WO) Attribute is visible if a TSM implementation provider
> >> + supports the concept of attestation reports for TVMs running
> >> + under an SVSM, like SEV-SNP. Specifying a empty or null GUID
> >> + (00000000-0000-0000-0000-000000) requests all active services
> >> + within the SVSM be part of the attestation report. Specifying
> >> + a non-null GUID requests an attestation report of just the
> >> + specified service using the manifest form specified by the
> >> + service_version attribute.
> >> + 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_version
> >> +Date: January, 2024
> >> +KernelVersion: v6.9
> >> +Contact: linux-coco@lists.linux.dev
> >> +Description:
> >> + (WO) Attribute is visible if a TSM implementation provider
> >> + supports the concept of attestation reports for TVMs running
> >> + under an SVSM, like SEV-SNP. Indicates the service manifest
> >> + version requested for the attestation report.
> >> + 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 b126e50a1358..4cafa92d1d3e 100644
> >> --- a/arch/x86/include/asm/sev.h
> >> +++ b/arch/x86/include/asm/sev.h
> >> @@ -194,6 +194,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_version;
> >> + u8 rsvd[4];
> >> +};
> >> +
> >> /*
> >> * SVSM protocol structure
> >> */
> >> @@ -217,6 +238,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);
> >> @@ -287,6 +312,7 @@ void snp_set_wakeup_secondary_cpu(void);
> >> bool snp_init(struct boot_params *bp);
> >> void __init __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);
> >> @@ -316,7 +342,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 849df3aae4e1..83bc5efa8fcf 100644
> >> --- a/arch/x86/kernel/sev.c
> >> +++ b/arch/x86/kernel/sev.c
> >> @@ -2378,6 +2378,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);
> >> +
> >> + memcpy(attest_call, input, sizeof(*attest_call));
> >> +
> >> + /*
> >> + * 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 1ff897913bf4..3693373c4227 100644
> >> --- a/drivers/virt/coco/sev-guest/sev-guest.c
> >> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
> >> @@ -783,6 +783,140 @@ 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 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;
> >> +
> >> +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;
> >> +
> >> + 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_version = desc->service_version;
> >> +
> >> + call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SINGLE_SERVICE);
> >> + }
> >> +
> >> + ret = snp_issue_svsm_attestation_request(call_id, &attest_call);
> >> + switch (ret) {
> >> + case SVSM_SUCCESS:
> >> + break;
> >> + case SVSM_ERR_INVALID_PARAMETER:
> >> + 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);
> >> + goto retry;
> >> + }
> >> +
> >> + ret = -EINVAL;
> >> + 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 +931,9 @@ static int sev_report_new(struct tsm_report *report, void *data)
> >> if (desc->inblob_len != SNP_REPORT_USER_DATA_SIZE)
> >> return -EINVAL;
> >>
> >> + if (desc->svsm)
> >> + 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..33fa26406bc6 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,77 @@ static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
> >> }
> >> CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
> >>
> >> +static ssize_t tsm_report_svsm_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.svsm = !!val;
> >> +
> >> + return len;
> >> +}
> >> +CONFIGFS_ATTR_WO(tsm_report_, svsm);
> >> +
> >> +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);
> >> + size_t guid_len;
> >> + int rc;
> >> +
> >> + guard(rwsem_write)(&tsm_rwsem);
> >> + rc = try_advance_write_generation(report);
> >> + if (rc)
> >> + return rc;
> >> +
> >> + /* Obtain the GUID string length */
> >> + guid_len = (len && buf[len - 1] == '\n') ? len - 1 : len;
> >> + if (guid_len && guid_len != UUID_STRING_LEN)
> >> + return -EINVAL;
> >> +
> >> + if (guid_len == UUID_STRING_LEN) {
> >> + rc = guid_parse(buf, &report->desc.service_guid);
> >> + if (rc)
> >> + return rc;
> >> + } else {
> >> + report->desc.service_guid = guid_null;
> >> + }
> >> +
> >> + return len;
> >> +}
> >> +CONFIGFS_ATTR_WO(tsm_report_, service_guid);
> >> +
> >> +static ssize_t tsm_report_service_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_version = val;
> >> +
> >> + return len;
> >> +}
> >> +CONFIGFS_ATTR_WO(tsm_report_, service_version);
> >> +
> >> static ssize_t tsm_report_inblob_write(struct config_item *cfg,
> >> const void *buf, size_t count)
> >> {
> >> @@ -163,6 +235,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 +263,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 +299,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 +329,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 +351,9 @@ static struct configfs_attribute *tsm_report_extra_attrs[] = {
> >> TSM_DEFAULT_ATTRS(),
> >> &tsm_report_attr_privlevel,
> >> &tsm_report_attr_privlevel_floor,
> >> + &tsm_report_attr_svsm,
> >> + &tsm_report_attr_service_guid,
> >> + &tsm_report_attr_service_version,
> >> NULL,
> >> };
> >>
> >> @@ -280,6 +369,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,6 +378,7 @@ 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(state);
> >> diff --git a/include/linux/tsm.h b/include/linux/tsm.h
> >> index de8324a2223c..7c36b8448b4f 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
> >> + * @svsm: optional indicator of where to obtain the tsm report blob
> >> + * @service_guid: optional SVSM service guid to attest
> >> + * @service_version: optional SVSM service manifest version requested
> >> */
> >> struct tsm_desc {
> >> unsigned int privlevel;
> >> size_t inblob_len;
> >> u8 inblob[TSM_INBLOB_MAX];
> >> + bool svsm;
> >> + guid_t service_guid;
> >> + unsigned int service_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.42.0
> >>
> >>
> >
> >
--
-Dionna Glaze, PhD (she/her)
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
2024-01-29 20:04 ` Dionna Amalie Glaze
@ 2024-02-01 21:14 ` Tom Lendacky
0 siblings, 0 replies; 42+ messages in thread
From: Tom Lendacky @ 2024-02-01 21:14 UTC (permalink / raw)
To: Dionna Amalie Glaze
Cc: linux-kernel, x86, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Dan Williams, Michael Roth, Ashish Kalra
On 1/29/24 14:04, Dionna Amalie Glaze wrote:
> On Mon, Jan 29, 2024 at 7:02 AM Tom Lendacky <thomas.lendacky@amd.com> wrote:
>>
>> On 1/26/24 19:27, Dionna Amalie Glaze wrote:
>>> On Fri, Jan 26, 2024 at 2:19 PM Tom Lendacky <thomas.lendacky@amd.com> 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:
>>>>
>>>> - 'svsm' (input)
>>>> This attribute is used to determine whether the attestation request
>>>> should be sent to the SVSM or to the SEV firmware.
>>>
>>> This is where I'm torn. If there's an SVSM, it's there to provide
>>> paravirtualization for unenlightened guests /or/ it's there to protect
>>
>> An SVSM is for enlightened guests. A para-visor would be for unenlightened
>> guests.
>>
>>> runtime measurement registers. I don't see there being any particular
>>> value in bifurcating the attestation report space by adding this
>>> option. If there's an SVSM present, the configfs-tsm report should
>>> return the full SVSM attestation only.
>>
>> I don't necessarily agree with that. The guest should still be able to
>> request a traditional attestation report.
>>
>> Maybe I can remove the SVSM attribute and direct the call based on
>> requested VMPL level. If VMPL0 is requested, it goes through the SVSM.
>> If VMPL1+ is requested, it goes to the ASP.
>>
>> That would mean that the privlevel_floor would need to stay at zero.
>>
>>>
>>>>
>>>> - 'service_guid' (input)
>>>> Used for requesting the attestation of a single service within the
>>>> SVSM. 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_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.
>>>
>>> I know that this is specified for the SVSM, but I still don't know
>>> what the intended use case is such that we wouldn't simply always
>>> return the full service manifest.
>>> I can see an argument for an evidence requester not being ready for a
>>> new manifest version and wanting the older version until they can
>>> bridge the gap. I don't see that as needing configuration from the
>>> user space. We can either require new service GUIDs for new versions,
>>> require manifest ABIs to be internally versioned to be additive-only
>>> to not break verifiers that understand up to manifest byte X, or we
>>> allow breaking version changes through control plane configuration
>>> that's passed directly to the SVSM.
>>>
>>> New versions get new GUIDs allows for gradual deprecation at the
>>> expense of size. I think that is a reasonable trade-off to keep from
>>> making tsm/report vendor-specific.
>>
>> This was requested and discussed during the SVSM spec review and there
>> were no objections raised. See the this thread where this was discussed:
>>
>> https://lore.kernel.org/linux-coco/09819cb3-1938-fe86-b948-28aaffbe584e@amd.com/
>>
>
> We also hadn't had the configfs-tsm unification point, so I think it's
> worth folding in that discussion.
> In terms of querying specific services, would you help me with a
> concrete example of where the evidence collector ought to query a
> specific version instead of the service enumeration?
Here is where the request was initially brought up:
https://lore.kernel.org/linux-coco/fbc84da05c5343c5228c5adb697d4b66f1ea6308.camel@HansenPartnership.com/
>
>> The changes you're requesting would require a new version of the spec
>> and updates to the protocol.
>>
>
> I think the changes I'm requesting are to just limit the exposure of
> the protocol to linux. What specifically about what I wrote requires a
> change to the spec? Is it the lack of plural handling of 'its GUID
> value' in "Each service will document its GUID value and the format of
> its manifest content."?
The spec is currently written so that a service has a single GUID. If I
understand correctly, you are asking that each version of the manifest
for a service gets a unique GUID. That would require a change to the
specification to document such a behavior and possibly a protocol
modification to somehow indicate to ignore the version field when
requesting a single service attestation or a new protocol that does not
take/use a version.
Thanks,
Tom
>
>>>
>>>>
>>>> - 'manifestblob' (output)
>>>> Used to return the service manifest associated with the attestation
>>>> report.
>>>
>>> Given the above, I think we can just append the manifest to the report
>>> since the report size is known a priori.
>>
>> We could have theoretically done the same thing with the auxblob (certs
>> data), but that is separate. I prefer the idea of having an individual
>> entry per piece of data being returned.
>
> Fair enough, another RO blob seems okay enough.
>
>>
>> Thanks,
>> Tom
>>
>>>
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
2024-01-26 22:16 ` [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM Tom Lendacky
2024-01-27 1:27 ` Dionna Amalie Glaze
@ 2024-02-02 7:10 ` Dan Williams
2024-02-05 23:29 ` Kuppuswamy, Sathyanarayanan
2024-02-06 18:48 ` Tom Lendacky
1 sibling, 2 replies; 42+ messages in thread
From: Dan Williams @ 2024-02-02 7:10 UTC (permalink / raw)
To: Tom Lendacky, linux-kernel, x86
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:
>
> - 'svsm' (input)
> This attribute is used to determine whether the attestation request
> should be sent to the SVSM or to the SEV firmware.
>
> - 'service_guid' (input)
> Used for requesting the attestation of a single service within the
> SVSM. 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_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 | 55 ++++++++++
> arch/x86/include/asm/sev.h | 31 +++++-
> arch/x86/kernel/sev.c | 50 +++++++++
> drivers/virt/coco/sev-guest/sev-guest.c | 137 ++++++++++++++++++++++++
> drivers/virt/coco/tsm.c | 95 +++++++++++++++-
> include/linux/tsm.h | 11 ++
> 6 files changed, 376 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
> index dd24202b5ba5..c5423987d323 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.9
> +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 "svsm" attribute is set
> + this file contains the service manifest used for the SVSM
> + attestation report from 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
I wish configfs had better dynamic visibility so that this could be
hidden when not active... oh well.
> +
> What: /sys/kernel/config/tsm/report/$name/provider
> Date: September, 2023
> KernelVersion: v6.7
> @@ -80,3 +95,43 @@ 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/svsm
> +Date: January, 2024
> +KernelVersion: v6.9
> +Contact: linux-coco@lists.linux.dev
> +Description:
> + (WO) Attribute is visible if a TSM implementation provider
> + supports the concept of attestation reports for TVMs running
> + under an SVSM, like SEV-SNP. Specifying any non-zero value
Just use kstrtobool just to have a bit more form to it, and who knows
maybe keeping some non-zero numbers reserved turns out useful someday.
...or see below, maybe this shouldn't be an "svsm" flag.
> + implies that the attestation report should come from the SVSM.
> + 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
So this affects the output format of outblob? I think @outblob should
probably document the fact that it depends on @provider, @privlevel, and
now @svsm. Probably all of the format links should live under @outblob
not @provider.
I worry that "svsm" is not going to be the last name for a selected
family of services that might convey something to outblob. I wonder if
this should just be a generic "service" attribute where "svsm" is only
supported value to write today. Another service family could be
introduced later and reuse the service_guid concept, or kernel gets
lucky and a de-facto standard heads off proliferation here.
> +
> +What: /sys/kernel/config/tsm/report/$name/service_guid
> +Date: January, 2024
> +KernelVersion: v6.9
> +Contact: linux-coco@lists.linux.dev
> +Description:
> + (WO) Attribute is visible if a TSM implementation provider
> + supports the concept of attestation reports for TVMs running
> + under an SVSM, like SEV-SNP. Specifying a empty or null GUID
> + (00000000-0000-0000-0000-000000) requests all active services
> + within the SVSM be part of the attestation report. Specifying
> + a non-null GUID requests an attestation report of just the
> + specified service using the manifest form specified by the
> + service_version attribute.
> + 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 the small number of service GUIDs so far perhaps save someone the
URL fetch and list it here?
> +
> +What: /sys/kernel/config/tsm/report/$name/service_version
> +Date: January, 2024
> +KernelVersion: v6.9
> +Contact: linux-coco@lists.linux.dev
> +Description:
> + (WO) Attribute is visible if a TSM implementation provider
> + supports the concept of attestation reports for TVMs running
> + under an SVSM, like SEV-SNP. Indicates the service manifest
> + version requested for the attestation report.
> + 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
Perhaps document that version 1 is assumed and is always compatible?
What prompts new versions and how does that discovered by guest software?
> diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
> index b126e50a1358..4cafa92d1d3e 100644
> --- a/arch/x86/include/asm/sev.h
> +++ b/arch/x86/include/asm/sev.h
> @@ -194,6 +194,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_version;
> + u8 rsvd[4];
> +};
> +
> /*
> * SVSM protocol structure
> */
> @@ -217,6 +238,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);
> @@ -287,6 +312,7 @@ void snp_set_wakeup_secondary_cpu(void);
> bool snp_init(struct boot_params *bp);
> void __init __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);
> @@ -316,7 +342,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 849df3aae4e1..83bc5efa8fcf 100644
> --- a/arch/x86/kernel/sev.c
> +++ b/arch/x86/kernel/sev.c
> @@ -2378,6 +2378,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);
> +
> + memcpy(attest_call, input, sizeof(*attest_call));
*attest_call = *input? Just to save that little bit of reviewer
brainpower wondering if these things are the same type and size?
> +
> + /*
> + * 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 1ff897913bf4..3693373c4227 100644
> --- a/drivers/virt/coco/sev-guest/sev-guest.c
> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
> @@ -783,6 +783,140 @@ 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 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;
> +
> +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;
> +
> + 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_version = desc->service_version;
> +
> + call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SINGLE_SERVICE);
> + }
> +
> + ret = snp_issue_svsm_attestation_request(call_id, &attest_call);
> + switch (ret) {
> + case SVSM_SUCCESS:
> + break;
> + case SVSM_ERR_INVALID_PARAMETER:
> + 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);
> + goto retry;
Is this expected to ever go past 1 retry? Fail after that? It would seem
suspicious if the untrusted host kept asking the guest to allocate more
and more memory. Is there a reasonable max that can be applied to those
buffers?
> + }
> +
> + ret = -EINVAL;
> + 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);
I was going to comment that mixing goto and cleanup.h helpers can be a
recipe for confusion, but this looks clean to me.
> +
> + return ret;
> +}
> +
> static int sev_report_new(struct tsm_report *report, void *data)
> {
> struct snp_msg_cert_entry *cert_table;
> @@ -797,6 +931,9 @@ static int sev_report_new(struct tsm_report *report, void *data)
> if (desc->inblob_len != SNP_REPORT_USER_DATA_SIZE)
> return -EINVAL;
>
> + if (desc->svsm)
> + 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..33fa26406bc6 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,77 @@ static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
> }
> CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
>
> +static ssize_t tsm_report_svsm_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.svsm = !!val;
> +
> + return len;
> +}
> +CONFIGFS_ATTR_WO(tsm_report_, svsm);
Modulo whether this should become "service" per above the rest of the
configfs interface changes look good to me.
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
2024-02-02 7:10 ` Dan Williams
@ 2024-02-05 23:29 ` Kuppuswamy, Sathyanarayanan
2024-02-06 18:53 ` Tom Lendacky
2024-02-06 18:48 ` Tom Lendacky
1 sibling, 1 reply; 42+ messages in thread
From: Kuppuswamy, Sathyanarayanan @ 2024-02-05 23:29 UTC (permalink / raw)
To: Dan Williams, Tom Lendacky, linux-kernel, x86
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
Ashish Kalra
On 2/1/24 11:10 PM, 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:
>>
>> - 'svsm' (input)
>> This attribute is used to determine whether the attestation request
>> should be sent to the SVSM or to the SEV firmware.
>>
>> - 'service_guid' (input)
>> Used for requesting the attestation of a single service within the
>> SVSM. 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_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 | 55 ++++++++++
>> arch/x86/include/asm/sev.h | 31 +++++-
>> arch/x86/kernel/sev.c | 50 +++++++++
>> drivers/virt/coco/sev-guest/sev-guest.c | 137 ++++++++++++++++++++++++
>> drivers/virt/coco/tsm.c | 95 +++++++++++++++-
>> include/linux/tsm.h | 11 ++
>> 6 files changed, 376 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
>> index dd24202b5ba5..c5423987d323 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.9
>> +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 "svsm" attribute is set
>> + this file contains the service manifest used for the SVSM
>> + attestation report from 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
> I wish configfs had better dynamic visibility so that this could be
> hidden when not active... oh well.
>
>> +
>> What: /sys/kernel/config/tsm/report/$name/provider
>> Date: September, 2023
>> KernelVersion: v6.7
>> @@ -80,3 +95,43 @@ 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/svsm
>> +Date: January, 2024
>> +KernelVersion: v6.9
>> +Contact: linux-coco@lists.linux.dev
>> +Description:
>> + (WO) Attribute is visible if a TSM implementation provider
>> + supports the concept of attestation reports for TVMs running
>> + under an SVSM, like SEV-SNP. Specifying any non-zero value
> Just use kstrtobool just to have a bit more form to it, and who knows
> maybe keeping some non-zero numbers reserved turns out useful someday.
>
> ...or see below, maybe this shouldn't be an "svsm" flag.
>
>> + implies that the attestation report should come from the SVSM.
>> + 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
> So this affects the output format of outblob? I think @outblob should
> probably document the fact that it depends on @provider, @privlevel, and
> now @svsm. Probably all of the format links should live under @outblob
> not @provider.
>
> I worry that "svsm" is not going to be the last name for a selected
> family of services that might convey something to outblob. I wonder if
> this should just be a generic "service" attribute where "svsm" is only
> supported value to write today. Another service family could be
> introduced later and reuse the service_guid concept, or kernel gets
> lucky and a de-facto standard heads off proliferation here.
>
>> +
>> +What: /sys/kernel/config/tsm/report/$name/service_guid
>> +Date: January, 2024
>> +KernelVersion: v6.9
>> +Contact: linux-coco@lists.linux.dev
>> +Description:
>> + (WO) Attribute is visible if a TSM implementation provider
>> + supports the concept of attestation reports for TVMs running
>> + under an SVSM, like SEV-SNP. Specifying a empty or null GUID
>> + (00000000-0000-0000-0000-000000) requests all active services
>> + within the SVSM be part of the attestation report. Specifying
>> + a non-null GUID requests an attestation report of just the
>> + specified service using the manifest form specified by the
>> + service_version attribute.
>> + 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 the small number of service GUIDs so far perhaps save someone the
> URL fetch and list it here?
How will user know about the available GUIDs? Is there a way for user to
query this list?
>
>> +
>> +What: /sys/kernel/config/tsm/report/$name/service_version
>> +Date: January, 2024
>> +KernelVersion: v6.9
>> +Contact: linux-coco@lists.linux.dev
>> +Description:
>> + (WO) Attribute is visible if a TSM implementation provider
>> + supports the concept of attestation reports for TVMs running
>> + under an SVSM, like SEV-SNP. Indicates the service manifest
>> + version requested for the attestation report.
>> + 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
> Perhaps document that version 1 is assumed and is always compatible?
>
> What prompts new versions and how does that discovered by guest software?
Why user care about it? If it is going to affect manifestblob output, I
recommend adding that info there.
>
>> diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
>> index b126e50a1358..4cafa92d1d3e 100644
>> --- a/arch/x86/include/asm/sev.h
>> +++ b/arch/x86/include/asm/sev.h
>> @@ -194,6 +194,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_version;
>> + u8 rsvd[4];
>> +};
>> +
>> /*
>> * SVSM protocol structure
>> */
>> @@ -217,6 +238,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);
>> @@ -287,6 +312,7 @@ void snp_set_wakeup_secondary_cpu(void);
>> bool snp_init(struct boot_params *bp);
>> void __init __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);
>> @@ -316,7 +342,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 849df3aae4e1..83bc5efa8fcf 100644
>> --- a/arch/x86/kernel/sev.c
>> +++ b/arch/x86/kernel/sev.c
>> @@ -2378,6 +2378,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);
>> +
>> + memcpy(attest_call, input, sizeof(*attest_call));
> *attest_call = *input? Just to save that little bit of reviewer
> brainpower wondering if these things are the same type and size?
>
>> +
>> + /*
>> + * 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 1ff897913bf4..3693373c4227 100644
>> --- a/drivers/virt/coco/sev-guest/sev-guest.c
>> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
>> @@ -783,6 +783,140 @@ 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 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;
>> +
>> +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;
>> +
>> + 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_version = desc->service_version;
>> +
>> + call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SINGLE_SERVICE);
>> + }
>> +
>> + ret = snp_issue_svsm_attestation_request(call_id, &attest_call);
>> + switch (ret) {
>> + case SVSM_SUCCESS:
>> + break;
>> + case SVSM_ERR_INVALID_PARAMETER:
>> + 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);
>> + goto retry;
> Is this expected to ever go past 1 retry? Fail after that? It would seem
> suspicious if the untrusted host kept asking the guest to allocate more
> and more memory. Is there a reasonable max that can be applied to those
> buffers?
>
>> + }
>> +
>> + ret = -EINVAL;
>> + 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);
> I was going to comment that mixing goto and cleanup.h helpers can be a
> recipe for confusion, but this looks clean to me.
>
>> +
>> + return ret;
>> +}
>> +
>> static int sev_report_new(struct tsm_report *report, void *data)
>> {
>> struct snp_msg_cert_entry *cert_table;
>> @@ -797,6 +931,9 @@ static int sev_report_new(struct tsm_report *report, void *data)
>> if (desc->inblob_len != SNP_REPORT_USER_DATA_SIZE)
>> return -EINVAL;
>>
>> + if (desc->svsm)
>> + 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..33fa26406bc6 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,77 @@ static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
>> }
>> CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
>>
>> +static ssize_t tsm_report_svsm_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.svsm = !!val;
>> +
>> + return len;
>> +}
>> +CONFIGFS_ATTR_WO(tsm_report_, svsm);
> Modulo whether this should become "service" per above the rest of the
> configfs interface changes look good to me.
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
2024-02-05 23:29 ` Kuppuswamy, Sathyanarayanan
@ 2024-02-06 18:53 ` Tom Lendacky
0 siblings, 0 replies; 42+ messages in thread
From: Tom Lendacky @ 2024-02-06 18:53 UTC (permalink / raw)
To: Kuppuswamy, Sathyanarayanan, Dan Williams, linux-kernel, x86
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
Ashish Kalra
On 2/5/24 17:29, Kuppuswamy, Sathyanarayanan wrote:
>
> On 2/1/24 11:10 PM, 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:
>>>
>>> - 'svsm' (input)
>>> This attribute is used to determine whether the attestation request
>>> should be sent to the SVSM or to the SEV firmware.
>>>
>>> - 'service_guid' (input)
>>> Used for requesting the attestation of a single service within the
>>> SVSM. 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_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 | 55 ++++++++++
>>> arch/x86/include/asm/sev.h | 31 +++++-
>>> arch/x86/kernel/sev.c | 50 +++++++++
>>> drivers/virt/coco/sev-guest/sev-guest.c | 137 ++++++++++++++++++++++++
>>> drivers/virt/coco/tsm.c | 95 +++++++++++++++-
>>> include/linux/tsm.h | 11 ++
>>> 6 files changed, 376 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
>>> index dd24202b5ba5..c5423987d323 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.9
>>> +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 "svsm" attribute is set
>>> + this file contains the service manifest used for the SVSM
>>> + attestation report from 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
>> I wish configfs had better dynamic visibility so that this could be
>> hidden when not active... oh well.
>>
>>> +
>>> What: /sys/kernel/config/tsm/report/$name/provider
>>> Date: September, 2023
>>> KernelVersion: v6.7
>>> @@ -80,3 +95,43 @@ 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/svsm
>>> +Date: January, 2024
>>> +KernelVersion: v6.9
>>> +Contact: linux-coco@lists.linux.dev
>>> +Description:
>>> + (WO) Attribute is visible if a TSM implementation provider
>>> + supports the concept of attestation reports for TVMs running
>>> + under an SVSM, like SEV-SNP. Specifying any non-zero value
>> Just use kstrtobool just to have a bit more form to it, and who knows
>> maybe keeping some non-zero numbers reserved turns out useful someday.
>>
>> ...or see below, maybe this shouldn't be an "svsm" flag.
>>
>>> + implies that the attestation report should come from the SVSM.
>>> + 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
>> So this affects the output format of outblob? I think @outblob should
>> probably document the fact that it depends on @provider, @privlevel, and
>> now @svsm. Probably all of the format links should live under @outblob
>> not @provider.
>>
>> I worry that "svsm" is not going to be the last name for a selected
>> family of services that might convey something to outblob. I wonder if
>> this should just be a generic "service" attribute where "svsm" is only
>> supported value to write today. Another service family could be
>> introduced later and reuse the service_guid concept, or kernel gets
>> lucky and a de-facto standard heads off proliferation here.
>>
>>> +
>>> +What: /sys/kernel/config/tsm/report/$name/service_guid
>>> +Date: January, 2024
>>> +KernelVersion: v6.9
>>> +Contact: linux-coco@lists.linux.dev
>>> +Description:
>>> + (WO) Attribute is visible if a TSM implementation provider
>>> + supports the concept of attestation reports for TVMs running
>>> + under an SVSM, like SEV-SNP. Specifying a empty or null GUID
>>> + (00000000-0000-0000-0000-000000) requests all active services
>>> + within the SVSM be part of the attestation report. Specifying
>>> + a non-null GUID requests an attestation report of just the
>>> + specified service using the manifest form specified by the
>>> + service_version attribute.
>>> + 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 the small number of service GUIDs so far perhaps save someone the
>> URL fetch and list it here?
>
> How will user know about the available GUIDs? Is there a way for user to
> query this list?
In a sense, yes. You can request an all services attestation which will
return a manifest containing all the active services GUIDs.
>
>>
>>> +
>>> +What: /sys/kernel/config/tsm/report/$name/service_version
>>> +Date: January, 2024
>>> +KernelVersion: v6.9
>>> +Contact: linux-coco@lists.linux.dev
>>> +Description:
>>> + (WO) Attribute is visible if a TSM implementation provider
>>> + supports the concept of attestation reports for TVMs running
>>> + under an SVSM, like SEV-SNP. Indicates the service manifest
>>> + version requested for the attestation report.
>>> + 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
>> Perhaps document that version 1 is assumed and is always compatible?
>>
>> What prompts new versions and how does that discovered by guest software?
>
> Why user care about it? If it is going to affect manifestblob output, I
> recommend adding that info there.
Will do.
Thanks,
Tom
>
>>
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
2024-02-02 7:10 ` Dan Williams
2024-02-05 23:29 ` Kuppuswamy, Sathyanarayanan
@ 2024-02-06 18:48 ` Tom Lendacky
2024-02-13 2:34 ` Dan Williams
1 sibling, 1 reply; 42+ messages in thread
From: Tom Lendacky @ 2024-02-06 18:48 UTC (permalink / raw)
To: Dan Williams, linux-kernel, x86
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
Ashish Kalra
On 2/2/24 01:10, 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:
>>
>> - 'svsm' (input)
>> This attribute is used to determine whether the attestation request
>> should be sent to the SVSM or to the SEV firmware.
>>
>> - 'service_guid' (input)
>> Used for requesting the attestation of a single service within the
>> SVSM. 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_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 | 55 ++++++++++
>> arch/x86/include/asm/sev.h | 31 +++++-
>> arch/x86/kernel/sev.c | 50 +++++++++
>> drivers/virt/coco/sev-guest/sev-guest.c | 137 ++++++++++++++++++++++++
>> drivers/virt/coco/tsm.c | 95 +++++++++++++++-
>> include/linux/tsm.h | 11 ++
>> 6 files changed, 376 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
>> index dd24202b5ba5..c5423987d323 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.9
>> +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 "svsm" attribute is set
>> + this file contains the service manifest used for the SVSM
>> + attestation report from 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
>
> I wish configfs had better dynamic visibility so that this could be
> hidden when not active... oh well.
So do I. I played with the idea of having two different structs and
registering one or the other based on whether an SVSM was present. Thoughts?
>
>> +
>> What: /sys/kernel/config/tsm/report/$name/provider
>> Date: September, 2023
>> KernelVersion: v6.7
>> @@ -80,3 +95,43 @@ 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/svsm
>> +Date: January, 2024
>> +KernelVersion: v6.9
>> +Contact: linux-coco@lists.linux.dev
>> +Description:
>> + (WO) Attribute is visible if a TSM implementation provider
>> + supports the concept of attestation reports for TVMs running
>> + under an SVSM, like SEV-SNP. Specifying any non-zero value
>
> Just use kstrtobool just to have a bit more form to it, and who knows
> maybe keeping some non-zero numbers reserved turns out useful someday.
>
> ...or see below, maybe this shouldn't be an "svsm" flag.
>
>> + implies that the attestation report should come from the SVSM.
>> + 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
>
> So this affects the output format of outblob? I think @outblob should
> probably document the fact that it depends on @provider, @privlevel, and
> now @svsm. Probably all of the format links should live under @outblob
> not @provider.
It doesn't change the output format, it is still a standard SNP
attestation report. What changes is that a SHA-512 hash of the nonce and
the manifest are taken and passed as report data as opposed to just the
nonce value.
>
> I worry that "svsm" is not going to be the last name for a selected
> family of services that might convey something to outblob. I wonder if
> this should just be a generic "service" attribute where "svsm" is only
> supported value to write today. Another service family could be
> introduced later and reuse the service_guid concept, or kernel gets
> lucky and a de-facto standard heads off proliferation here.
I can work something up along that line and see what it looks like.
>
>> +
>> +What: /sys/kernel/config/tsm/report/$name/service_guid
>> +Date: January, 2024
>> +KernelVersion: v6.9
>> +Contact: linux-coco@lists.linux.dev
>> +Description:
>> + (WO) Attribute is visible if a TSM implementation provider
>> + supports the concept of attestation reports for TVMs running
>> + under an SVSM, like SEV-SNP. Specifying a empty or null GUID
>> + (00000000-0000-0000-0000-000000) requests all active services
>> + within the SVSM be part of the attestation report. Specifying
>> + a non-null GUID requests an attestation report of just the
>> + specified service using the manifest form specified by the
>> + service_version attribute.
>> + 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 the small number of service GUIDs so far perhaps save someone the
> URL fetch and list it here?
I can do that. I'll put the currently defined one(s) along with the link.
>
>> +
>> +What: /sys/kernel/config/tsm/report/$name/service_version
>> +Date: January, 2024
>> +KernelVersion: v6.9
>> +Contact: linux-coco@lists.linux.dev
>> +Description:
>> + (WO) Attribute is visible if a TSM implementation provider
>> + supports the concept of attestation reports for TVMs running
>> + under an SVSM, like SEV-SNP. Indicates the service manifest
>> + version requested for the attestation report.
>> + 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
>
> Perhaps document that version 1 is assumed and is always compatible?
Can do.
>
> What prompts new versions and how does that discovered by guest software?
New versions will depend on the service that is running. Changes or
updates to that service would document the new versions manifest output.
There isn't currently a discoverable way other than calling with the
requested version and seeing if an error is returned.
A possible extension to the SVSM attestation protocol could create a
version query call.
>
>> diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
>> index b126e50a1358..4cafa92d1d3e 100644
>> --- a/arch/x86/include/asm/sev.h
>> +++ b/arch/x86/include/asm/sev.h
>> @@ -194,6 +194,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_version;
>> + u8 rsvd[4];
>> +};
>> +
>> /*
>> * SVSM protocol structure
>> */
>> @@ -217,6 +238,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);
>> @@ -287,6 +312,7 @@ void snp_set_wakeup_secondary_cpu(void);
>> bool snp_init(struct boot_params *bp);
>> void __init __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);
>> @@ -316,7 +342,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 849df3aae4e1..83bc5efa8fcf 100644
>> --- a/arch/x86/kernel/sev.c
>> +++ b/arch/x86/kernel/sev.c
>> @@ -2378,6 +2378,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);
>> +
>> + memcpy(attest_call, input, sizeof(*attest_call));
>
> *attest_call = *input? Just to save that little bit of reviewer
> brainpower wondering if these things are the same type and size?
Ok.
>
>> +
>> + /*
>> + * 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 1ff897913bf4..3693373c4227 100644
>> --- a/drivers/virt/coco/sev-guest/sev-guest.c
>> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
>> @@ -783,6 +783,140 @@ 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 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;
>> +
>> +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;
>> +
>> + 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_version = desc->service_version;
>> +
>> + call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SINGLE_SERVICE);
>> + }
>> +
>> + ret = snp_issue_svsm_attestation_request(call_id, &attest_call);
>> + switch (ret) {
>> + case SVSM_SUCCESS:
>> + break;
>> + case SVSM_ERR_INVALID_PARAMETER:
>> + 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);
>> + goto retry;
>
> Is this expected to ever go past 1 retry? Fail after that? It would seem
> suspicious if the untrusted host kept asking the guest to allocate more
> and more memory. Is there a reasonable max that can be applied to those
> buffers?
The report buffer and manifest buffer should be fixed after boot, but the
certs buffer could be dynamic. But I wouldn't expect that the provider is
updating the certs that often.
I can put a maximum retry counter in place here, with 3 attempts seeming
reasonable.
>
>> + }
>> +
>> + ret = -EINVAL;
>> + 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);
>
> I was going to comment that mixing goto and cleanup.h helpers can be a
> recipe for confusion, but this looks clean to me.
>
>> +
>> + return ret;
>> +}
>> +
>> static int sev_report_new(struct tsm_report *report, void *data)
>> {
>> struct snp_msg_cert_entry *cert_table;
>> @@ -797,6 +931,9 @@ static int sev_report_new(struct tsm_report *report, void *data)
>> if (desc->inblob_len != SNP_REPORT_USER_DATA_SIZE)
>> return -EINVAL;
>>
>> + if (desc->svsm)
>> + 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..33fa26406bc6 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,77 @@ static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
>> }
>> CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
>>
>> +static ssize_t tsm_report_svsm_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.svsm = !!val;
>> +
>> + return len;
>> +}
>> +CONFIGFS_ATTR_WO(tsm_report_, svsm);
>
> Modulo whether this should become "service" per above the rest of the
> configfs interface changes look good to me.
Let me re-work it for the next version and see how it all looks.
Thanks,
Tom
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
2024-02-06 18:48 ` Tom Lendacky
@ 2024-02-13 2:34 ` Dan Williams
2024-02-16 19:07 ` Tom Lendacky
2024-02-23 20:41 ` Tom Lendacky
0 siblings, 2 replies; 42+ messages in thread
From: Dan Williams @ 2024-02-13 2:34 UTC (permalink / raw)
To: Tom Lendacky, Dan Williams, linux-kernel, x86
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
Ashish Kalra
Tom Lendacky wrote:
> On 2/2/24 01:10, 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:
> >>
> >> - 'svsm' (input)
> >> This attribute is used to determine whether the attestation request
> >> should be sent to the SVSM or to the SEV firmware.
> >>
> >> - 'service_guid' (input)
> >> Used for requesting the attestation of a single service within the
> >> SVSM. 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_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 | 55 ++++++++++
> >> arch/x86/include/asm/sev.h | 31 +++++-
> >> arch/x86/kernel/sev.c | 50 +++++++++
> >> drivers/virt/coco/sev-guest/sev-guest.c | 137 ++++++++++++++++++++++++
> >> drivers/virt/coco/tsm.c | 95 +++++++++++++++-
> >> include/linux/tsm.h | 11 ++
> >> 6 files changed, 376 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
> >> index dd24202b5ba5..c5423987d323 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.9
> >> +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 "svsm" attribute is set
> >> + this file contains the service manifest used for the SVSM
> >> + attestation report from 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
> >
> > I wish configfs had better dynamic visibility so that this could be
> > hidden when not active... oh well.
>
> So do I. I played with the idea of having two different structs and
> registering one or the other based on whether an SVSM was present. Thoughts?
That's the status quo for the differences between TDX vs SEV
(tsm_report_default_type vs tsm_report_extra_type). I think a
"tsm_report_service_type " can be a new superset of
tsm_report_extra_type. That that just starts to get messy if
implementations start to pick and choose on a finer granularity what
they support. For example, what if TDX supports these new service
attributes, but not privlevel.
It seems straightforward to add an is_visible() callback to
'struct configfs_item_operations'. Then a common superset of all the
attributes could be specified, but with an is_visible() implementation
that consults with data registered with tsm_register() rather than the
@type argument directly.
[..]
> >> +What: /sys/kernel/config/tsm/report/$name/svsm
> >> +Date: January, 2024
> >> +KernelVersion: v6.9
> >> +Contact: linux-coco@lists.linux.dev
> >> +Description:
> >> + (WO) Attribute is visible if a TSM implementation provider
> >> + supports the concept of attestation reports for TVMs running
> >> + under an SVSM, like SEV-SNP. Specifying any non-zero value
> >
> > Just use kstrtobool just to have a bit more form to it, and who knows
> > maybe keeping some non-zero numbers reserved turns out useful someday.
> >
> > ...or see below, maybe this shouldn't be an "svsm" flag.
> >
> >> + implies that the attestation report should come from the SVSM.
> >> + 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
> >
> > So this affects the output format of outblob? I think @outblob should
> > probably document the fact that it depends on @provider, @privlevel, and
> > now @svsm. Probably all of the format links should live under @outblob
> > not @provider.
>
> It doesn't change the output format, it is still a standard SNP
> attestation report. What changes is that a SHA-512 hash of the nonce and
> the manifest are taken and passed as report data as opposed to just the
> nonce value.
If it is the same format, and the input is user controlled then I am
confused what the new ABI is selecting? Could it not be inferred by
privlevel?
[..]
> >> +
> >> +What: /sys/kernel/config/tsm/report/$name/service_version
> >> +Date: January, 2024
> >> +KernelVersion: v6.9
> >> +Contact: linux-coco@lists.linux.dev
> >> +Description:
> >> + (WO) Attribute is visible if a TSM implementation provider
> >> + supports the concept of attestation reports for TVMs running
> >> + under an SVSM, like SEV-SNP. Indicates the service manifest
> >> + version requested for the attestation report.
> >> + 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
> >
> > Perhaps document that version 1 is assumed and is always compatible?
>
> Can do.
>
> >
> > What prompts new versions and how does that discovered by guest software?
>
> New versions will depend on the service that is running. Changes or
> updates to that service would document the new versions manifest output.
> There isn't currently a discoverable way other than calling with the
> requested version and seeing if an error is returned.
>
> A possible extension to the SVSM attestation protocol could create a
> version query call.
Can the version be made to not matter, or be inferred by the presence of
a new enumerated service capability? For example, make the same compat
guarantees that ACPI methods do between versions where extensions are
optional and software can always use v1 without breaking? Otherwise, I
am not grokking what software should do with this version.
Separately, is this a version for the service protocol or a version of
the manifest format? The description makes it sound like the latter, but
the "service_version" name makes it sound like the former.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
2024-02-13 2:34 ` Dan Williams
@ 2024-02-16 19:07 ` Tom Lendacky
2024-02-16 20:46 ` Dan Williams
2024-02-23 20:41 ` Tom Lendacky
1 sibling, 1 reply; 42+ messages in thread
From: Tom Lendacky @ 2024-02-16 19:07 UTC (permalink / raw)
To: Dan Williams, linux-kernel, x86
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
Ashish Kalra
On 2/12/24 20:34, Dan Williams wrote:
> Tom Lendacky wrote:
>> On 2/2/24 01:10, 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:
>>>>
>>>> - 'svsm' (input)
>>>> This attribute is used to determine whether the attestation request
>>>> should be sent to the SVSM or to the SEV firmware.
>>>>
>>>> - 'service_guid' (input)
>>>> Used for requesting the attestation of a single service within the
>>>> SVSM. 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_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 | 55 ++++++++++
>>>> arch/x86/include/asm/sev.h | 31 +++++-
>>>> arch/x86/kernel/sev.c | 50 +++++++++
>>>> drivers/virt/coco/sev-guest/sev-guest.c | 137 ++++++++++++++++++++++++
>>>> drivers/virt/coco/tsm.c | 95 +++++++++++++++-
>>>> include/linux/tsm.h | 11 ++
>>>> 6 files changed, 376 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
>>>> index dd24202b5ba5..c5423987d323 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.9
>>>> +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 "svsm" attribute is set
>>>> + this file contains the service manifest used for the SVSM
>>>> + attestation report from 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
>>>
>>> I wish configfs had better dynamic visibility so that this could be
>>> hidden when not active... oh well.
>>
>> So do I. I played with the idea of having two different structs and
>> registering one or the other based on whether an SVSM was present. Thoughts?
>
> That's the status quo for the differences between TDX vs SEV
> (tsm_report_default_type vs tsm_report_extra_type). I think a
> "tsm_report_service_type " can be a new superset of
> tsm_report_extra_type. That that just starts to get messy if
> implementations start to pick and choose on a finer granularity what
> they support. For example, what if TDX supports these new service
> attributes, but not privlevel.
>
> It seems straightforward to add an is_visible() callback to
> 'struct configfs_item_operations'. Then a common superset of all the
> attributes could be specified, but with an is_visible() implementation
> that consults with data registered with tsm_register() rather than the
> @type argument directly.
Let me look into that.
>
> [..]
>>>> +What: /sys/kernel/config/tsm/report/$name/svsm
>>>> +Date: January, 2024
>>>> +KernelVersion: v6.9
>>>> +Contact: linux-coco@lists.linux.dev
>>>> +Description:
>>>> + (WO) Attribute is visible if a TSM implementation provider
>>>> + supports the concept of attestation reports for TVMs running
>>>> + under an SVSM, like SEV-SNP. Specifying any non-zero value
>>>
>>> Just use kstrtobool just to have a bit more form to it, and who knows
>>> maybe keeping some non-zero numbers reserved turns out useful someday.
>>>
>>> ...or see below, maybe this shouldn't be an "svsm" flag.
>>>
>>>> + implies that the attestation report should come from the SVSM.
>>>> + 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
>>>
>>> So this affects the output format of outblob? I think @outblob should
>>> probably document the fact that it depends on @provider, @privlevel, and
>>> now @svsm. Probably all of the format links should live under @outblob
>>> not @provider.
>>
>> It doesn't change the output format, it is still a standard SNP
>> attestation report. What changes is that a SHA-512 hash of the nonce and
>> the manifest are taken and passed as report data as opposed to just the
>> nonce value.
>
> If it is the same format, and the input is user controlled then I am
> confused what the new ABI is selecting? Could it not be inferred by
> privlevel?
The new ABI selects whether to go through the SVSM to get the attestation
report, which will additionally return a manifest that, along with the
nonce, has become part of the report through hashing.
But, yes, I mentioned in a previous reply [1] that we could use privlevel
to determine whether to invoke attestation through an SVSM request or
through the standard method of issuing an extended guest request.
[1] https://lore.kernel.org/lkml/3fca61f2-6fe0-4431-818e-9c7b96c6a391@amd.com/
>
> [..]
>>>> +
>>>> +What: /sys/kernel/config/tsm/report/$name/service_version
>>>> +Date: January, 2024
>>>> +KernelVersion: v6.9
>>>> +Contact: linux-coco@lists.linux.dev
>>>> +Description:
>>>> + (WO) Attribute is visible if a TSM implementation provider
>>>> + supports the concept of attestation reports for TVMs running
>>>> + under an SVSM, like SEV-SNP. Indicates the service manifest
>>>> + version requested for the attestation report.
>>>> + 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
>>>
>>> Perhaps document that version 1 is assumed and is always compatible?
>>
>> Can do.
>>
>>>
>>> What prompts new versions and how does that discovered by guest software?
>>
>> New versions will depend on the service that is running. Changes or
>> updates to that service would document the new versions manifest output.
>> There isn't currently a discoverable way other than calling with the
>> requested version and seeing if an error is returned.
>>
>> A possible extension to the SVSM attestation protocol could create a
>> version query call.
>
> Can the version be made to not matter, or be inferred by the presence of
> a new enumerated service capability? For example, make the same compat
> guarantees that ACPI methods do between versions where extensions are
> optional and software can always use v1 without breaking? Otherwise, I
> am not grokking what software should do with this version.
Software can always use v1. The idea is that if a service wanted to
provide additional information or change the information provided in the
service manifest, then it would have to do that via a new version of its
manifest so as not to break existing users. By default, zero would be used
for the service manifest version and have to be updated by the user if
they wanted a different one.
>
> Separately, is this a version for the service protocol or a version of
> the manifest format? The description makes it sound like the latter, but
> the "service_version" name makes it sound like the former.
Correct, it is for the manifest version. I can rename it to
service_manifest or service_manifest_version. I'd rather not rename it to
manifest_version since it is specific to an individual service.
Thanks,
Tom
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
2024-02-16 19:07 ` Tom Lendacky
@ 2024-02-16 20:46 ` Dan Williams
0 siblings, 0 replies; 42+ messages in thread
From: Dan Williams @ 2024-02-16 20:46 UTC (permalink / raw)
To: Tom Lendacky, Dan Williams, linux-kernel, x86
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
Ashish Kalra
Tom Lendacky wrote:
[..]
> > If it is the same format, and the input is user controlled then I am
> > confused what the new ABI is selecting? Could it not be inferred by
> > privlevel?
>
> The new ABI selects whether to go through the SVSM to get the attestation
> report, which will additionally return a manifest that, along with the
> nonce, has become part of the report through hashing.
Ah yeah, that's a lot to overlead to the meaning of privlevel.
>
> But, yes, I mentioned in a previous reply [1] that we could use privlevel
> to determine whether to invoke attestation through an SVSM request or
> through the standard method of issuing an extended guest request.
>
> [1] https://lore.kernel.org/lkml/3fca61f2-6fe0-4431-818e-9c7b96c6a391@amd.com/
Missed that, thanks. Lets keep explicit as you have it and not overload
privlevel.
[..]
> > Can the version be made to not matter, or be inferred by the presence of
> > a new enumerated service capability? For example, make the same compat
> > guarantees that ACPI methods do between versions where extensions are
> > optional and software can always use v1 without breaking? Otherwise, I
> > am not grokking what software should do with this version.
>
> Software can always use v1. The idea is that if a service wanted to
> provide additional information or change the information provided in the
> service manifest, then it would have to do that via a new version of its
> manifest so as not to break existing users. By default, zero would be used
> for the service manifest version and have to be updated by the user if
> they wanted a different one.
Can it just be the case the manifest can only grow but old fields never
change? Then software can determine the "version" based on manifest size
and no software gets built with an explicit version check, and is
instead built to understand a certain point in the evolution of the
manifest.
To be clear this is my standard response to any specification that
transmits a payload that "may change in the future", if it is an
awkward fit in this case it would at least be good to clarify why.
> > Separately, is this a version for the service protocol or a version of
> > the manifest format? The description makes it sound like the latter, but
> > the "service_version" name makes it sound like the former.
>
> Correct, it is for the manifest version. I can rename it to
> service_manifest or service_manifest_version. I'd rather not rename it to
> manifest_version since it is specific to an individual service.
FWIW, service_manifest_version makes it crystal clear to me, but maybe
even better would be that the output size already conveys that, this
attribute is not needed, and userspace reads as much of the manifest as
it knows about.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
2024-02-13 2:34 ` Dan Williams
2024-02-16 19:07 ` Tom Lendacky
@ 2024-02-23 20:41 ` Tom Lendacky
2024-02-24 0:02 ` Dan Williams
1 sibling, 1 reply; 42+ messages in thread
From: Tom Lendacky @ 2024-02-23 20:41 UTC (permalink / raw)
To: Dan Williams, linux-kernel, x86
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
Ashish Kalra
On 2/12/24 20:34, Dan Williams wrote:
> Tom Lendacky wrote:
>> On 2/2/24 01:10, 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:
>>>>
>>>> - 'svsm' (input)
>>>> This attribute is used to determine whether the attestation request
>>>> should be sent to the SVSM or to the SEV firmware.
>>>>
>>>> - 'service_guid' (input)
>>>> Used for requesting the attestation of a single service within the
>>>> SVSM. 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_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 | 55 ++++++++++
>>>> arch/x86/include/asm/sev.h | 31 +++++-
>>>> arch/x86/kernel/sev.c | 50 +++++++++
>>>> drivers/virt/coco/sev-guest/sev-guest.c | 137 ++++++++++++++++++++++++
>>>> drivers/virt/coco/tsm.c | 95 +++++++++++++++-
>>>> include/linux/tsm.h | 11 ++
>>>> 6 files changed, 376 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
>>>> index dd24202b5ba5..c5423987d323 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.9
>>>> +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 "svsm" attribute is set
>>>> + this file contains the service manifest used for the SVSM
>>>> + attestation report from 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
>>>
>>> I wish configfs had better dynamic visibility so that this could be
>>> hidden when not active... oh well.
>>
>> So do I. I played with the idea of having two different structs and
>> registering one or the other based on whether an SVSM was present. Thoughts?
>
> That's the status quo for the differences between TDX vs SEV
> (tsm_report_default_type vs tsm_report_extra_type). I think a
> "tsm_report_service_type " can be a new superset of
> tsm_report_extra_type. That that just starts to get messy if
> implementations start to pick and choose on a finer granularity what
> they support. For example, what if TDX supports these new service
> attributes, but not privlevel.
>
> It seems straightforward to add an is_visible() callback to
> 'struct configfs_item_operations'. Then a common superset of all the
> attributes could be specified, but with an is_visible() implementation
> that consults with data registered with tsm_register() rather than the
> @type argument directly.
I've been playing with this a bit.
For the configfs support I was thinking of doing a per attribute
is_visible() callback field since the TSM support is currently all in one
group. The callback field would be checked in fs/configfs/dir.c
populate_attrs(). A simple bool return value should suffice, I'm not sure
we need to get into umode changes. If the field is NULL, then the
attribute is displayed. If non-NULL, it depends on the callback return value.
In order to keep tsm.c as vendor neutral as possible, a way to
provide/override a default callback would be needed. The new SVSM related
fields would have a callback assigned that always returns false by
default, so that these attributes wouldn't be visible. A new tsm.c
interface that takes the attribute name and a callback function can be
used to override the requested attribute. For example, the SEV guest
driver could register a callback for these attributes that returns true
when running under an SVSM or false otherwise. Or it could leave the
default in place and register a callback when running under an SVSM that
always returns true.
Thoughts?
Thanks,
Tom
>
> [..]
>>>> +What: /sys/kernel/config/tsm/report/$name/svsm
>>>> +Date: January, 2024
>>>> +KernelVersion: v6.9
>>>> +Contact: linux-coco@lists.linux.dev
>>>> +Description:
>>>> + (WO) Attribute is visible if a TSM implementation provider
>>>> + supports the concept of attestation reports for TVMs running
>>>> + under an SVSM, like SEV-SNP. Specifying any non-zero value
>>>
>>> Just use kstrtobool just to have a bit more form to it, and who knows
>>> maybe keeping some non-zero numbers reserved turns out useful someday.
>>>
>>> ...or see below, maybe this shouldn't be an "svsm" flag.
>>>
>>>> + implies that the attestation report should come from the SVSM.
>>>> + 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
>>>
>>> So this affects the output format of outblob? I think @outblob should
>>> probably document the fact that it depends on @provider, @privlevel, and
>>> now @svsm. Probably all of the format links should live under @outblob
>>> not @provider.
>>
>> It doesn't change the output format, it is still a standard SNP
>> attestation report. What changes is that a SHA-512 hash of the nonce and
>> the manifest are taken and passed as report data as opposed to just the
>> nonce value.
>
> If it is the same format, and the input is user controlled then I am
> confused what the new ABI is selecting? Could it not be inferred by
> privlevel?
>
> [..]
>>>> +
>>>> +What: /sys/kernel/config/tsm/report/$name/service_version
>>>> +Date: January, 2024
>>>> +KernelVersion: v6.9
>>>> +Contact: linux-coco@lists.linux.dev
>>>> +Description:
>>>> + (WO) Attribute is visible if a TSM implementation provider
>>>> + supports the concept of attestation reports for TVMs running
>>>> + under an SVSM, like SEV-SNP. Indicates the service manifest
>>>> + version requested for the attestation report.
>>>> + 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
>>>
>>> Perhaps document that version 1 is assumed and is always compatible?
>>
>> Can do.
>>
>>>
>>> What prompts new versions and how does that discovered by guest software?
>>
>> New versions will depend on the service that is running. Changes or
>> updates to that service would document the new versions manifest output.
>> There isn't currently a discoverable way other than calling with the
>> requested version and seeing if an error is returned.
>>
>> A possible extension to the SVSM attestation protocol could create a
>> version query call.
>
> Can the version be made to not matter, or be inferred by the presence of
> a new enumerated service capability? For example, make the same compat
> guarantees that ACPI methods do between versions where extensions are
> optional and software can always use v1 without breaking? Otherwise, I
> am not grokking what software should do with this version.
>
> Separately, is this a version for the service protocol or a version of
> the manifest format? The description makes it sound like the latter, but
> the "service_version" name makes it sound like the former.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
2024-02-23 20:41 ` Tom Lendacky
@ 2024-02-24 0:02 ` Dan Williams
2024-02-26 14:42 ` Tom Lendacky
0 siblings, 1 reply; 42+ messages in thread
From: Dan Williams @ 2024-02-24 0:02 UTC (permalink / raw)
To: Tom Lendacky, Dan Williams, linux-kernel, x86
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
Ashish Kalra
Tom Lendacky wrote:
> On 2/12/24 20:34, Dan Williams wrote:
> > Tom Lendacky wrote:
> >> On 2/2/24 01:10, 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:
> >>>>
> >>>> - 'svsm' (input)
> >>>> This attribute is used to determine whether the attestation request
> >>>> should be sent to the SVSM or to the SEV firmware.
> >>>>
> >>>> - 'service_guid' (input)
> >>>> Used for requesting the attestation of a single service within the
> >>>> SVSM. 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_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 | 55 ++++++++++
> >>>> arch/x86/include/asm/sev.h | 31 +++++-
> >>>> arch/x86/kernel/sev.c | 50 +++++++++
> >>>> drivers/virt/coco/sev-guest/sev-guest.c | 137 ++++++++++++++++++++++++
> >>>> drivers/virt/coco/tsm.c | 95 +++++++++++++++-
> >>>> include/linux/tsm.h | 11 ++
> >>>> 6 files changed, 376 insertions(+), 3 deletions(-)
> >>>>
> >>>> diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
> >>>> index dd24202b5ba5..c5423987d323 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.9
> >>>> +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 "svsm" attribute is set
> >>>> + this file contains the service manifest used for the SVSM
> >>>> + attestation report from 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
> >>>
> >>> I wish configfs had better dynamic visibility so that this could be
> >>> hidden when not active... oh well.
> >>
> >> So do I. I played with the idea of having two different structs and
> >> registering one or the other based on whether an SVSM was present. Thoughts?
> >
> > That's the status quo for the differences between TDX vs SEV
> > (tsm_report_default_type vs tsm_report_extra_type). I think a
> > "tsm_report_service_type " can be a new superset of
> > tsm_report_extra_type. That that just starts to get messy if
> > implementations start to pick and choose on a finer granularity what
> > they support. For example, what if TDX supports these new service
> > attributes, but not privlevel.
> >
> > It seems straightforward to add an is_visible() callback to
> > 'struct configfs_item_operations'. Then a common superset of all the
> > attributes could be specified, but with an is_visible() implementation
> > that consults with data registered with tsm_register() rather than the
> > @type argument directly.
>
> I've been playing with this a bit.
>
> For the configfs support I was thinking of doing a per attribute
> is_visible() callback field since the TSM support is currently all in one
> group. The callback field would be checked in fs/configfs/dir.c
> populate_attrs(). A simple bool return value should suffice, I'm not sure
> we need to get into umode changes. If the field is NULL, then the
> attribute is displayed. If non-NULL, it depends on the callback return value.
>
> In order to keep tsm.c as vendor neutral as possible, a way to
> provide/override a default callback would be needed. The new SVSM related
> fields would have a callback assigned that always returns false by
> default, so that these attributes wouldn't be visible. A new tsm.c
> interface that takes the attribute name and a callback function can be
> used to override the requested attribute. For example, the SEV guest
> driver could register a callback for these attributes that returns true
> when running under an SVSM or false otherwise. Or it could leave the
> default in place and register a callback when running under an SVSM that
> always returns true.
>
> Thoughts?
Sounds like a patch I want to see, yes. So the idea is the low-level
driver registers the is_visible() callback to the core and that gets to
filter attributes?
Hmm, as long as it ends up looking similar to sysfs is_visible()
prototype.
It could even just be a bitmask of attributes that gets passed in by the
provider, something like:
static struct configfs_attribute *tsm_report_attrs[] = {
[TSM_REPORT_ATTR_GENERATION] = &tsm_report_attr_generation,
[TSM_REPORT_ATTR_PROVIDER] = &tsm_report_attr_provider
[TSM_REPORT_ATTR_PRIVLEVEL] = &tsm_report_attr_privlevel,
[TSM_REPORT_ATTR_FLOOR] = &tsm_report_attr_privlevel_floor,
NULL,
};
bool tsm_report_is_visible(struct config_item *cfg, struct configfs_attribute *attr, int n)
{
return test_bit(n, &provider.attr_mask);
}
...and in is_bin_visible() for the binary attributes?
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
2024-02-24 0:02 ` Dan Williams
@ 2024-02-26 14:42 ` Tom Lendacky
0 siblings, 0 replies; 42+ messages in thread
From: Tom Lendacky @ 2024-02-26 14:42 UTC (permalink / raw)
To: Dan Williams, linux-kernel, x86
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Michael Roth,
Ashish Kalra
On 2/23/24 18:02, Dan Williams wrote:
> Tom Lendacky wrote:
>> On 2/12/24 20:34, Dan Williams wrote:
>>> Tom Lendacky wrote:
>>>> On 2/2/24 01:10, 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:
>>>>>>
>>>>>> - 'svsm' (input)
>>>>>> This attribute is used to determine whether the attestation request
>>>>>> should be sent to the SVSM or to the SEV firmware.
>>>>>>
>>>>>> - 'service_guid' (input)
>>>>>> Used for requesting the attestation of a single service within the
>>>>>> SVSM. 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_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 | 55 ++++++++++
>>>>>> arch/x86/include/asm/sev.h | 31 +++++-
>>>>>> arch/x86/kernel/sev.c | 50 +++++++++
>>>>>> drivers/virt/coco/sev-guest/sev-guest.c | 137 ++++++++++++++++++++++++
>>>>>> drivers/virt/coco/tsm.c | 95 +++++++++++++++-
>>>>>> include/linux/tsm.h | 11 ++
>>>>>> 6 files changed, 376 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
>>>>>> index dd24202b5ba5..c5423987d323 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.9
>>>>>> +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 "svsm" attribute is set
>>>>>> + this file contains the service manifest used for the SVSM
>>>>>> + attestation report from 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
>>>>>
>>>>> I wish configfs had better dynamic visibility so that this could be
>>>>> hidden when not active... oh well.
>>>>
>>>> So do I. I played with the idea of having two different structs and
>>>> registering one or the other based on whether an SVSM was present. Thoughts?
>>>
>>> That's the status quo for the differences between TDX vs SEV
>>> (tsm_report_default_type vs tsm_report_extra_type). I think a
>>> "tsm_report_service_type " can be a new superset of
>>> tsm_report_extra_type. That that just starts to get messy if
>>> implementations start to pick and choose on a finer granularity what
>>> they support. For example, what if TDX supports these new service
>>> attributes, but not privlevel.
>>>
>>> It seems straightforward to add an is_visible() callback to
>>> 'struct configfs_item_operations'. Then a common superset of all the
>>> attributes could be specified, but with an is_visible() implementation
>>> that consults with data registered with tsm_register() rather than the
>>> @type argument directly.
>>
>> I've been playing with this a bit.
>>
>> For the configfs support I was thinking of doing a per attribute
>> is_visible() callback field since the TSM support is currently all in one
>> group. The callback field would be checked in fs/configfs/dir.c
>> populate_attrs(). A simple bool return value should suffice, I'm not sure
>> we need to get into umode changes. If the field is NULL, then the
>> attribute is displayed. If non-NULL, it depends on the callback return value.
>>
>> In order to keep tsm.c as vendor neutral as possible, a way to
>> provide/override a default callback would be needed. The new SVSM related
>> fields would have a callback assigned that always returns false by
>> default, so that these attributes wouldn't be visible. A new tsm.c
>> interface that takes the attribute name and a callback function can be
>> used to override the requested attribute. For example, the SEV guest
>> driver could register a callback for these attributes that returns true
>> when running under an SVSM or false otherwise. Or it could leave the
>> default in place and register a callback when running under an SVSM that
>> always returns true.
>>
>> Thoughts?
>
> Sounds like a patch I want to see, yes. So the idea is the low-level
> driver registers the is_visible() callback to the core and that gets to
> filter attributes?
>
> Hmm, as long as it ends up looking similar to sysfs is_visible()
> prototype.
>
> It could even just be a bitmask of attributes that gets passed in by the
> provider, something like:
>
> static struct configfs_attribute *tsm_report_attrs[] = {
> [TSM_REPORT_ATTR_GENERATION] = &tsm_report_attr_generation,
> [TSM_REPORT_ATTR_PROVIDER] = &tsm_report_attr_provider
> [TSM_REPORT_ATTR_PRIVLEVEL] = &tsm_report_attr_privlevel,
> [TSM_REPORT_ATTR_FLOOR] = &tsm_report_attr_privlevel_floor,
> NULL,
> };
>
> bool tsm_report_is_visible(struct config_item *cfg, struct configfs_attribute *attr, int n)
> {
> return test_bit(n, &provider.attr_mask);
> }
>
> ..and in is_bin_visible() for the binary attributes?
I was thinking something along the lines of the following for the configfs
support:
diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index 18677cd4e62f..c224060c1b6b 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -589,12 +589,20 @@ 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 (attr->ca_is_visible && !attr->ca_is_visible(attr))
+ continue;
+
if ((error = configfs_create_file(item, attr)))
break;
}
}
- if (t->ct_bin_attrs) {
+ if (t->ct_bin_attrs && !error) {
for (i = 0; (bin_attr = t->ct_bin_attrs[i]) != NULL; i++) {
+ attr = &bin_attr->cb_attr;
+
+ if (attr->ca_is_visible && !attr->ca_is_visible(attr))
+ continue;
+
error = configfs_create_bin_file(item, bin_attr);
if (error)
break;
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 2606711adb18..93d346e2afc1 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -112,39 +112,63 @@ static inline void configfs_add_default_group(struct config_group *new_group,
list_add_tail(&new_group->group_entry, &group->default_groups);
}
+typedef bool (*configfs_is_visible_t)(const struct configfs_attribute *attr);
+
struct configfs_attribute {
const char *ca_name;
struct module *ca_owner;
umode_t ca_mode;
+ configfs_is_visible_t ca_is_visible;
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, \
+ .ca_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, \
+ .ca_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, \
+ .ca_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 +180,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, \
+ .ca_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, \
+ .ca_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, \
+ .ca_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).
And then the following for implementing it for tsm, which allows for as
simple or complicated an is_visible() function as required:
diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
index 4ac62c896670..f29310a4a357 100644
--- a/drivers/virt/coco/sev-guest/sev-guest.c
+++ b/drivers/virt/coco/sev-guest/sev-guest.c
@@ -1022,6 +1022,11 @@ static int sev_report_new(struct tsm_report *report, void *data)
return 0;
}
+static bool svsm_make_visible(const struct configfs_attribute *attr)
+{
+ return true;
+}
+
static struct tsm_ops sev_tsm_ops = {
.name = KBUILD_MODNAME,
.report_new = sev_report_new,
@@ -1116,6 +1121,14 @@ static int __init sev_guest_probe(struct platform_device *pdev)
if (ret)
goto e_free_cert_data;
+ if (snp_get_vmpl()) {
+ /* Make the SVSM-related attributes visible */
+ tsm_set_visibility("svsm", svsm_make_visible);
+ tsm_set_visibility("service_guid", svsm_make_visible);
+ tsm_set_visibility("service_manifest_version", svsm_make_visible);
+ tsm_set_visibility("manifestblob", svsm_make_visible);
+ }
+
ret = devm_add_action_or_reset(&pdev->dev, unregister_sev_tsm, NULL);
if (ret)
goto e_free_cert_data;
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
index 51e02001bb4d..ebb3c642f548 100644
--- a/drivers/virt/coco/tsm.c
+++ b/drivers/virt/coco/tsm.c
@@ -64,6 +64,11 @@ static struct tsm_report_state *to_state(struct tsm_report *report)
return container_of(report, struct tsm_report_state, report);
}
+static bool not_visible(const struct configfs_attribute *attr)
+{
+ return false;
+}
+
static int try_advance_write_generation(struct tsm_report *report)
{
struct tsm_report_state *state = to_state(report);
@@ -139,7 +144,7 @@ static ssize_t tsm_report_svsm_store(struct config_item *cfg,
return len;
}
-CONFIGFS_ATTR_WO(tsm_report_, svsm);
+CONFIGFS_ATTR_VISIBLE_WO(tsm_report_, svsm, not_visible);
static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
const char *buf, size_t len)
@@ -168,7 +173,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, not_visible);
static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg,
const char *buf, size_t len)
@@ -189,7 +194,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, not_visible);
static ssize_t tsm_report_inblob_write(struct config_item *cfg,
const void *buf, size_t count)
@@ -336,7 +341,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, not_visible);
#define TSM_DEFAULT_ATTRS() \
&tsm_report_attr_generation, \
@@ -444,6 +449,43 @@ static struct configfs_subsystem tsm_configfs = {
.su_mutex = __MUTEX_INITIALIZER(tsm_configfs.su_mutex),
};
+int tsm_set_visibility(const char *name, configfs_is_visible_t func)
+{
+ struct configfs_bin_attribute *bin_attr;
+ struct configfs_attribute *attr;
+ const struct config_item_type *t;
+ unsigned int i;
+
+ guard(rwsem_write)(&tsm_rwsem);
+
+ t = provider.type;
+
+ if (t->ct_attrs) {
+ for (i = 0; (attr = t->ct_attrs[i]) != NULL; i++) {
+ if (strcmp(attr->ca_name, name))
+ continue;
+
+ attr->ca_is_visible = func;
+ return 0;
+ }
+ }
+
+ if (t->ct_bin_attrs) {
+ for (i = 0; (bin_attr = t->ct_bin_attrs[i]) != NULL; i++) {
+ attr = &bin_attr->cb_attr;
+
+ if (strcmp(attr->ca_name, name))
+ continue;
+
+ attr->ca_is_visible = func;
+ return 0;
+ }
+ }
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(tsm_set_visibility);
+
int tsm_register(const struct tsm_ops *ops, void *priv,
const struct config_item_type *type)
{
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
index c4aed3059500..01b075a4debc 100644
--- a/include/linux/tsm.h
+++ b/include/linux/tsm.h
@@ -5,6 +5,7 @@
#include <linux/sizes.h>
#include <linux/types.h>
#include <linux/uuid.h>
+#include <linux/configfs.h>
#define TSM_INBLOB_MAX 64
#define TSM_OUTBLOB_MAX SZ_32K
@@ -77,4 +78,7 @@ 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_unregister(const struct tsm_ops *ops);
+
+int tsm_set_visibility(const char *name, configfs_is_visible_t func);
+
#endif /* __TSM_H */
Thanks,
Tom
>
>
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH 11/11] x86/sev: Allow non-VMPL0 execution when an SVSM is present
2024-01-26 22:15 [PATCH 00/11] Provide SEV-SNP support for running under an SVSM Tom Lendacky
` (9 preceding siblings ...)
2024-01-26 22:16 ` [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM Tom Lendacky
@ 2024-01-26 22:16 ` Tom Lendacky
2024-02-12 10:40 ` [PATCH 00/11] Provide SEV-SNP support for running under an SVSM Reshetova, Elena
11 siblings, 0 replies; 42+ messages in thread
From: Tom Lendacky @ 2024-01-26 22:16 UTC (permalink / raw)
To: linux-kernel, x86
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 3fbb614c31e0..6740f6298524 100644
--- a/arch/x86/boot/compressed/sev.c
+++ b/arch/x86/boot/compressed/sev.c
@@ -608,10 +608,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 83bc5efa8fcf..a2c1a28335a5 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -2344,22 +2344,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.42.0
^ permalink raw reply related [flat|nested] 42+ messages in thread* RE: [PATCH 00/11] Provide SEV-SNP support for running under an SVSM
2024-01-26 22:15 [PATCH 00/11] Provide SEV-SNP support for running under an SVSM Tom Lendacky
` (10 preceding siblings ...)
2024-01-26 22:16 ` [PATCH 11/11] x86/sev: Allow non-VMPL0 execution when an SVSM is present Tom Lendacky
@ 2024-02-12 10:40 ` Reshetova, Elena
2024-02-16 19:46 ` Tom Lendacky
11 siblings, 1 reply; 42+ messages in thread
From: Reshetova, Elena @ 2024-02-12 10:40 UTC (permalink / raw)
To: Tom Lendacky, linux-kernel@vger.kernel.org, x86@kernel.org
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Williams, Dan J,
Michael Roth, Ashish Kalra, Shutemov, Kirill, Dong, Eddie,
Jeremi Piotrowski
> 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
Hi Tom and everyone,
This patch set imo is a good opportunity to start a wider discussion on
SVSM-style confidential guests that we actually wanted to start anyhow
because TDX will need smth similar in the future.
So let me explain our thinking and try to align together here.
In addition to an existing notion of a Confidential Computing (CoCo) guest
both Intel and AMD define a concept that a CoCo guest can be further
subdivided/partitioned into different SW layers running with different
privileges. In the AMD Secure Encrypted Virtualization with Secure Nested
Paging (SEV-SNP) architecture this is called VM Permission Levels (VMPLs)
and in the Intel Trust Domain Extensions (TDX) architecture it is called
TDX Partitioning. The most privileged part of a CoCo guest is referred as
running at VMPL0 for AMD SEV-SNP and as L1 for Intel TDX Partitioning.
This privilege level has full control over the other components running
inside a CoCo guest, as well as some operations are only allowed to be
executed by the SW running at this privilege level. The assumption is that
this level is used for a Virtual Machine Monitor (VMM)/Hypervisor like KVM
and others or a lightweight Service Manager (SM) like coconut-SVSM [3].
The actual workload VM (together with its OS) is expected to be run in a
different privilege level (!VMPL0 in AMD case and L2 layer in Intel case).
Both architectures in our current understanding (please correct if this is
not true for AMD) allow for different workload VM options starting from
a fully unmodified legacy OS to a fully enabled/enlightened AMD SEV-SNP/
Intel TDX guest and anything in between. However, each workload guest
option requires a different level of implementation support from the most
privileged VMPL0/L1 layer as well as from the workload OS itself (running
at !VMPL0/L2) and also has different effects on overall performance and
other factors. Linux as being one of the workload OSes currently doesn’t
define a common notion or interfaces for such special type of CoCo guests
and there is a risk that each vendor can duplicate a lot of common concepts
inside ADM SEV-SNP or Intel TDX specific code. This is not the approach
Linux usually prefers and the vendor agnostic solution should be explored first.
So this is an attempt to start a joint discussion on how/what/if we can unify
in this space and following the recent lkml thread [1], it seems we need
to first clarify how we see this special !VMPL0/L2 guest and whenever we
can or need to define a common notion for it.
The following options are *theoretically* possible:
1. Keep the !VMPL0/L2 guest as unmodified AMD SEV-SNP/Intel TDX guest
and hide all complexity inside VMPL0/L1 VMM and/or respected Intel/AMD
architecture internal components. This likely creates additional complexity
in the implementation of VMPL0/L1 layer compared to other options below.
This option also doesn’t allow service providers to unify their interfaces
between AMD/Intel solutions, but requires their VMPL0/L1 layer to handle
differences between these guests. On a plus side this option requires no
changes in existing AMD SEV-SNP/Intel TDX Linux guest code to support
!VMPL0/L2 guest. The big open question we have here to AMD folks is
whenever it is architecturally feasible for you to support this case?
2. Keep it as Intel TDX/AMD SEV-SNP guest with some Linux guest internal
code logic to handle whenever it runs in L1 vs L2/VMPL0 vs !VMPL0.
This is essentially what this patch series is doing for AMD.
This option potentially creates many if statements inside respected Linux
implementation of these technologies to handle the differences, complicates
the code, and doesn’t allow service providers to unify their L1/VMPL0 code.
This option was also previously proposed for Intel TDX in this lkml thread [1]
and got a negative initial reception.
3. Keep it as a legacy non-CoCo guest. This option is very bad from
performance point of view since all I/O must be done via VMPL0/L1 layer
and it is considered infeasible/unacceptable by service providers
(performance of networking and disk is horrible). It also requires an
extensive implementation in VMPL0/L1 layer to support emulation of all devices.
4. Define a new guest abstraction/guest type that would be used for
!VMPL0/L2 guest. This allows in the future to define a unified L2 <-> L1/VMPL!0
<-> VMPL0 communication interface that underneath would use Intel
TDX/AMD SEV-SNP specified communication primitives. Out of existing Linux code,
this approach is followed to some initial degree by MSFT Hyper-V implementation [2].
It defines a new type of virtualized guest with its own initialization path and callbacks in
x86_platform.guest/hyper.*. However, in our understanding noone has yet
attempted to define a unified abstraction for such guest, as well as unified interface.
AMD SEV-SNP has defined in [4] a VMPL0 <--> !VMPL0 communication interface
which is AMD specific.
5. Anything else is missing?
References:
[1] https://lkml.org/lkml/2023/11/22/1089
[2] MSFT hyper-v implementation of AMD SEV-SNP !VMPL0 guest and TDX L2
partitioning guest:
https://elixir.bootlin.com/linux/latest/source/arch/x86/hyperv/ivm.c#L575
[3] https://github.com/coconut-svsm/svsm
[4] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 00/11] Provide SEV-SNP support for running under an SVSM
2024-02-12 10:40 ` [PATCH 00/11] Provide SEV-SNP support for running under an SVSM Reshetova, Elena
@ 2024-02-16 19:46 ` Tom Lendacky
2024-02-19 16:57 ` Shutemov, Kirill
2024-02-19 17:54 ` Reshetova, Elena
0 siblings, 2 replies; 42+ messages in thread
From: Tom Lendacky @ 2024-02-16 19:46 UTC (permalink / raw)
To: Reshetova, Elena, linux-kernel@vger.kernel.org, x86@kernel.org
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Williams, Dan J,
Michael Roth, Ashish Kalra, Shutemov, Kirill, Dong, Eddie,
Jeremi Piotrowski
On 2/12/24 04:40, Reshetova, Elena wrote:
>> 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
>
> Hi Tom and everyone,
>
> This patch set imo is a good opportunity to start a wider discussion on
> SVSM-style confidential guests that we actually wanted to start anyhow
> because TDX will need smth similar in the future.
> So let me explain our thinking and try to align together here.
>
> In addition to an existing notion of a Confidential Computing (CoCo) guest
> both Intel and AMD define a concept that a CoCo guest can be further
> subdivided/partitioned into different SW layers running with different
> privileges. In the AMD Secure Encrypted Virtualization with Secure Nested
> Paging (SEV-SNP) architecture this is called VM Permission Levels (VMPLs)
> and in the Intel Trust Domain Extensions (TDX) architecture it is called
> TDX Partitioning. The most privileged part of a CoCo guest is referred as
> running at VMPL0 for AMD SEV-SNP and as L1 for Intel TDX Partitioning.
> This privilege level has full control over the other components running
> inside a CoCo guest, as well as some operations are only allowed to be
> executed by the SW running at this privilege level. The assumption is that
> this level is used for a Virtual Machine Monitor (VMM)/Hypervisor like KVM
> and others or a lightweight Service Manager (SM) like coconut-SVSM [3].
I'm not sure what you mean about the level being used for a
VMM/hypervisor, since they are running in the host. Coconut-SVSM is
correct, since it is running within the guest context.
> The actual workload VM (together with its OS) is expected to be run in a
> different privilege level (!VMPL0 in AMD case and L2 layer in Intel case).
> Both architectures in our current understanding (please correct if this is
> not true for AMD) allow for different workload VM options starting from
> a fully unmodified legacy OS to a fully enabled/enlightened AMD SEV-SNP/
> Intel TDX guest and anything in between. However, each workload guest
I'm not sure about the "anything in between" aspect. I would think that if
the guest is enlightened it would be fully enlightened or not at all. It
would be difficult to try to decide what operations should be sent to the
SVSM to handle, and how that would occur if the guest OS is unaware of the
SVSM protocol to use. If it is aware of the protocol, then it would just
use it.
For the unenlighted guest, it sounds like more of a para-visor approach
being used where the guest wouldn't know that control was ever transferred
to the para-visor to handle the event. With SNP, that would be done
through a feature called Reflect-VC. But that means it is an all or
nothing action.
> option requires a different level of implementation support from the most
> privileged VMPL0/L1 layer as well as from the workload OS itself (running
> at !VMPL0/L2) and also has different effects on overall performance and
> other factors. Linux as being one of the workload OSes currently doesn’t
> define a common notion or interfaces for such special type of CoCo guests
> and there is a risk that each vendor can duplicate a lot of common concepts
> inside ADM SEV-SNP or Intel TDX specific code. This is not the approach
> Linux usually prefers and the vendor agnostic solution should be explored first.
>
> So this is an attempt to start a joint discussion on how/what/if we can unify
> in this space and following the recent lkml thread [1], it seems we need
> to first clarify how we see this special !VMPL0/L2 guest and whenever we
> can or need to define a common notion for it.
> The following options are *theoretically* possible:
>
> 1. Keep the !VMPL0/L2 guest as unmodified AMD SEV-SNP/Intel TDX guest
> and hide all complexity inside VMPL0/L1 VMM and/or respected Intel/AMD
> architecture internal components. This likely creates additional complexity
> in the implementation of VMPL0/L1 layer compared to other options below.
> This option also doesn’t allow service providers to unify their interfaces
> between AMD/Intel solutions, but requires their VMPL0/L1 layer to handle
> differences between these guests. On a plus side this option requires no
> changes in existing AMD SEV-SNP/Intel TDX Linux guest code to support
> !VMPL0/L2 guest. The big open question we have here to AMD folks is
> whenever it is architecturally feasible for you to support this case?
It is architecturally feasible to support this, but it would come with a
performance penalty. For SNP, all #VC exceptions would be routed back to
the HV, into the SVSM/para-visor to be processed, back to the HV and
finally back the guest. While we would expect some operations, such as
PVALIDATE, to have to make this kind of exchange, operations such as CPUID
or MSR accesses would suffer.
>
> 2. Keep it as Intel TDX/AMD SEV-SNP guest with some Linux guest internal
> code logic to handle whenever it runs in L1 vs L2/VMPL0 vs !VMPL0.
> This is essentially what this patch series is doing for AMD.
> This option potentially creates many if statements inside respected Linux
> implementation of these technologies to handle the differences, complicates
> the code, and doesn’t allow service providers to unify their L1/VMPL0 code.
> This option was also previously proposed for Intel TDX in this lkml thread [1]
> and got a negative initial reception.
I think the difference here is that the guest would still be identified as
an SNP guest and still use all of the memory encryption and #VC handling
it does today. It is just specific VMPL0-only operations that would need
to performed by the SVSM instead of by the guest.
>
> 3. Keep it as a legacy non-CoCo guest. This option is very bad from
> performance point of view since all I/O must be done via VMPL0/L1 layer
> and it is considered infeasible/unacceptable by service providers
> (performance of networking and disk is horrible). It also requires an
> extensive implementation in VMPL0/L1 layer to support emulation of all devices.
>
> 4. Define a new guest abstraction/guest type that would be used for
> !VMPL0/L2 guest. This allows in the future to define a unified L2 <-> L1/VMPL!0
> <-> VMPL0 communication interface that underneath would use Intel
> TDX/AMD SEV-SNP specified communication primitives. Out of existing Linux code,
> this approach is followed to some initial degree by MSFT Hyper-V implementation [2].
> It defines a new type of virtualized guest with its own initialization path and callbacks in
> x86_platform.guest/hyper.*. However, in our understanding noone has yet
> attempted to define a unified abstraction for such guest, as well as unified interface.
> AMD SEV-SNP has defined in [4] a VMPL0 <--> !VMPL0 communication interface
> which is AMD specific.
Can TDX create a new protocol within the SVSM that it could use?
Thanks,
Tom
>
> 5. Anything else is missing?
>
> References:
>
> [1] https://lkml.org/lkml/2023/11/22/1089
>
> [2] MSFT hyper-v implementation of AMD SEV-SNP !VMPL0 guest and TDX L2
> partitioning guest:
> https://elixir.bootlin.com/linux/latest/source/arch/x86/hyperv/ivm.c#L575
>
> [3] https://github.com/coconut-svsm/svsm
>
> [4] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
>
>
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 00/11] Provide SEV-SNP support for running under an SVSM
2024-02-16 19:46 ` Tom Lendacky
@ 2024-02-19 16:57 ` Shutemov, Kirill
2024-02-19 17:54 ` Reshetova, Elena
1 sibling, 0 replies; 42+ messages in thread
From: Shutemov, Kirill @ 2024-02-19 16:57 UTC (permalink / raw)
To: Tom Lendacky
Cc: Reshetova, Elena, linux-kernel@vger.kernel.org, x86@kernel.org,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Williams, Dan J,
Michael Roth, Ashish Kalra, Dong, Eddie, Jeremi Piotrowski
On Fri, Feb 16, 2024 at 01:46:41PM -0600, Tom Lendacky wrote:
> > 4. Define a new guest abstraction/guest type that would be used for
> > !VMPL0/L2 guest. This allows in the future to define a unified L2 <-> L1/VMPL!0
> > <-> VMPL0 communication interface that underneath would use Intel
> > TDX/AMD SEV-SNP specified communication primitives. Out of existing Linux code,
> > this approach is followed to some initial degree by MSFT Hyper-V implementation [2].
> > It defines a new type of virtualized guest with its own initialization path and callbacks in
> > x86_platform.guest/hyper.*. However, in our understanding noone has yet
> > attempted to define a unified abstraction for such guest, as well as unified interface.
> > AMD SEV-SNP has defined in [4] a VMPL0 <--> !VMPL0 communication interface
> > which is AMD specific.
>
> Can TDX create a new protocol within the SVSM that it could use?
Sure we can. But it contributes to virtualization zoo. The situation is
bad as it is. Ideally we would have a single SVSM guest type instead of
SVSM/TDX and SVSM/SEV.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply [flat|nested] 42+ messages in thread
* RE: [PATCH 00/11] Provide SEV-SNP support for running under an SVSM
2024-02-16 19:46 ` Tom Lendacky
2024-02-19 16:57 ` Shutemov, Kirill
@ 2024-02-19 17:54 ` Reshetova, Elena
2024-02-23 20:23 ` Tom Lendacky
1 sibling, 1 reply; 42+ messages in thread
From: Reshetova, Elena @ 2024-02-19 17:54 UTC (permalink / raw)
To: Tom Lendacky, linux-kernel@vger.kernel.org, x86@kernel.org
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Williams, Dan J,
Michael Roth, Ashish Kalra, Shutemov, Kirill, Dong, Eddie,
Jeremi Piotrowski
> Subject: Re: [PATCH 00/11] Provide SEV-SNP support for running under an SVSM
>
> On 2/12/24 04:40, Reshetova, Elena wrote:
> >> 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
> >
> > Hi Tom and everyone,
> >
> > This patch set imo is a good opportunity to start a wider discussion on
> > SVSM-style confidential guests that we actually wanted to start anyhow
> > because TDX will need smth similar in the future.
> > So let me explain our thinking and try to align together here.
> >
> > In addition to an existing notion of a Confidential Computing (CoCo) guest
> > both Intel and AMD define a concept that a CoCo guest can be further
> > subdivided/partitioned into different SW layers running with different
> > privileges. In the AMD Secure Encrypted Virtualization with Secure Nested
> > Paging (SEV-SNP) architecture this is called VM Permission Levels (VMPLs)
> > and in the Intel Trust Domain Extensions (TDX) architecture it is called
> > TDX Partitioning. The most privileged part of a CoCo guest is referred as
> > running at VMPL0 for AMD SEV-SNP and as L1 for Intel TDX Partitioning.
> > This privilege level has full control over the other components running
> > inside a CoCo guest, as well as some operations are only allowed to be
> > executed by the SW running at this privilege level. The assumption is that
> > this level is used for a Virtual Machine Monitor (VMM)/Hypervisor like KVM
> > and others or a lightweight Service Manager (SM) like coconut-SVSM [3].
>
> I'm not sure what you mean about the level being used for a
> VMM/hypervisor, since they are running in the host. Coconut-SVSM is
> correct, since it is running within the guest context.
What I meant is that this privilege level can be in principle used to host
any hypervisor/VMM also (not on the host, but in the guest).
For TDX we have pocs published in past that enabled
KVM running as L1 inside the guest.
>
> > The actual workload VM (together with its OS) is expected to be run in a
> > different privilege level (!VMPL0 in AMD case and L2 layer in Intel case).
> > Both architectures in our current understanding (please correct if this is
> > not true for AMD) allow for different workload VM options starting from
> > a fully unmodified legacy OS to a fully enabled/enlightened AMD SEV-SNP/
> > Intel TDX guest and anything in between. However, each workload guest
>
> I'm not sure about the "anything in between" aspect. I would think that if
> the guest is enlightened it would be fully enlightened or not at all. It
> would be difficult to try to decide what operations should be sent to the
> SVSM to handle, and how that would occur if the guest OS is unaware of the
> SVSM protocol to use. If it is aware of the protocol, then it would just
> use it.
Architecturally we can support guests that would fall somewhere in between of
a fully enlightened guest or legacy non-coco guest, albeit I am not saying it is a
way to go. A minimally enlightened guest can ask for a service
from SVSM on some things (i.e. attestation evidence) but behave fully unenlightened
when it comes to other things (like handling MMIO - will be emulated by SVSM or
forwarded to the host).
>
> For the unenlighted guest, it sounds like more of a para-visor approach
> being used where the guest wouldn't know that control was ever transferred
> to the para-visor to handle the event. With SNP, that would be done
> through a feature called Reflect-VC. But that means it is an all or
> nothing action.
Thank you for the SEV insights.
>
> > option requires a different level of implementation support from the most
> > privileged VMPL0/L1 layer as well as from the workload OS itself (running
> > at !VMPL0/L2) and also has different effects on overall performance and
> > other factors. Linux as being one of the workload OSes currently doesn’t
> > define a common notion or interfaces for such special type of CoCo guests
> > and there is a risk that each vendor can duplicate a lot of common concepts
> > inside ADM SEV-SNP or Intel TDX specific code. This is not the approach
> > Linux usually prefers and the vendor agnostic solution should be explored first.
> >
> > So this is an attempt to start a joint discussion on how/what/if we can unify
> > in this space and following the recent lkml thread [1], it seems we need
> > to first clarify how we see this special !VMPL0/L2 guest and whenever we
> > can or need to define a common notion for it.
> > The following options are *theoretically* possible:
> >
> > 1. Keep the !VMPL0/L2 guest as unmodified AMD SEV-SNP/Intel TDX guest
> > and hide all complexity inside VMPL0/L1 VMM and/or respected Intel/AMD
> > architecture internal components. This likely creates additional complexity
> > in the implementation of VMPL0/L1 layer compared to other options below.
> > This option also doesn’t allow service providers to unify their interfaces
> > between AMD/Intel solutions, but requires their VMPL0/L1 layer to handle
> > differences between these guests. On a plus side this option requires no
> > changes in existing AMD SEV-SNP/Intel TDX Linux guest code to support
> > !VMPL0/L2 guest. The big open question we have here to AMD folks is
> > whenever it is architecturally feasible for you to support this case?
>
> It is architecturally feasible to support this, but it would come with a
> performance penalty. For SNP, all #VC exceptions would be routed back to
> the HV, into the SVSM/para-visor to be processed, back to the HV and
> finally back the guest. While we would expect some operations, such as
> PVALIDATE, to have to make this kind of exchange, operations such as CPUID
> or MSR accesses would suffer.
Sorry for my ignorance, what the HV?
>
> >
> > 2. Keep it as Intel TDX/AMD SEV-SNP guest with some Linux guest internal
> > code logic to handle whenever it runs in L1 vs L2/VMPL0 vs !VMPL0.
> > This is essentially what this patch series is doing for AMD.
> > This option potentially creates many if statements inside respected Linux
> > implementation of these technologies to handle the differences, complicates
> > the code, and doesn’t allow service providers to unify their L1/VMPL0 code.
> > This option was also previously proposed for Intel TDX in this lkml thread [1]
> > and got a negative initial reception.
>
> I think the difference here is that the guest would still be identified as
> an SNP guest and still use all of the memory encryption and #VC handling
> it does today. It is just specific VMPL0-only operations that would need
> to performed by the SVSM instead of by the guest.
I see, you are saying less fragmentation overall, but overall I think this option
still reflects it also.
>
> >
> > 3. Keep it as a legacy non-CoCo guest. This option is very bad from
> > performance point of view since all I/O must be done via VMPL0/L1 layer
> > and it is considered infeasible/unacceptable by service providers
> > (performance of networking and disk is horrible). It also requires an
> > extensive implementation in VMPL0/L1 layer to support emulation of all
> devices.
> >
> > 4. Define a new guest abstraction/guest type that would be used for
> > !VMPL0/L2 guest. This allows in the future to define a unified L2 <-> L1/VMPL!0
> > <-> VMPL0 communication interface that underneath would use Intel
> > TDX/AMD SEV-SNP specified communication primitives. Out of existing Linux
> code,
> > this approach is followed to some initial degree by MSFT Hyper-V
> implementation [2].
> > It defines a new type of virtualized guest with its own initialization path and
> callbacks in
> > x86_platform.guest/hyper.*. However, in our understanding noone has yet
> > attempted to define a unified abstraction for such guest, as well as unified
> interface.
> > AMD SEV-SNP has defined in [4] a VMPL0 <--> !VMPL0 communication interface
> > which is AMD specific.
>
> Can TDX create a new protocol within the SVSM that it could use?
Kirill already commented on this, and the answer is of course we can, but imo we
need to see a bigger picture first. If we go with option 2 above, then coming with a
joint protocol is only limitedly useful because likely we wont be able to share the
code in the guest kernel. Ideally I think we want a common concept and a common
protocol that we can share in both guest kernel and coconut-svsm.
Btw, is continuing discussion here the best/preferred/efficient way forward? Or should we
setup a call with anyone who is interested in the topic to form a joint understanding
on what can be done here?
Best Regards,
Elena.
>
> Thanks,
> Tom
>
> >
> > 5. Anything else is missing?
> >
> > References:
> >
> > [1] https://lkml.org/lkml/2023/11/22/1089
> >
> > [2] MSFT hyper-v implementation of AMD SEV-SNP !VMPL0 guest and TDX L2
> > partitioning guest:
> > https://elixir.bootlin.com/linux/latest/source/arch/x86/hyperv/ivm.c#L575
> >
> > [3] https://github.com/coconut-svsm/svsm
> >
> > [4] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-
> docs/specifications/58019.pdf
> >
> >
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 00/11] Provide SEV-SNP support for running under an SVSM
2024-02-19 17:54 ` Reshetova, Elena
@ 2024-02-23 20:23 ` Tom Lendacky
2024-02-27 14:56 ` Reshetova, Elena
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lendacky @ 2024-02-23 20:23 UTC (permalink / raw)
To: Reshetova, Elena, linux-kernel@vger.kernel.org, x86@kernel.org
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Williams, Dan J,
Michael Roth, Ashish Kalra, Shutemov, Kirill, Dong, Eddie,
Jeremi Piotrowski
On 2/19/24 11:54, Reshetova, Elena wrote:
>> Subject: Re: [PATCH 00/11] Provide SEV-SNP support for running under an SVSM
>>
>> On 2/12/24 04:40, Reshetova, Elena wrote:
>>>> This series adds SEV-SNP support for running Linux under an Secure VM
>
> Sorry for my ignorance, what the HV?
HV == Hypervisor
>
>>
>
> Kirill already commented on this, and the answer is of course we can, but imo we
> need to see a bigger picture first. If we go with option 2 above, then coming with a
> joint protocol is only limitedly useful because likely we wont be able to share the
> code in the guest kernel. Ideally I think we want a common concept and a common
> protocol that we can share in both guest kernel and coconut-svsm.
>
> Btw, is continuing discussion here the best/preferred/efficient way forward? Or should we
> setup a call with anyone who is interested in the topic to form a joint understanding
> on what can be done here?
I'm not sure what the best way forward is since I'm not sure what a common
concept / common protocol would look like. If you feel we can effectively
describe it via email, then we should continue that, maybe on a new thread
under linux-coco. If not, then a call might be best.
Thanks,
Tom
>
> Best Regards,
> Elena.
>
>
>>
>> Thanks,
>> Tom
>>
>>>
>>> 5. Anything else is missing?
>>>
>>> References:
>>>
>>> [1] https://lkml.org/lkml/2023/11/22/1089
>>>
>>> [2] MSFT hyper-v implementation of AMD SEV-SNP !VMPL0 guest and TDX L2
>>> partitioning guest:
>>> https://elixir.bootlin.com/linux/latest/source/arch/x86/hyperv/ivm.c#L575
>>>
>>> [3] https://github.com/coconut-svsm/svsm
>>>
>>> [4] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-
>> docs/specifications/58019.pdf
>>>
>>>
^ permalink raw reply [flat|nested] 42+ messages in thread
* RE: [PATCH 00/11] Provide SEV-SNP support for running under an SVSM
2024-02-23 20:23 ` Tom Lendacky
@ 2024-02-27 14:56 ` Reshetova, Elena
0 siblings, 0 replies; 42+ messages in thread
From: Reshetova, Elena @ 2024-02-27 14:56 UTC (permalink / raw)
To: Tom Lendacky, linux-kernel@vger.kernel.org, x86@kernel.org
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Williams, Dan J,
Michael Roth, Ashish Kalra, Shutemov, Kirill, Dong, Eddie,
Jeremi Piotrowski
> > Kirill already commented on this, and the answer is of course we can, but imo
> we
> > need to see a bigger picture first. If we go with option 2 above, then coming
> with a
> > joint protocol is only limitedly useful because likely we wont be able to share
> the
> > code in the guest kernel. Ideally I think we want a common concept and a
> common
> > protocol that we can share in both guest kernel and coconut-svsm.
> >
> > Btw, is continuing discussion here the best/preferred/efficient way forward?
> Or should we
> > setup a call with anyone who is interested in the topic to form a joint
> understanding
> > on what can be done here?
>
> I'm not sure what the best way forward is since I'm not sure what a common
> concept / common protocol would look like. If you feel we can effectively
> describe it via email, then we should continue that, maybe on a new thread
> under linux-coco. If not, then a call might be best.
OK, let us first put some proposal from our side on how this potentially could
look like. It might be easier to have a discussion against smth more concrete.
Best Regards,
Elena.
>
> Thanks,
> Tom
>
> >
> > Best Regards,
> > Elena.
> >
> >
> >>
> >> Thanks,
> >> Tom
> >>
> >>>
> >>> 5. Anything else is missing?
> >>>
> >>> References:
> >>>
> >>> [1] https://lkml.org/lkml/2023/11/22/1089
> >>>
> >>> [2] MSFT hyper-v implementation of AMD SEV-SNP !VMPL0 guest and TDX L2
> >>> partitioning guest:
> >>> https://elixir.bootlin.com/linux/latest/source/arch/x86/hyperv/ivm.c#L575
> >>>
> >>> [3] https://github.com/coconut-svsm/svsm
> >>>
> >>> [4] https://www.amd.com/content/dam/amd/en/documents/epyc-
> technical-
> >> docs/specifications/58019.pdf
> >>>
> >>>
^ permalink raw reply [flat|nested] 42+ messages in thread