Provide SEV-SNP support for running under an SVSM
cover Provide SEV-SNP support for running under an SVSM
This series adds SEV-SNP support for running Linux under an Secure VM Service Module (SVSM) at a less privileged VM Privilege Level (VMPL). By running at a less priviledged VMPL, the SVSM can be used to provide services, e.g. a virtual TPM, for Linux within the SEV-SNP confidential VM (CVM) rather than trust such services from the hypervisor.
Currently, a Linux guest expects to run at the highest VMPL, VMPL0, and there are certain SNP related operations that require that VMPL level. Specifically, the PVALIDATE instruction and the RMPADJUST instruction when setting the VMSA attribute of a page (used when starting APs).
If Linux is to run at a less privileged VMPL, e.g. VMPL2, then it must use an SVSM (which is running at VMPL0) to perform the operations that it is no longer able to perform.
How Linux interacts with and uses the SVSM is documented in the SVSM specification [1] and the GHCB specification [2].
This series introduces support to run Linux under an SVSM. It consists of:
- Detecting the presence of an SVSM
- When not running at VMPL0, invoking the SVSM for page validation and VMSA page creation/deletion
- Adding a sysfs entry that specifies the Linux VMPL
- Modifying the sev-guest driver to use the VMPCK key associated with the Linux VMPL
- Expanding the config-fs TSM support to request attestation reports from the SVSM
- Detecting and allowing Linux to run in a VMPL other than 0 when an SVSM is present
The series is based off of and tested against the tip tree:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master
b0c57a7002b0 ("Merge branch into tip/master: 'x86/cpu'")
[1] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
[2] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
---
Tom Lendacky (11):
x86/sev: Rename snp_init() in the boot/compressed/sev.c file x86/sev: Make the VMPL0 checking function more generic x86/sev: Check for the presence of an SVSM in the SNP Secrets page x86/sev: Use kernel provided SVSM Calling Areas x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0 x86/sev: Use the SVSM to create a vCPU when not in VMPL0 x86/sev: Provide SVSM discovery support
x86/sev: Provide guest VMPL level to userspace
virt: sev-guest: Choose the VMPCK key based on executing VMPL x86/sev: Extend the config-fs attestation support for an SVSM x86/sev: Allow non-VMPL0 execution when an SVSM is present
Documentation/ABI/testing/configfs-tsm | 55 +++ arch/x86/boot/compressed/sev.c | 253 ++++++++------ arch/x86/include/asm/msr-index.h | 2 + arch/x86/include/asm/sev-common.h | 18 + arch/x86/include/asm/sev.h | 114 ++++++- arch/x86/include/uapi/asm/svm.h | 1 + arch/x86/kernel/sev-shared.c | 338 ++++++++++++++++++- arch/x86/kernel/sev.c | 426 +++++++++++++++++++++--- arch/x86/mm/mem_encrypt_amd.c | 8 +- drivers/virt/coco/sev-guest/sev-guest.c | 147 +++++++- drivers/virt/coco/tsm.c | 95 +++++- include/linux/tsm.h | 11 + 12 files changed, 1300 insertions(+), 168 deletions(-)
Signature · 1 line
2.42.0
PATCH 1/11 x86/sev: Rename snp_init() in the boot/compressed/sev.c file
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.
--- arch/x86/boot/compressed/sev.c | 162 ++++++++++++++++----------------- 1 file changed, 81 insertions(+), 81 deletions(-)
arch/x86/boot/compressed/sev.c +81 -81
@@ -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) {/*
Signature · 1 line
2.42.0
Re: [PATCH 01/11] x86/sev: Rename snp_init() in the boot/compressed/sev.c file
Quoted 196 lines · Tom Lendacky
The
snp_init()function is local to theboot/compressed/sev.cfile and is not called from outside of the file. Change the name so that it is not tied to the function definition inarch/x86/include/asm/sev.h. Move the renamedsnp_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 inarch/x86/kernel/sev.cto be changed without having to make the same change inboot/compressed/sev.c.Signed-off-by Tom Lendacky <[email protected]>--- arch/x86/boot/compressed/sev.c | 162 ++++++++++++++++----------------- 1 file changed, 81 insertions(+), 81 deletions(-)arch/x86/boot/compressed/sev.c +81
-71@@ -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); -
arch/x86/boot/compressed/sev.c u64 sev_get_status(void) · line 608
Quoted 10 lines
arch/x86/boot/compressed/sev.c +0
-10-/* -* 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.
Quoted 7 lines
arch/x86/boot/compressed/sev.c +0
-1void sev_prep_identity_maps (unsigned long top_level_pgt) {/* -- 2.42.0
Signature · 1 line
-Dionna Glaze, PhD (she/her)
Re: [PATCH 01/11] x86/sev: Rename snp_init() in the boot/compressed/sev.c file
Quoted 16 lines · Dionna Amalie Glaze
Quoted 15 lines · Tom Lendacky
The
snp_init()function is local to theboot/compressed/sev.cfile and is not called from outside of the file. Change the name so that it is not tied to the function definition inarch/x86/include/asm/sev.h. Move the renamedsnp_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 inarch/x86/kernel/sev.cto be changed without having to make the same change inboot/compressed/sev.c.Signed-off-by Tom Lendacky <[email protected]>--- arch/x86/boot/compressed/sev.c | 162 ++++++++++++++++----------------- 1 file changed, 81 insertions(+), 81 deletions(-)
Quoted 8 lines
arch/x86/boot/compressed/sev.c
Quoted 4 lines
arch/x86/boot/compressed/sev.c +0
-0Did 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
Quoted 10 lines
Quoted 8 lines
void
sev_prep_identity_maps(unsigned long top_level_pgt){ /*--
2.42.0
PATCH 2/11 x86/sev: Make the VMPL0 checking function more generic
In reply to Tom LendackyCurrently, 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.
--- arch/x86/boot/compressed/sev.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-)
arch/x86/boot/compressed/sev.c +6 -7
@@ -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 ))
Signature · 1 line
2.42.0
PATCH 3/11 x86/sev: Check for the presence of an SVSM in the SNP Secrets page
In reply to Tom LendackyDuring 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.
--- 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(-)
arch/x86/boot/compressed/sev.c +17 -18
@@ -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
arch/x86/include/asm/sev-common.h +4 -0
@@ -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)
arch/x86/include/asm/sev.h +24 -1
@@ -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 );
arch/x86/kernel/sev-shared.c +64 -0
73 lines not on this page · raw message
arch/x86/kernel/sev.c +16 -0
@@ -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.
Signature · 1 line
2.42.0
PATCH 4/11 x86/sev: Use kernel provided SVSM Calling Areas
In reply to Tom LendackyThe 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.
--- 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(-)
arch/x86/include/asm/sev-common.h +13 -0
@@ -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
arch/x86/include/asm/sev.h +32 -0
@@ -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 snvoid 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 *instatic 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
arch/x86/include/uapi/asm/svm.h +1 -0
@@ -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) \
arch/x86/kernel/sev-shared.c +93 -1
106 lines not on this page · raw message
arch/x86/kernel/sev.c +174 -33
275 lines not on this page · raw message
arch/x86/mm/mem_encrypt_amd.c +7 -1
@@ -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 <[email protected]> */
@@ -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 )
Signature · 1 line
2.42.0
Re: [PATCH 04/11] x86/sev: Use kernel provided SVSM Calling Areas
Quoted 6 lines · Tom Lendacky
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_CAAcall.
REMAP_CA, not CAA.
Quoted 70 lines
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 <[email protected]>--- 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(-)arch/x86/include/asm/sev-common.h +13
-0@@ -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 0x081arch/x86/include/asm/sev.h +18
-0@@ -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;
arch/x86/include/asm/sev.h struct svsm_ca { · line 193
Quoted 10 lines
arch/x86/include/asm/sev.h +10
-0+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) ?
Quoted 370 lines
arch/x86/include/asm/sev.h +4
-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 snvoid 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 *instatic 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 arch/x86/include/uapi/asm/svm.h +1
-0@@ -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) \arch/x86/kernel/sev-shared.c +93
-1@@ -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_ctxtreturn 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 +*/ + asmvolatile ("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,arch/x86/kernel/sev.c +129
-27@@ -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 sireturn 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. +*/
arch/x86/kernel/sev.c static __init struct cc_blob_sev_info *find_cc_blob(struct boot_params *bp) · line 2208
Quoted 10 lines
arch/x86/kernel/sev.c +10
-0+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
Quoted 85 lines
arch/x86/kernel/sev.c +35
-6+* RIP-relative addressing. +*/ + asmvolatile ("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; +}arch/x86/mm/mem_encrypt_amd.c +7
-2@@ -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 <[email protected]> */ @@ -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
Signature · 1 line
-Dionna Glaze, PhD (she/her)
Re: [PATCH 04/11] x86/sev: Use kernel provided SVSM Calling Areas
Quoted 9 lines · Dionna Amalie Glaze
Quoted 6 lines · Tom Lendacky
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_CAAcall.
REMAP_CA, not CAA.
Will fix.
Quoted 40 lines
Quoted 25 lines
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 <[email protected]>--- 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(-)arch/x86/include/asm/sev-common.h +0
-0arch/x86/include/asm/sev-common.h
Quoted 3 lines
arch/x86/include/asm/sev-common.h +2
-0+ +#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))
#defineSVSM_CORE_PROTOCOL0
#defineSVSM_ATTESTATION_PROTOCOL1
#defineSVSM_VTPM_PROTOCOL2And then
Quoted 8 lines
#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
#defineSVSM_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
Quoted 1 line
PATCH 5/11 x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0
In reply to Tom LendackyThe 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.
--- 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(-)
arch/x86/boot/compressed/sev.c +38 -4
@@ -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
arch/x86/include/asm/sev.h +22 -0
@@ -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);
arch/x86/kernel/sev-shared.c +175 -1
194 lines not on this page · raw message
arch/x86/kernel/sev.c +12 -13
@@ -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 ;
Signature · 1 line
2.42.0
Re: [PATCH 05/11] x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0
Quoted 50 lines · Tom Lendacky
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_PVALIDATEcall 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(). Thepvalidate_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 <[email protected]>--- 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(-)arch/x86/boot/compressed/sev.c +14
-0@@ -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;
arch/x86/boot/compressed/sev.c static bool fault_in_kernel_space(unsigned long address) · line 161
Quoted 10 lines
arch/x86/boot/compressed/sev.c +10
-0+ +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?
Quoted 30 lines
arch/x86/boot/compressed/sev.c +8
-4+ +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)
arch/x86/boot/compressed/sev.c void sev_es_shutdown_ghcb(void) · line 293
Quoted 5 lines
arch/x86/boot/compressed/sev.c +2
-0@@ -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?
Quoted 306 lines
arch/x86/boot/compressed/sev.c +4
-0+* 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 arch/x86/include/asm/sev.h +22
-0@@ -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);arch/x86/kernel/sev-shared.c +175
-1@@ -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 ;arch/x86/kernel/sev.c +12
-14@@ -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 ; --
Quoted 3 lines
2.42.0
--
-Dionna Glaze, PhD (she/her)
Re: [PATCH 05/11] x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0
Quoted 27 lines · Dionna Amalie Glaze
Quoted 25 lines · Tom Lendacky
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_PVALIDATEcall 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(). Thepvalidate_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 <[email protected]>--- 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(-)arch/x86/boot/compressed/sev.c +0
-0
Quoted 16 lines
Quoted 4 lines
arch/x86/boot/compressed/sev.c +4
-0+static int svsm_protocol (struct svsm_call *call) +{ +struct ghcb *ghcb; +int ret;arch/x86/boot/compressed/sev.c static bool fault_in_kernel_space(unsigned long address) · line 161
Quoted 10 lines
arch/x86/boot/compressed/sev.c +10
-0+ +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.
Quoted 11 lines
arch/x86/boot/compressed/sev.c void sev_es_shutdown_ghcb(void) · line 293
Quoted 9 lines
void
snp_set_page_private(unsigned long paddr)arch/x86/boot/compressed/sev.c +2
-0@@ -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
Quoted 1 line
PATCH 6/11 x86/sev: Use the SVSM to create a vCPU when not in VMPL0
In reply to Tom LendackyUsing 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.
--- arch/x86/include/asm/sev.h | 2 ++ arch/x86/kernel/sev.c | 60 +++++++++++++++++++++++++++++++++----- 2 files changed, 54 insertions(+), 8 deletions(-)
arch/x86/include/asm/sev.h +2 -0
@@ -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);
arch/x86/kernel/sev.c +52 -8
119 lines not on this page · raw message
Signature · 1 line
2.42.0
PATCH 7/11 x86/sev: Provide SVSM discovery support
In reply to Tom LendackyThe 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.
--- 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(+)
arch/x86/include/asm/msr-index.h +2 -0
@@ -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
arch/x86/kernel/sev-shared.c +4 -0
@@ -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 ;
arch/x86/kernel/sev.c +17 -0
@@ -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 ;
Signature · 1 line
2.42.0
Re: [PATCH 07/11] x86/sev: Provide SVSM discovery support
Quoted 7 lines · Tom Lendacky
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
0x8000001fCPUID 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.
Quoted 40 lines
For the MSR support, new reserved MSR
0xc001f000has 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 <[email protected]>--- 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(+)arch/x86/include/asm/msr-index.h +2
-0@@ -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 0xc00102b1arch/x86/kernel/sev-shared.c +4
-0@@ -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 ;
Re: [PATCH 07/11] x86/sev: Provide SVSM discovery support
Quoted 4 lines · Jeremi Piotrowski
Quoted 3 lines · Tom Lendacky
The SVSM specification documents an alternative method of discovery for the SVSM using a reserved CPUID bit and a reserved MSR.
Quoted 8 lines
Quoted 4 lines
For the CPUID support, the #VC handler of an SEV-SNP guest should modify the returned value in the EAX register for the
0x8000001fCPUID 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.
Quoted 2 lines
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
Quoted 41 lines
Quoted 41 lines
For the MSR support, new reserved MSR
0xc001f000has 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 <[email protected]>--- 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(+)arch/x86/include/asm/msr-index.h +2
-0@@ -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 0xc00102b1arch/x86/kernel/sev-shared.c +4
-0@@ -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 ;
PATCH 8/11 x86/sev: Provide guest VMPL level to userspace
In reply to Tom LendackyRequesting 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.
--- arch/x86/kernel/sev.c | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+)
arch/x86/kernel/sev.c +37 -0
@@ -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);
Signature · 1 line
2.42.0
Re: [PATCH 08/11] x86/sev: Provide guest VMPL level to userspace
Quoted 10 lines · Tom Lendacky
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?
Quoted 55 lines
Signed-off-by Tom Lendacky <[email protected]>--- arch/x86/kernel/sev.c | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+)arch/x86/kernel/sev.c +37
-1@@ -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
Signature · 1 line
-Dionna Glaze, PhD (she/her)
Re: [PATCH 08/11] x86/sev: Provide guest VMPL level to userspace
Quoted 6 lines · Dionna Amalie Glaze
Quoted 5 lines · Tom Lendacky
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.
Quoted 8 lines
Quoted 5 lines
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_floorin/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
Quoted 1 line
PATCH 9/11 virt: sev-guest: Choose the VMPCK key based on executing VMPL
In reply to Tom LendackyCurrently, 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.
--- 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(-)
arch/x86/include/asm/sev.h +2 -0
@@ -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
arch/x86/kernel/sev.c +6 -0
@@ -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 ,
drivers/virt/coco/sev-guest/sev-guest.c +7 -3
@@ -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 <[email protected]> */
@@ -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) {
Signature · 1 line
2.42.0
PATCH 10/11 x86/sev: Extend the config-fs attestation support for an SVSM
In reply to Tom LendackyWhen 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.
--- 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(-)
Documentation/ABI/testing/configfs-tsm +55 -0
@@ -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: [email protected] +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: [email protected] 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: [email protected] +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: [email protected] +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: [email protected] +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
arch/x86/include/asm/sev.h +30 -1
@@ -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 ; }
arch/x86/kernel/sev.c +50 -0
56 lines not on this page · raw message
drivers/virt/coco/sev-guest/sev-guest.c +137 -0
149 lines not on this page · raw message
drivers/virt/coco/tsm.c +93 -2
157 lines not on this page · raw message
include/linux/tsm.h +11 -0
@@ -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; };/**
Signature · 1 line
2.42.0
Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 11 lines · Tom Lendacky
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.
Quoted 11 lines
- '
service_guid' (input)
Used for requesting the attestation of a single service within the SVSM. A null GUID implies that theSVSM_ATTEST_SERVICEScall should be used to request the attestation report. A non-null GUID implies that theSVSM_ATTEST_SINGLE_SERVICEcall should be used.- '
service_version' (input)
Used with theSVSM_ATTEST_SINGLE_SERVICEcall, 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.
Quoted 4 lines
- '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.
Quoted 583 lines
Signed-off-by Tom Lendacky <[email protected]>--- 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(-)Documentation/ABI/testing/configfs-tsm +55
-0@@ -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: [email protected] +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: [email protected] 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: [email protected] +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: [email protected] +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: [email protected] +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.pdfarch/x86/include/asm/sev.h +30
-1@@ -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 ; }arch/x86/kernel/sev.c +50
-0@@ -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;drivers/virt/coco/sev-guest/sev-guest.c +137
-0@@ -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 ;drivers/virt/coco/tsm.c +93
-2@@ -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);include/linux/tsm.h +11
-1@@ -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
Signature · 1 line
-Dionna Glaze, PhD (she/her)
Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 9 lines · Dionna Amalie Glaze
Quoted 8 lines · Tom Lendacky
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:
Quoted 6 lines
Quoted 3 lines
- '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.
Quoted 4 lines
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.
Quoted 25 lines
Quoted 8 lines
- '
service_guid' (input)
Used for requesting the attestation of a single service within the SVSM. A null GUID implies that theSVSM_ATTEST_SERVICEScall should be used to request the attestation report. A non-null GUID implies that theSVSM_ATTEST_SINGLE_SERVICEcall should be used.Quoted 4 lines
- '
service_version' (input)
Used with theSVSM_ATTEST_SINGLE_SERVICEcall, 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.
Quoted 3 lines
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/[email protected]/
The changes you're requesting would require a new version of the spec and updates to the protocol.
Quoted 8 lines
Quoted 5 lines
- '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
Quoted 586 lines
Quoted 584 lines
Signed-off-by Tom Lendacky <[email protected]>--- 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(-)Documentation/ABI/testing/configfs-tsm +55
-0@@ -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: [email protected] +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: [email protected] 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: [email protected] +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: [email protected] +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: [email protected] +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.pdfarch/x86/include/asm/sev.h +30
-1@@ -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 ; }arch/x86/kernel/sev.c +50
-0@@ -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;drivers/virt/coco/sev-guest/sev-guest.c +137
-0@@ -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 ;drivers/virt/coco/tsm.c +93
-2@@ -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);include/linux/tsm.h +11
-1@@ -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
Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 60 lines · Tom Lendacky
Quoted 9 lines · Dionna Amalie Glaze
Quoted 8 lines · Tom Lendacky
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:
Quoted 6 lines
Quoted 3 lines
- '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.
Quoted 4 lines
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_floorwould need to stay at zero.Quoted 25 lines
Quoted 8 lines
- '
service_guid' (input)
Used for requesting the attestation of a single service within the SVSM. A null GUID implies that theSVSM_ATTEST_SERVICEScall should be used to request the attestation report. A non-null GUID implies that theSVSM_ATTEST_SINGLE_SERVICEcall should be used.Quoted 4 lines
- '
service_version' (input)
Used with theSVSM_ATTEST_SINGLE_SERVICEcall, 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.
Quoted 9 lines
Quoted 3 lines
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:
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?
Quoted 3 lines
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."?
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
- 'manifestblob' (output)
Used to return the service manifest associated with the attestation report.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 590 lines
Thanks,
TomQuoted 586 lines
Quoted 584 lines
Signed-off-by Tom Lendacky <[email protected]>--- 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(-)Documentation/ABI/testing/configfs-tsm +55
-0@@ -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: [email protected] +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: [email protected] 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: [email protected] +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: [email protected] +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: [email protected] +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.pdfarch/x86/include/asm/sev.h +30
-1@@ -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 ; }arch/x86/kernel/sev.c +50
-0@@ -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;drivers/virt/coco/sev-guest/sev-guest.c +137
-0@@ -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 ;drivers/virt/coco/tsm.c +93
-2@@ -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);include/linux/tsm.h +11
-1@@ -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
Signature · 1 line
-Dionna Glaze, PhD (she/her)
Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 68 lines · Dionna Amalie Glaze
Quoted 67 lines · Tom Lendacky
Quoted 9 lines · Dionna Amalie Glaze
Quoted 8 lines · Tom Lendacky
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:
Quoted 6 lines
Quoted 3 lines
- '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.
Quoted 4 lines
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_floorwould need to stay at zero.Quoted 25 lines
Quoted 8 lines
- '
service_guid' (input)
Used for requesting the attestation of a single service within the SVSM. A null GUID implies that theSVSM_ATTEST_SERVICEScall should be used to request the attestation report. A non-null GUID implies that theSVSM_ATTEST_SINGLE_SERVICEcall should be used.Quoted 4 lines
- '
service_version' (input)
Used with theSVSM_ATTEST_SINGLE_SERVICEcall, 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.Quoted 3 lines
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:
Quoted 8 lines
Quoted 2 lines
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:
Quoted 10 lines
Quoted 4 lines
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
Quoted 21 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
- 'manifestblob' (output)
Used to return the service manifest associated with the attestation report.Quoted 6 lines
Quoted 2 lines
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.
Quoted 5 lines
Thanks,
TomQuoted 1 line
Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
In reply to Tom LendackyQuoted 48 lines · Tom Lendacky
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 theSVSM_ATTEST_SERVICEScall should be used to request the attestation report. A non-null GUID implies that theSVSM_ATTEST_SINGLE_SERVICEcall should be used.- '
service_version' (input)
Used with theSVSM_ATTEST_SINGLE_SERVICEcall, 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 <[email protected]>--- 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(-)Documentation/ABI/testing/configfs-tsm +4
-0@@ -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: [email protected]
Documentation/ABI/testing/configfs-tsm Description: · line 47
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +10
-0+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.
Quoted 7 lines
Documentation/ABI/testing/configfs-tsm +1
-0+ What: /sys/kernel/config/tsm/report/$name/provider Date: September, 2023 KernelVersion: v6.7@@ -80,3 +95,43 @@ Contact: [email protected] Description: (RO) Indicates the minimum permissible value that can be written
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 106
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +9
-0to @privlevel. + +What: /sys/kernel/config/tsm/report/$name/svsm +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +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.
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 109
Quoted 3 lines
Documentation/ABI/testing/configfs-tsm +3
-0+ 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.
Quoted 6 lines
Documentation/ABI/testing/configfs-tsm +6
-0+ +What: /sys/kernel/config/tsm/report/$name/service_guid +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +Description:
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 125
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +10
-0+ (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?
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 137
Quoted 12 lines
Documentation/ABI/testing/configfs-tsm +12
-0+ +What: /sys/kernel/config/tsm/report/$name/service_version +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +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?
Quoted 93 lines
arch/x86/include/asm/sev.h +30
-1@@ -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 ; }arch/x86/kernel/sev.c +22
-0@@ -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)
arch/x86/kernel/sev.c static int __init init_sev_config(char *str) · line 2412
Quoted 10 lines
arch/x86/kernel/sev.c +10
-0+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?
Quoted 99 lines
arch/x86/kernel/sev.c +18
-0+ +/* +* 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;drivers/virt/coco/sev-guest/sev-guest.c +70
-0@@ -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; + }
drivers/virt/coco/sev-guest/sev-guest.c struct snp_msg_cert_entry { · line 865
Quoted 10 lines
drivers/virt/coco/sev-guest/sev-guest.c +10
-0+ +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?
Quoted 40 lines
drivers/virt/coco/sev-guest/sev-guest.c +40
-0+ } + + 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;
drivers/virt/coco/sev-guest/sev-guest.c struct snp_msg_cert_entry { · line 915
Quoted 10 lines
drivers/virt/coco/sev-guest/sev-guest.c +10
-0+ +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.
Quoted 52 lines
drivers/virt/coco/sev-guest/sev-guest.c +7
-0+ +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 ;drivers/virt/coco/tsm.c +12
-1@@ -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;
drivers/virt/coco/tsm.c static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg, · line 142
Quoted 10 lines
drivers/virt/coco/tsm.c +10
-0+ +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.
Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 109 lines · Dan Williams
Quoted 48 lines · Tom Lendacky
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 theSVSM_ATTEST_SERVICEScall should be used to request the attestation report. A non-null GUID implies that theSVSM_ATTEST_SINGLE_SERVICEcall should be used.- '
service_version' (input)
Used with theSVSM_ATTEST_SINGLE_SERVICEcall, 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 <[email protected]>--- 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(-)Documentation/ABI/testing/configfs-tsm +4
-0@@ -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: [email protected]Documentation/ABI/testing/configfs-tsm Description: · line 47
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +10
-0+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.pdfI wish configfs had better dynamic visibility so that this could be hidden when not active... oh well.
Quoted 7 lines
Documentation/ABI/testing/configfs-tsm +1
-0+ What: /sys/kernel/config/tsm/report/$name/provider Date: September, 2023 KernelVersion: v6.7@@ -80,3 +95,43 @@ Contact: [email protected] Description: (RO) Indicates the minimum permissible value that can be writtenDocumentation/ABI/testing/configfs-tsm Contact: [email protected] · line 106
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +9
-0to @privlevel. + +What: /sys/kernel/config/tsm/report/$name/svsm +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +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 valueJust 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.
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 109
Quoted 3 lines
Documentation/ABI/testing/configfs-tsm +3
-0+ 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.pdfSo 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_guidconcept, or kernel gets lucky and a de-facto standard heads off proliferation here.Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +10
-0+ +What: /sys/kernel/config/tsm/report/$name/service_guid +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +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
Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 125
Quoted 6 lines
Documentation/ABI/testing/configfs-tsm +6
-0+ 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.pdfGiven 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?
Quoted 15 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 137
Quoted 13 lines
Documentation/ABI/testing/configfs-tsm +12
-0+ +What: /sys/kernel/config/tsm/report/$name/service_version +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +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.pdfPerhaps document that version 1 is assumed and is always compatible?
Quoted 1 line
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.
Quoted 338 lines
Quoted 94 lines
arch/x86/include/asm/sev.h +30
-1@@ -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 ; }arch/x86/kernel/sev.c +22
-0@@ -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)arch/x86/kernel/sev.c static int __init init_sev_config(char *str) · line 2412
Quoted 10 lines
arch/x86/kernel/sev.c +10
-0+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?Quoted 99 lines
arch/x86/kernel/sev.c +18
-0+ +/* +* 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;drivers/virt/coco/sev-guest/sev-guest.c +70
-0@@ -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; + }drivers/virt/coco/sev-guest/sev-guest.c struct snp_msg_cert_entry { · line 865
Quoted 10 lines
drivers/virt/coco/sev-guest/sev-guest.c +10
-0+ +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?
Quoted 40 lines
drivers/virt/coco/sev-guest/sev-guest.c +40
-0+ } + + 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;drivers/virt/coco/sev-guest/sev-guest.c struct snp_msg_cert_entry { · line 915
Quoted 10 lines
drivers/virt/coco/sev-guest/sev-guest.c +10
-0+ +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.hhelpers can be a recipe for confusion, but this looks clean to me.Quoted 52 lines
drivers/virt/coco/sev-guest/sev-guest.c +7
-0+ +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 ;drivers/virt/coco/tsm.c +12
-1@@ -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;drivers/virt/coco/tsm.c static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg, · line 142
Quoted 10 lines
drivers/virt/coco/tsm.c +10
-0+ +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.
Signature · 2 lines
Sathyanarayanan Kuppuswamy Linux Kernel Developer
Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 120 lines · Sathyanarayanan
Quoted 109 lines · Dan Williams
Quoted 48 lines · Tom Lendacky
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 theSVSM_ATTEST_SERVICEScall should be used to request the attestation report. A non-null GUID implies that theSVSM_ATTEST_SINGLE_SERVICEcall should be used.- '
service_version' (input)
Used with theSVSM_ATTEST_SINGLE_SERVICEcall, 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 <[email protected]>--- 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(-)Documentation/ABI/testing/configfs-tsm +4
-0@@ -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: [email protected]Documentation/ABI/testing/configfs-tsm Description: · line 47
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +10
-0+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.pdfI wish configfs had better dynamic visibility so that this could be hidden when not active... oh well.
Quoted 7 lines
Documentation/ABI/testing/configfs-tsm +1
-0+ What: /sys/kernel/config/tsm/report/$name/provider Date: September, 2023 KernelVersion: v6.7@@ -80,3 +95,43 @@ Contact: [email protected] Description: (RO) Indicates the minimum permissible value that can be writtenDocumentation/ABI/testing/configfs-tsm Contact: [email protected] · line 106
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +9
-0to @privlevel. + +What: /sys/kernel/config/tsm/report/$name/svsm +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +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 valueJust 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.
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 109
Quoted 3 lines
Documentation/ABI/testing/configfs-tsm +3
-0+ 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.pdfSo 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_guidconcept, or kernel gets lucky and a de-facto standard heads off proliferation here.Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +10
-0+ +What: /sys/kernel/config/tsm/report/$name/service_guid +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +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 servicesQuoted 8 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 125
Quoted 6 lines
Documentation/ABI/testing/configfs-tsm +6
-0+ 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.pdfGiven the small number of service GUIDs so far perhaps save someone the URL fetch and list it here?
Quoted 2 lines
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.
Quoted 16 lines
Quoted 16 lines
Quoted 4 lines
Documentation/ABI/testing/configfs-tsm +2
-0+ +What: /sys/kernel/config/tsm/report/$name/service_versionDocumentation/ABI/testing/configfs-tsm Contact: [email protected] · line 137
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +10
-0+Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +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.pdfPerhaps document that version 1 is assumed and is always compatible?
Quoted 4 lines
Quoted 1 line
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
Quoted 2 lines
Quoted 2 lines
Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
In reply to Dan WilliamsQuoted 54 lines · Dan Williams
Quoted 53 lines · Tom Lendacky
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 theSVSM_ATTEST_SERVICEScall should be used to request the attestation report. A non-null GUID implies that theSVSM_ATTEST_SINGLE_SERVICEcall should be used.- '
service_version' (input)
Used with theSVSM_ATTEST_SINGLE_SERVICEcall, 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 <[email protected]>--- 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(-)Documentation/ABI/testing/configfs-tsm +9
-0@@ -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: [email protected] +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. +
Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Description: · line 47
Quoted 5 lines
Documentation/ABI/testing/configfs-tsm +5
-0+ 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.pdfI 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?
Quoted 24 lines
Quoted 8 lines
Documentation/ABI/testing/configfs-tsm +1
-0+ What: /sys/kernel/config/tsm/report/$name/provider Date: September, 2023 KernelVersion: v6.7@@ -80,3 +95,43 @@ Contact: [email protected] Description: (RO) Indicates the minimum permissible value that can be writtenDocumentation/ABI/testing/configfs-tsm Contact: [email protected] · line 106
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +9
-0to @privlevel. + +What: /sys/kernel/config/tsm/report/$name/svsm +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +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 valueJust 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.
Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 109
Quoted 3 lines
Documentation/ABI/testing/configfs-tsm +3
-0+ 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.pdfSo 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.
Quoted 7 lines
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_guidconcept, 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.
Quoted 12 lines
Quoted 12 lines
Documentation/ABI/testing/configfs-tsm +11
-0+ +What: /sys/kernel/config/tsm/report/$name/service_guid +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +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
Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 125
Quoted 5 lines
Documentation/ABI/testing/configfs-tsm +5
-0+ 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.pdfGiven 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.
Quoted 15 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 137
Quoted 13 lines
Documentation/ABI/testing/configfs-tsm +12
-0+ +What: /sys/kernel/config/tsm/report/$name/service_version +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +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.pdfPerhaps document that version 1 is assumed and is always compatible?
Can do.
Quoted 2 lines
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.
Quoted 99 lines
Quoted 99 lines
arch/x86/include/asm/sev.h +30
-1@@ -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 ; }arch/x86/kernel/sev.c +27
-0@@ -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 ();
Quoted 8 lines
arch/x86/kernel/sev.c static int __init init_sev_config(char *str) · line 2412
Quoted 5 lines
arch/x86/kernel/sev.c +5
-0+ + 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.
Quoted 107 lines
Quoted 107 lines
arch/x86/kernel/sev.c +18
-0+ +/* +* 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;drivers/virt/coco/sev-guest/sev-guest.c +77
-0@@ -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 */
Quoted 8 lines
drivers/virt/coco/sev-guest/sev-guest.c struct snp_msg_cert_entry { · line 865
Quoted 3 lines
drivers/virt/coco/sev-guest/sev-guest.c +3
-0+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.
Quoted 112 lines
Quoted 41 lines
drivers/virt/coco/sev-guest/sev-guest.c +40
-0+ } + + 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;drivers/virt/coco/sev-guest/sev-guest.c struct snp_msg_cert_entry { · line 915
Quoted 10 lines
drivers/virt/coco/sev-guest/sev-guest.c +10
-0+ +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.hhelpers can be a recipe for confusion, but this looks clean to me.Quoted 57 lines
drivers/virt/coco/sev-guest/sev-guest.c +7
-0+ +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 ;drivers/virt/coco/tsm.c +17
-1@@ -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;
Quoted 8 lines
drivers/virt/coco/tsm.c static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg, · line 142
Quoted 5 lines
drivers/virt/coco/tsm.c +5
-0+ 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
Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 64 lines · Tom Lendacky
Quoted 54 lines · Dan Williams
Quoted 53 lines · Tom Lendacky
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 theSVSM_ATTEST_SERVICEScall should be used to request the attestation report. A non-null GUID implies that theSVSM_ATTEST_SINGLE_SERVICEcall should be used.- '
service_version' (input)
Used with theSVSM_ATTEST_SINGLE_SERVICEcall, 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 <[email protected]>--- 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(-)Documentation/ABI/testing/configfs-tsm +9
-0@@ -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: [email protected] +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. +Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Description: · line 47
Quoted 5 lines
Documentation/ABI/testing/configfs-tsm +5
-0+ 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.pdfI wish configfs had better dynamic visibility so that this could be hidden when not active... oh well.
Quoted 2 lines
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.
[..]
Quoted 23 lines
Quoted 14 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 106
Quoted 8 lines
Documentation/ABI/testing/configfs-tsm +8
-0+What: /sys/kernel/config/tsm/report/$name/svsm +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +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 valueJust 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.
Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 109
Quoted 3 lines
Documentation/ABI/testing/configfs-tsm +3
-0+ 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.pdfSo 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.
Quoted 4 lines
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?
[..]
Quoted 20 lines
Quoted 6 lines
Quoted 6 lines
Documentation/ABI/testing/configfs-tsm +6
-0+ +What: /sys/kernel/config/tsm/report/$name/service_version +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +Description:Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 137
Quoted 6 lines
Documentation/ABI/testing/configfs-tsm +6
-0+ (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.pdfPerhaps document that version 1 is assumed and is always compatible?
Can do.
Quoted 2 lines
What prompts new versions and how does that discovered by guest software?
Quoted 7 lines
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.
Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 76 lines · Dan Williams
Quoted 64 lines · Tom Lendacky
Quoted 54 lines · Dan Williams
Quoted 53 lines · Tom Lendacky
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 theSVSM_ATTEST_SERVICEScall should be used to request the attestation report. A non-null GUID implies that theSVSM_ATTEST_SINGLE_SERVICEcall should be used.- '
service_version' (input)
Used with theSVSM_ATTEST_SINGLE_SERVICEcall, 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 <[email protected]>--- 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(-)Documentation/ABI/testing/configfs-tsm +9
-0@@ -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: [email protected] +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. +Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Description: · line 47
Quoted 5 lines
Documentation/ABI/testing/configfs-tsm +5
-0+ 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.pdfI wish configfs had better dynamic visibility so that this could be hidden when not active... oh well.
Quoted 2 lines
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_typevstsm_report_extra_type). I think a "tsm_report_service_type" can be a new superset oftsm_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.
Quoted 5 lines
It seems straightforward to add an
is_visible()callback to 'structconfigfs_item_operations'. Then a common superset of all the attributes could be specified, but with anis_visible()implementation that consults with data registered withtsm_register()rather than the @type argument directly.
Let me look into that.
Quoted 25 lines
[..]
Quoted 23 lines
Quoted 22 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 106
Quoted 8 lines
Documentation/ABI/testing/configfs-tsm +8
-0+What: /sys/kernel/config/tsm/report/$name/svsm +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +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 valueJust 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.
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 109
Quoted 3 lines
Documentation/ABI/testing/configfs-tsm +3
-0+ 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.pdfSo 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.
Quoted 8 lines
Quoted 4 lines
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/[email protected]/
Quoted 27 lines
[..]
Quoted 25 lines
Quoted 6 lines
Quoted 6 lines
Documentation/ABI/testing/configfs-tsm +6
-0+ +What: /sys/kernel/config/tsm/report/$name/service_version +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +Description:Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 137
Quoted 6 lines
Documentation/ABI/testing/configfs-tsm +6
-0+ (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.pdfPerhaps document that version 1 is assumed and is always compatible?
Can do.
Quoted 2 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 4 lines
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
Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
Tom Lendacky wrote:
[..]
Quoted 7 lines
Quoted 3 lines
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.
Quoted 6 lines
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.
Missed that, thanks. Lets keep explicit as you have it and not overload privlevel.
[..]
Quoted 6 lines
Quoted 5 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
Quoted 3 lines
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_manifestorservice_manifest_version. I'd rather not rename it tomanifest_versionsince 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.
Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
In reply to Dan WilliamsQuoted 76 lines · Dan Williams
Quoted 64 lines · Tom Lendacky
Quoted 54 lines · Dan Williams
Quoted 53 lines · Tom Lendacky
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 theSVSM_ATTEST_SERVICEScall should be used to request the attestation report. A non-null GUID implies that theSVSM_ATTEST_SINGLE_SERVICEcall should be used.- '
service_version' (input)
Used with theSVSM_ATTEST_SINGLE_SERVICEcall, 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 <[email protected]>--- 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(-)Documentation/ABI/testing/configfs-tsm +9
-0@@ -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: [email protected] +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. +Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Description: · line 47
Quoted 5 lines
Documentation/ABI/testing/configfs-tsm +5
-0+ 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.pdfI wish configfs had better dynamic visibility so that this could be hidden when not active... oh well.
Quoted 2 lines
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_typevstsm_report_extra_type). I think a "tsm_report_service_type" can be a new superset oftsm_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.
Quoted 5 lines
It seems straightforward to add an
is_visible()callback to 'structconfigfs_item_operations'. Then a common superset of all the attributes could be specified, but with anis_visible()implementation that consults with data registered withtsm_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
Quoted 72 lines
[..]
Quoted 23 lines
Quoted 14 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 106
Quoted 8 lines
Documentation/ABI/testing/configfs-tsm +8
-0+What: /sys/kernel/config/tsm/report/$name/svsm +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +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 valueJust 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.
Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 109
Quoted 3 lines
Documentation/ABI/testing/configfs-tsm +3
-0+ 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.pdfSo 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.
Quoted 4 lines
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?
[..]
Quoted 20 lines
Quoted 6 lines
Quoted 6 lines
Documentation/ABI/testing/configfs-tsm +6
-0+ +What: /sys/kernel/config/tsm/report/$name/service_version +Date: January, 2024 +KernelVersion: v6.9 +Contact: [email protected] +Description:Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 137
Quoted 6 lines
Documentation/ABI/testing/configfs-tsm +6
-0+ (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.pdfPerhaps document that version 1 is assumed and is always compatible?
Can do.
Quoted 2 lines
What prompts new versions and how does that discovered by guest software?
Quoted 7 lines
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.
Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 103 lines · Tom Lendacky
Quoted 76 lines · Dan Williams
Quoted 64 lines · Tom Lendacky
Quoted 54 lines · Dan Williams
Quoted 53 lines · Tom Lendacky
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 theSVSM_ATTEST_SERVICEScall should be used to request the attestation report. A non-null GUID implies that theSVSM_ATTEST_SINGLE_SERVICEcall should be used.- '
service_version' (input)
Used with theSVSM_ATTEST_SINGLE_SERVICEcall, 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 <[email protected]>--- 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(-)Documentation/ABI/testing/configfs-tsm +9
-0@@ -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: [email protected] +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. +Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Description: · line 47
Quoted 5 lines
Documentation/ABI/testing/configfs-tsm +5
-0+ 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.pdfI wish configfs had better dynamic visibility so that this could be hidden when not active... oh well.
Quoted 2 lines
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_typevstsm_report_extra_type). I think a "tsm_report_service_type" can be a new superset oftsm_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.Quoted 5 lines
It seems straightforward to add an
is_visible()callback to 'structconfigfs_item_operations'. Then a common superset of all the attributes could be specified, but with anis_visible()implementation that consults with data registered withtsm_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 infs/configfs/dir.cpopulate_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.cas 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 newtsm.cinterface 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.
Quoted 1 line
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?
Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 124 lines · Dan Williams
Quoted 103 lines · Tom Lendacky
Quoted 76 lines · Dan Williams
Quoted 64 lines · Tom Lendacky
Quoted 54 lines · Dan Williams
Quoted 53 lines · Tom Lendacky
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 theSVSM_ATTEST_SERVICEScall should be used to request the attestation report. A non-null GUID implies that theSVSM_ATTEST_SINGLE_SERVICEcall should be used.- '
service_version' (input)
Used with theSVSM_ATTEST_SINGLE_SERVICEcall, 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 <[email protected]>--- 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(-)Documentation/ABI/testing/configfs-tsm +9
-0@@ -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: [email protected] +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. +Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Description: · line 47
Quoted 5 lines
Documentation/ABI/testing/configfs-tsm +5
-0+ 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.pdfI wish configfs had better dynamic visibility so that this could be hidden when not active... oh well.
Quoted 2 lines
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_typevstsm_report_extra_type). I think a "tsm_report_service_type" can be a new superset oftsm_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.Quoted 5 lines
It seems straightforward to add an
is_visible()callback to 'structconfigfs_item_operations'. Then a common superset of all the attributes could be specified, but with anis_visible()implementation that consults with data registered withtsm_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 infs/configfs/dir.cpopulate_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.cas 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 newtsm.cinterface 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.Quoted 1 line
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,
};
Quoted 6 lines
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:
fs/configfs/dir.c +9 -1
@@ -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 ;
include/linux/configfs.h +79 -34
161 lines not on this page · raw message
And then the following for implementing it for tsm, which allows for as simple or complicated an is_visible() function as required:
drivers/virt/coco/sev-guest/sev-guest.c +13 -0
@@ -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;
drivers/virt/coco/tsm.c +46 -4
86 lines not on this page · raw message
include/linux/tsm.h +4 -0
@@ -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
Quoted 2 lines
PATCH 11/11 x86/sev: Allow non-VMPL0 execution when an SVSM is present
In reply to Tom LendackyTo 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.
--- 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(-)
arch/x86/boot/compressed/sev.c +9 -2
@@ -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 ); }
arch/x86/include/asm/sev-common.h +1 -0
@@ -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
arch/x86/kernel/sev.c +17 -3
@@ -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) {
Signature · 1 line
2.42.0
Quoted 18 lines
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].
Quoted 12 lines
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
Quoted 38 lines · Elena
Quoted 18 lines
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].
Quoted 12 lines
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 presentHi 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.
Quoted 13 lines
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.
Quoted 6 lines
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.
Quoted 15 lines
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:
Quoted 10 lines
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.
Quoted 9 lines
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.
Quoted 7 lines
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.
Quoted 10 lines
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
Quoted 16 lines
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
Quoted 11 lines · Tom Lendacky
Quoted 10 lines
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.
Quoted 1 line
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.
Signature · 1 line
Kiryl Shutsemau / Kirill A. Shutemov
Quoted 55 lines
Subject: Re: [PATCH 00/11] Provide SEV-SNP support for running under an SVSM
Quoted 38 lines · Elena
Quoted 18 lines
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].
Quoted 12 lines
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 presentHi 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.Quoted 13 lines
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].
Quoted 3 lines
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.
Quoted 8 lines
Quoted 7 lines
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
Quoted 6 lines
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).
Quoted 6 lines
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.
Quoted 27 lines
Quoted 16 lines
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:Quoted 10 lines
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?
Quoted 6 lines
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?
Quoted 11 lines
Quoted 10 lines
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.
Quoted 4 lines
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.
Quoted 17 lines
Quoted 7 lines
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.
Quoted 5 lines
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,
Quoted 1 line
this approach is followed to some initial degree by MSFT Hyper-V
implementation [2].
Quoted 1 line
It defines a new type of virtualized guest with its own initialization path and
Quoted 8 lines
callbacks in
Quoted 2 lines
x86_platform.guest/hyper.*. However, in our understanding noone has yet
attempted to define a unified abstraction for such guest, as well as unifiedinterface.
Quoted 2 lines
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.
Quoted 21 lines
Thanks,
TomQuoted 7 lines
5. Anything else is missing?
References:
Quoted 7 lines
[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
Quoted 2 lines
Quoted 7 lines · Elena
Quoted 4 lines
Subject: Re: [PATCH 00/11] Provide SEV-SNP support for running under an SVSM
Quoted 1 line · Elena
Quoted 1 line
This series adds SEV-SNP support for running Linux under an Secure VM
Sorry for my ignorance, what the HV?
HV == Hypervisor
Quoted 10 lines
Quoted 2 lines
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.
Quoted 3 lines
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
Quoted 26 lines
Best Regards,
Elena.Quoted 21 lines
Thanks,
TomQuoted 7 lines
5. Anything else is missing?
References:
Quoted 7 lines
[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
Quoted 2 lines
Quoted 12 lines
Quoted 1 line
Kirill already commented on this, and the answer is of course we can, but imo
we
Quoted 1 line
need to see a bigger picture first. If we go with option 2 above, then coming
with a
Quoted 1 line
joint protocol is only limitedly useful because likely we wont be able to share
the
Quoted 1 line
code in the guest kernel. Ideally I think we want a common concept and a
common
Quoted 3 lines
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
Quoted 8 lines
Quoted 1 line
setup a call with anyone who is interested in the topic to form a joint
understanding
Quoted 1 line
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.
Quoted 31 lines
Thanks,
TomQuoted 23 lines
Best Regards,
Elena.Quoted 18 lines
Thanks,
TomQuoted 14 lines
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#L575technical-
Quoted 3 lines
Quoted 3 lines
docs/specifications/58019.pdf
Quoted 2 lines