Provide SEV-SNP support for running under an SVSM
v2 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
fdd513724225 ("Merge branch into tip/master: 'x86/tdx'")
[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
---
Changes in v2:
- Define X86_FEATURE_SVSM_PRESENT and set the bit in the CPUID table, removing the need to set the CPUID bit in the #VC handler.
- Rename the TSM service_version attribute to service_manifest_version.
- Add support to config-fs to hide attributes and hide the SVSM attributes when an SVSM is not present.
Tom Lendacky (14):
x86/sev: Rename snp_init() in the boot/compressed/sev.c file x86/sev: Make the VMPL0 checking function more generic x86/sev: Check for the presence of an SVSM in the SNP Secrets page x86/sev: Use kernel provided SVSM Calling Areas
x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0 x86/sev: Use the SVSM to create a vCPU when not in VMPL0 x86/sev: Provide SVSM discovery support
x86/sev: Provide guest VMPL level to userspace
virt: sev-guest: Choose the VMPCK key based on executing VMPL
configfs-tsm: Allow the privlevel_floor attribute to be updated x86/sev: Extend the config-fs attestation support for an SVSM fs/configfs: Add a callback to determine attribute visibility x86/sev: Hide SVSM attestation entries if not running under an SVSM x86/sev: Allow non-VMPL0 execution when an SVSM is present
Documentation/ABI/testing/configfs-tsm | 59 ++++ arch/x86/boot/compressed/sev.c | 256 ++++++++------ arch/x86/coco/core.c | 4 + arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/msr-index.h | 2 + arch/x86/include/asm/sev-common.h | 18 + arch/x86/include/asm/sev.h | 114 ++++++- arch/x86/include/uapi/asm/svm.h | 1 + arch/x86/kernel/sev-shared.c | 345 ++++++++++++++++++- arch/x86/kernel/sev.c | 426 +++++++++++++++++++++--- arch/x86/mm/mem_encrypt_amd.c | 8 +- drivers/virt/coco/sev-guest/sev-guest.c | 162 ++++++++- drivers/virt/coco/tsm.c | 100 +++++- fs/configfs/file.c | 13 + include/linux/cc_platform.h | 8 + include/linux/configfs.h | 114 +++++-- include/linux/tsm.h | 13 +- 17 files changed, 1440 insertions(+), 204 deletions(-)
Signature · 1 line
2.43.2
PATCH v2 1/14 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
@@ -413,6 +413,85 @@ void snp_check_features(void) } } +/* Search for Confidential Computing blob in the EFI config table. */ +static struct cc_blob_sev_info *find_cc_blob_efi (struct boot_params *bp) +{ +unsigned long cfg_table_pa; +unsigned int cfg_table_len; +int ret; + + ret =efi_get_conf_table (bp, &cfg_table_pa, &cfg_table_len); +if (ret) +return NULL ; + +return (struct cc_blob_sev_info *)efi_find_vendor_table (bp, cfg_table_pa, + cfg_table_len, +EFI_CC_BLOB_GUID ); +} + +/* +* Initial set up of SNP relies on information provided by the +* Confidential Computing blob, which can be passed to the boot kernel +* by firmware/bootloader in the following ways: +* +* - via an entry in the EFI config table +* - via a setup_data structure, as defined by the Linux Boot Protocol +* +* Scan for the blob in that order. +*/ +static struct cc_blob_sev_info *find_cc_blob (struct boot_params *bp) +{ +struct cc_blob_sev_info *cc_info; + + cc_info =find_cc_blob_efi (bp); +if (cc_info) + goto found_cc_info; + + cc_info =find_cc_blob_setup_data (bp); +if (!cc_info) +return NULL ; + +found_cc_info: +if (cc_info->magic !=CC_BLOB_SEV_HDR_MAGIC ) +sev_es_terminate (SEV_TERM_SET_GEN ,GHCB_SNP_UNSUPPORTED ); + +return cc_info; +} + +/* +* Indicate SNP based on presence of SNP-specific CC blob. Subsequent checks +* will verify the SNP CPUID/MSR bits. +*/ +static bool 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 *
@@ -463,7 +542,7 @@ void sev_enable(struct boot_params *bp) bp->cc_blob_address =0 ;/* -* Do an initial SEV capability check before snp_init() which +* Do an initial SEV capability check before snp_setup() which * loads the CPUID page and the same checks afterwards are done * without the hypervisor and are trustworthy. *
@@ -478,7 +557,7 @@ void sev_enable(struct boot_params *bp)* Setup/preliminary detection of SNP. This will be sanity-checked * against CPUID/MSR values later. */ - snp =snp_init (bp); + snp =snp_setup (bp);/* Now repeat the checks with the SNP CPUID table. */
@@ -535,85 +614,6 @@ u64 sev_get_status(void)return m.q; } -/* Search for Confidential Computing blob in the EFI config table. */ -static struct cc_blob_sev_info *find_cc_blob_efi (struct boot_params *bp) -{ -unsigned long cfg_table_pa; -unsigned int cfg_table_len; -int ret; - - ret =efi_get_conf_table (bp, &cfg_table_pa, &cfg_table_len); -if (ret) -return NULL ; - -return (struct cc_blob_sev_info *)efi_find_vendor_table (bp, cfg_table_pa, - cfg_table_len, -EFI_CC_BLOB_GUID ); -} - -/* -* Initial set up of SNP relies on information provided by the -* Confidential Computing blob, which can be passed to the boot kernel -* by firmware/bootloader in the following ways: -* -* - via an entry in the EFI config table -* - via a setup_data structure, as defined by the Linux Boot Protocol -* -* Scan for the blob in that order. -*/ -static struct cc_blob_sev_info *find_cc_blob (struct boot_params *bp) -{ -struct cc_blob_sev_info *cc_info; - - cc_info =find_cc_blob_efi (bp); -if (cc_info) - goto found_cc_info; - - cc_info =find_cc_blob_setup_data (bp); -if (!cc_info) -return NULL ; - -found_cc_info: -if (cc_info->magic !=CC_BLOB_SEV_HDR_MAGIC ) -sev_es_terminate (SEV_TERM_SET_GEN ,GHCB_SNP_UNSUPPORTED ); - -return cc_info; -} - -/* -* Indicate SNP based on presence of SNP-specific CC blob. Subsequent checks -* will verify the SNP CPUID/MSR bits. -*/ -bool snp_init (struct boot_params *bp) -{ -struct cc_blob_sev_info *cc_info; - -if (!bp) -return false; - - cc_info =find_cc_blob (bp); -if (!cc_info) -return false; - -/* -* If a SNP-specific Confidential Computing blob is present, then -* firmware/bootloader have indicated SNP support. Verifying this -* involves CPUID checks which will be more reliable if the SNP -* CPUID table is used. See comments over snp_setup_cpuid_table() for -* more details. -*/ -setup_cpuid_table (cc_info); - -/* -* Pass run-time kernel a pointer to CC info via boot_params so EFI -* config table doesn't need to be searched again during early startup -* phase. -*/ - bp->cc_blob_address = (u32 )(unsigned long )cc_info; - -return true; -} -void sev_prep_identity_maps (unsigned long top_level_pgt) {/*
Signature · 1 line
2.43.2
Borislav Petkov
maintainerRe: [PATCH v2 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file
arch/x86/boot/compressed/sev.c void sev_enable(struct boot_params *bp) · line 560
Quoted 6 lines · Tom Lendacky
arch/x86/boot/compressed/sev.c +1
-1@@ -478,7 +557,7 @@ void sev_enable(struct boot_params *bp)* Setup/preliminary detection of SNP. This will be sanity-checked * against CPUID/MSR values later. */ - snp =snp_init (bp); + snp =snp_setup (bp);
So if you call the compressed/sev.c version early_snp_init() or boot_snp_init() or something similar, you know immediately when it is called vs having to grep the tree to figure out which is which - was snp_setup() early or was it in the kernel proper. And so on...
Signature · 4 lines
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquetteRe: [PATCH v2 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file
Quoted 10 lines · Borislav Petkov
arch/x86/boot/compressed/sev.c void sev_enable(struct boot_params *bp) · line 560
Quoted 6 lines · Tom Lendacky
arch/x86/boot/compressed/sev.c +1
-1@@ -478,7 +557,7 @@ void sev_enable(struct boot_params *bp)* Setup/preliminary detection of SNP. This will be sanity-checked * against CPUID/MSR values later. */ - snp =snp_init (bp); + snp =snp_setup (bp);So if you call the
compressed/sev.cversionearly_snp_init()orboot_snp_init()or something similar, you know immediately when it is
Yep, makes sense. Will change it.
Thanks,
Tom
Quoted 3 lines
called vs having to grep the tree to figure out which is which - was
snp_setup()early or was it in the kernel proper. And so on...
PATCH v2 2/14 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
@@ -335,10 +335,9 @@ void do_boot_stage2_vc(struct pt_regs *regs, unsigned long exit_code)sev_es_terminate (SEV_TERM_SET_GEN ,GHCB_SEV_ES_GEN_REQ ); } -static void enforce_vmpl0 (void ) +static bool running_at_vmpl0 (void *va) {u64 attrs; -int err;/* * RMPADJUST modifies RMP permissions of a lesser-privileged (numerically
@@ -347,12 +346,11 @@ static void enforce_vmpl0(void)* * If the guest is running at VMPL0, it will succeed. Even if that operation * modifies permission bits, it is still ok to do so currently because Linux -* SNP guests are supported only on VMPL0 so VMPL1 or higher permission masks -* changing is a don't-care. +* SNP guests running at VMPL0 only run at VMPL0, so VMPL1 or higher +* permission mask changes are a don't-care. */ attrs =1 ; -if (rmpadjust ((unsigned long )&boot_ghcb_page,RMP_PG_SIZE_4K , attrs)) -sev_es_terminate (SEV_TERM_SET_LINUX ,GHCB_TERM_NOT_VMPL0 ); +return !rmpadjust ((unsigned long )va,RMP_PG_SIZE_4K , attrs); }/*
@@ -588,7 +586,8 @@ void sev_enable(struct boot_params *bp)if (!(get_hv_features () &GHCB_HV_FT_SNP ))sev_es_terminate (SEV_TERM_SET_GEN ,GHCB_SNP_UNSUPPORTED ); -enforce_vmpl0 (); +if (!running_at_vmpl0 (&boot_ghcb_page)) +sev_es_terminate (SEV_TERM_SET_LINUX ,GHCB_TERM_NOT_VMPL0 ); }if (snp && !(sev_status &MSR_AMD64_SEV_SNP_ENABLED ))
Signature · 1 line
2.43.2
PATCH v2 3/14 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/bootparam.h> #include <asm/pgtable_types.h> #include <asm/sev.h>
@@ -29,6 +30,15 @@static struct ghcb boot_ghcb_page__aligned(PAGE_SIZE) ;struct ghcb *boot_ghcb; +/* +* SVSM related information: +* When running under an SVSM, the VMPL that Linux is executing at must be +* non-zero. The VMPL is therefore used to indicate the presence of an SVSM. +*/ +static u8 vmpl __section(".data"); +static u64 boot_svsm_caa_pa __section(".data"); +static struct svsm_ca *boot_svsm_caa __section(".data"); +/* * Copy a version of this function here - insn-eval.c can't be used in * pre-decompression code.
@@ -335,24 +345,6 @@ void do_boot_stage2_vc(struct pt_regs *regs, unsigned long exit_code)sev_es_terminate (SEV_TERM_SET_GEN ,GHCB_SEV_ES_GEN_REQ ); } -static bool running_at_vmpl0 (void *va) -{ -u64 attrs; - -/* -* RMPADJUST modifies RMP permissions of a lesser-privileged (numerically -* higher) privilege level. Here, clear the VMPL1 permission mask of the -* GHCB page. If the guest is not running at VMPL0, this will fail. -* -* If the guest is running at VMPL0, it will succeed. Even if that operation -* modifies permission bits, it is still ok to do so currently because Linux -* SNP guests running at VMPL0 only run at VMPL0, so VMPL1 or higher -* permission mask changes are a don't-care. -*/ - attrs =1 ; -return !rmpadjust ((unsigned long )va,RMP_PG_SIZE_4K , attrs); -} -/* * SNP_FEATURES_IMPL_REQ is the mask of SNP features that will need * guest side implementation for proper functioning of the guest. If any
@@ -480,6 +472,13 @@ static bool 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
@@ -152,9 +152,32 @@ struct snp_secrets_page_layout {u8 vmpck2[VMPCK_KEY_LEN ];u8 vmpck3[VMPCK_KEY_LEN ];struct secrets_os_area os_area; -u8 rsvd3[3840 ]; + +u8 vmsa_tweak_bitmap[64 ]; + +/* SVSM fields */ +u64 svsm_base; +u64 svsm_size; +u64 svsm_caa; +u32 svsm_max_version; +u8 svsm_guest_vmpl; +u8 rsvd3[3 ]; + +/* Remainder of page */ +u8 rsvd4[3744 ]; } __packed; +/* +* The SVSM Calling Area (CA) related structures. +*/ +struct svsm_ca { +u8 call_pending; +u8 mem_available; +u8 rsvd1[6 ]; + +u8 svsm_buffer[PAGE_SIZE -8 ]; +}; +#ifdef CONFIG_AMD_MEM_ENCRYPT extern void __sev_es_ist_enter (struct pt_regs *regs);extern void __sev_es_ist_exit (void );
arch/x86/kernel/sev-shared.c +64 -0
73 lines not on this page · raw message
arch/x86/kernel/sev.c +16 -0
@@ -135,6 +135,15 @@ struct ghcb_state { static DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data); static DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa); +/* +* SVSM related information: +* When running under an SVSM, the VMPL that Linux is executing at must be +* non-zero. The VMPL is therefore used to indicate the presence of an SVSM. +*/ +static u8 vmpl__ro_after_init ; +static struct svsm_ca *boot_svsm_caa__ro_after_init ; +static u64 boot_svsm_caa_pa__ro_after_init ; +struct sev_config { __u64 debug : 1,
@@ -2122,6 +2131,13 @@ bool __head snp_init(struct boot_params *bp)setup_cpuid_table (cc_info); +/* +* Record the SVSM Calling Area address (CAA) if the guest is not +* running at VMPL0. The CA will be used to communicate with the +* SVSM to perform the SVSM services. +*/ +setup_svsm_ca (cc_info); +/* * The CC blob will be used later to access the secrets page. Cache * it here like the boot kernel does.
Signature · 1 line
2.43.2
Re: [PATCH v2 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page
Quoted 169 lines · Tom Lendacky
During early boot phases, check for the presence of an SVSM when running as an SEV-SNP guest.
An SVSM is present if the 64-bit value at offset
0x148into the secrets page is non-zero. If an SVSM is present, save the SVSM Calling Area address (CAA), located at offset0x150into the secrets page, and set the VMPL level of the guest, which should be non-zero, to indicate the presence of an SVSM.Signed-off-by Tom Lendacky <[email protected]>--- 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/bootparam.h> #include <asm/pgtable_types.h> #include <asm/sev.h> @@ -29,6 +30,15 @@static struct ghcb boot_ghcb_page__aligned(PAGE_SIZE) ;struct ghcb *boot_ghcb; +/* +* SVSM related information: +* When running under an SVSM, the VMPL that Linux is executing at must be +* non-zero. The VMPL is therefore used to indicate the presence of an SVSM. +*/ +static u8 vmpl __section(".data"); +static u64 boot_svsm_caa_pa __section(".data"); +static struct svsm_ca *boot_svsm_caa __section(".data"); +/* * Copy a version of this function here - insn-eval.c can't be used in * pre-decompression code. @@ -335,24 +345,6 @@ void do_boot_stage2_vc(struct pt_regs *regs, unsigned long exit_code)sev_es_terminate (SEV_TERM_SET_GEN ,GHCB_SEV_ES_GEN_REQ ); } -static bool running_at_vmpl0 (void *va) -{ -u64 attrs; - -/* -* RMPADJUST modifies RMP permissions of a lesser-privileged (numerically -* higher) privilege level. Here, clear the VMPL1 permission mask of the -* GHCB page. If the guest is not running at VMPL0, this will fail. -* -* If the guest is running at VMPL0, it will succeed. Even if that operation -* modifies permission bits, it is still ok to do so currently because Linux -* SNP guests running at VMPL0 only run at VMPL0, so VMPL1 or higher -* permission mask changes are a don't-care. -*/ - attrs =1 ; -return !rmpadjust ((unsigned long )va,RMP_PG_SIZE_4K , attrs); -} -/* * SNP_FEATURES_IMPL_REQ is the mask of SNP features that will need * guest side implementation for proper functioning of the guest. If any @@ -480,6 +472,13 @@ static bool 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@@ -152,9 +152,32 @@ struct snp_secrets_page_layout {u8 vmpck2[VMPCK_KEY_LEN ];u8 vmpck3[VMPCK_KEY_LEN ];struct secrets_os_area os_area; -u8 rsvd3[3840 ]; + +u8 vmsa_tweak_bitmap[64 ]; + +/* SVSM fields */ +u64 svsm_base; +u64 svsm_size; +u64 svsm_caa; +u32 svsm_max_version; +u8 svsm_guest_vmpl; +u8 rsvd3[3 ]; + +/* Remainder of page */ +u8 rsvd4[3744 ]; } __packed; +/* +* The SVSM Calling Area (CA) related structures. +*/ +struct svsm_ca { +u8 call_pending; +u8 mem_available; +u8 rsvd1[6 ]; + +u8 svsm_buffer[PAGE_SIZE -8 ]; +}; +#ifdef CONFIG_AMD_MEM_ENCRYPT extern void __sev_es_ist_enter (struct pt_regs *regs);extern void __sev_es_ist_exit (void );arch/x86/kernel/sev-shared.c +18
-0@@ -111,6 +111,24 @@ sev_es_terminate(unsigned int set, unsigned int reason) asmvolatile ("hlt\n" : : :"memory" ); } +static bool running_at_vmpl0 (void *va) +{ +u64 attrs; + +/* +* RMPADJUST modifies RMP permissions of a lesser-privileged (numerically +* higher) privilege level. Here, clear the VMPL1 permission mask of the +* GHCB page. If the guest is not running at VMPL0, this will fail. +* +* If the guest is running at VMPL0, it will succeed. Even if that operation +* modifies permission bits, it is still ok to do so currently because Linux +* SNP guests running at VMPL0 only run at VMPL0, so VMPL1 or higher +* permission mask changes are a don't-care. +*/ + attrs =1 ; +return !rmpadjust ((unsigned long )va,RMP_PG_SIZE_4K , attrs); +} +/* * The hypervisor features are available from GHCB version 2 onward. */
arch/x86/kernel/sev-shared.c static enum es_result vc_check_opcode_bytes(struct es_em_ctxt *ctxt, · line 1291
Quoted 7 lines
arch/x86/kernel/sev-shared.c +4
-0@@ -1267,3 +1285,49 @@ static enum es_result vc_check_opcode_bytes(struct es_em_ctxt *ctxt,return ES_UNSUPPORTED ; } + +/* +* Maintain the GPA of the SVSM Calling Area (CA) in order to utilize the SVSM +* services needed when not runnuing in VMPL0.
running*
otherwise lgtm
Quoted 80 lines
arch/x86/kernel/sev-shared.c +42
-0+*/ +static void __init setup_svsm_ca (const struct cc_blob_sev_info *cc_info) +{ +struct snp_secrets_page_layout *secrets_page; +u64 caa; + +BUILD_BUG_ON (sizeof (*secrets_page) !=PAGE_SIZE ); + +/* +* Use __pa() since this routine is running identity mapped when +* called, both by the decompressor code and the early kernel code. +*/ +if (running_at_vmpl0 ((void *)__pa (&boot_ghcb_page))) +return ; + +/* +* Not running at VMPL0, ensure everything has been properly supplied +* for running under an SVSM. +*/ +if (!cc_info || !cc_info->secrets_phys || cc_info->secrets_len !=PAGE_SIZE ) +sev_es_terminate (SEV_TERM_SET_LINUX ,GHCB_TERM_SECRETS_PAGE ); + + secrets_page = (struct snp_secrets_page_layout *)cc_info->secrets_phys; +if (!secrets_page->svsm_size) +sev_es_terminate (SEV_TERM_SET_LINUX ,GHCB_TERM_NO_SVSM ); + +if (!secrets_page->svsm_guest_vmpl) +sev_es_terminate (SEV_TERM_SET_LINUX ,GHCB_TERM_SVSM_VMPL0 ); + + vmpl = secrets_page->svsm_guest_vmpl; + + caa = secrets_page->svsm_caa; +if (!PAGE_ALIGNED (caa)) +sev_es_terminate (SEV_TERM_SET_LINUX ,GHCB_TERM_SVSM_CAA ); + +/* +* The CA is identity mapped when this routine is called, both by the +* decompressor code and the early kernel code. +*/ + boot_svsm_caa = (struct svsm_ca *)caa; + boot_svsm_caa_pa = caa; +}arch/x86/kernel/sev.c +16
-1@@ -135,6 +135,15 @@ struct ghcb_state { static DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data); static DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa); +/* +* SVSM related information: +* When running under an SVSM, the VMPL that Linux is executing at must be +* non-zero. The VMPL is therefore used to indicate the presence of an SVSM. +*/ +static u8 vmpl__ro_after_init ; +static struct svsm_ca *boot_svsm_caa__ro_after_init ; +static u64 boot_svsm_caa_pa__ro_after_init ; +struct sev_config { __u64 debug : 1,@@ -2122,6 +2131,13 @@ bool __head snp_init(struct boot_params *bp)setup_cpuid_table (cc_info); +/* +* Record the SVSM Calling Area address (CAA) if the guest is not +* running at VMPL0. The CA will be used to communicate with the +* SVSM to perform the SVSM services. +*/ +setup_svsm_ca (cc_info); +/* * The CC blob will be used later to access the secrets page. Cache * it here like the boot kernel does. -- 2.43.2
Signature · 1 line
-Dionna Glaze, PhD (she/her)
Re: [PATCH v2 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page
Quoted 21 lines · Dionna Amalie Glaze
Quoted 19 lines · Tom Lendacky
During early boot phases, check for the presence of an SVSM when running as an SEV-SNP guest.
An SVSM is present if the 64-bit value at offset
0x148into the secrets page is non-zero. If an SVSM is present, save the SVSM Calling Area address (CAA), located at offset0x150into the secrets page, and set the VMPL level of the guest, which should be non-zero, to indicate the presence of an SVSM.Signed-off-by Tom Lendacky <[email protected]>--- 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(-)
Quoted 8 lines
arch/x86/kernel/sev-shared.c static enum es_result vc_check_opcode_bytes(struct es_em_ctxt *ctxt, · line 1291
Quoted 4 lines
arch/x86/kernel/sev-shared.c +4
-0+ +/* +* Maintain the GPA of the SVSM Calling Area (CA) in order to utilize the SVSM +* services needed when not runnuing in VMPL0. running*
otherwise lgtm
Will fix.
Thanks,
Tom
Quoted 1 line
PATCH v2 4/14 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_CA call.
An SVSM call is executed by filling out the SVSM CA and setting the proper register state as documented by the SVSM protocol. The SVSM is invoked by by requesting the hypervisor to run VMPL0.
Once it is safe to allocate/reserve memory, allocate a CA for each CPU. After allocating the new CAs, the BSP will switch from the boot CA to the per-CPU CA. The CA for an AP is identified to the SVSM when creating the VMSA in preparation for booting the AP.
--- 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
@@ -178,6 +178,36 @@ struct svsm_ca {u8 svsm_buffer[PAGE_SIZE -8 ]; }; +#define SVSM_SUCCESS 0 +#define SVSM_ERR_INCOMPLETE 0x80000000 +#define SVSM_ERR_UNSUPPORTED_PROTOCOL 0x80000001 +#define SVSM_ERR_UNSUPPORTED_CALL 0x80000002 +#define SVSM_ERR_INVALID_ADDRESS 0x80000003 +#define SVSM_ERR_INVALID_FORMAT 0x80000004 +#define SVSM_ERR_INVALID_PARAMETER 0x80000005 +#define SVSM_ERR_INVALID_REQUEST 0x80000006 +#define SVSM_ERR_BUSY 0x80000007 + +/* +* SVSM protocol structure +*/ +struct svsm_call { +struct svsm_ca *caa; +u64 rax; +u64 rcx; +u64 rdx; +u64 r8; +u64 r9; +u64 rax_out; +u64 rcx_out; +u64 rdx_out; +u64 r8_out; +u64 r9_out; +}; + +#define SVSM_CORE_CALL (x) ((0ULL << 32) | (x)) +#define SVSM_CORE_REMAP_CA 0 +#ifdef CONFIG_AMD_MEM_ENCRYPT extern void __sev_es_ist_enter (struct pt_regs *regs);extern void __sev_es_ist_exit (void );
@@ -253,6 +283,7 @@ u64 snp_get_unsupported_features(u64 status);u64 sev_get_status (void );void kdump_sev_callback (void );void sev_show_status (void ); +void __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 ) { }
@@ -283,6 +314,7 @@ static inline u64 snp_get_unsupported_features(u64 status) { return 0; }static inline u64 sev_get_status (void ) {return 0 ; }static inline void kdump_sev_callback (void ) { }static inline void sev_show_status (void ) { } +static inline void snp_remap_svsm_ca (void ) { }#endif #ifdef CONFIG_KVM_AMD_SEV
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
108 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.43.2
PATCH v2 5/14 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 | 45 ++++++++- arch/x86/include/asm/sev.h | 22 +++++ arch/x86/kernel/sev-shared.c | 176 ++++++++++++++++++++++++++++++++- arch/x86/kernel/sev.c | 25 +++-- 4 files changed, 250 insertions(+), 18 deletions(-)
arch/x86/boot/compressed/sev.c +41 -4
@@ -39,6 +39,16 @@ static u8 vmpl __section(".data"); static u64 boot_svsm_caa_pa __section(".data"); static struct svsm_ca *boot_svsm_caa __section(".data"); +static struct svsm_ca *__svsm_get_caa (void ) +{ +return boot_svsm_caa; +} + +static u64 __svsm_get_caa_pa (void ) +{ +return boot_svsm_caa_pa; +} +/* * Copy a version of this function here - insn-eval.c can't be used in * pre-decompression code.
@@ -139,6 +149,24 @@ static bool fault_in_kernel_space(unsigned long address)/* Include code for early handlers */ #include "../../kernel/sev-shared.c" +static int svsm_protocol (struct svsm_call *call) +{ +struct ghcb *ghcb; +int ret; + +if (boot_ghcb) + ghcb = boot_ghcb; +else + ghcb =NULL ; + +do { + ret = ghcb ?__svsm_ghcb_protocol (ghcb, call) + :__svsm_msr_protocol (call); + }while (ret ==SVSM_ERR_BUSY ); + +return ret; +} +bool sev_snp_enabled (void ) {return sev_status &MSR_AMD64_SEV_SNP_ENABLED ;
@@ -155,8 +183,8 @@ static void __page_state_change(unsigned long paddr, enum psc_op op)* If private -> shared then invalidate the page before requesting the * state change in the RMP table. */ -if (op ==SNP_PAGE_STATE_SHARED &&pvalidate (paddr,RMP_PG_SIZE_4K ,0 )) -sev_es_terminate (SEV_TERM_SET_LINUX ,GHCB_TERM_PVALIDATE ); +if (op ==SNP_PAGE_STATE_SHARED ) +pvalidate_4k_page (paddr, paddr,0 );/* Issue VMGEXIT to change the page state in RMP table. */ sev_es_wr_ghcb_msr (GHCB_MSR_PSC_REQ_GFN (paddr >>PAGE_SHIFT , op));
@@ -171,8 +199,8 @@ static void __page_state_change(unsigned long paddr, enum psc_op op)* Now that page state is changed in the RMP table, validate it so that it is * consistent with the RMP entry. */ -if (op ==SNP_PAGE_STATE_PRIVATE &&pvalidate (paddr,RMP_PG_SIZE_4K ,1 )) -sev_es_terminate (SEV_TERM_SET_LINUX ,GHCB_TERM_PVALIDATE ); +if (op ==SNP_PAGE_STATE_PRIVATE ) +pvalidate_4k_page (paddr, paddr,1 ); }void snp_set_page_private (unsigned long paddr)
@@ -265,6 +293,15 @@ void sev_es_shutdown_ghcb(void)if (!sev_es_check_cpu_features ())error ("SEV-ES CPU Features missing." ); +/* +* The boot_ghcb value is used to determine whether to use the GHCB MSR +* protocol or the GHCB shared page to perform a GHCB request. Since the +* GHCB page is being changed to encrypted, it can't be used to perform +* GHCB requests. Clear the boot_ghcb variable so that the GHCB MSR +* protocol is used to change the GHCB page over to an encrypted page. +*/ + boot_ghcb =NULL ; +/* * GHCB Page must be flushed from the cache and mapped encrypted again. * Otherwise the running kernel will see strange cache effects when
arch/x86/include/asm/sev.h +22 -0
@@ -187,6 +187,27 @@ struct svsm_ca {#define SVSM_ERR_INVALID_PARAMETER 0x80000005#define SVSM_ERR_INVALID_REQUEST 0x80000006#define SVSM_ERR_BUSY 0x80000007 +#define SVSM_PVALIDATE_FAIL_SIZEMISMATCH 0x80001006 + +/* +* The SVSM PVALIDATE related structures +*/ +struct svsm_pvalidate_entry { +u64 page_size :2 , + action :1 , + ignore_cf :1 , + rsvd :8 , + pfn :52 ; +}; + +struct svsm_pvalidate_call { +u16 entries; +u16 next; + +u8 rsvd1[4 ]; + +struct svsm_pvalidate_entry entry[]; +};/* * SVSM protocol structure
@@ -207,6 +228,7 @@ struct svsm_call {#define SVSM_CORE_CALL (x) ((0ULL << 32) | (x))#define SVSM_CORE_REMAP_CA 0 +#define SVSM_CORE_PVALIDATE 1#ifdef CONFIG_AMD_MEM_ENCRYPT extern void __sev_es_ist_enter (struct pt_regs *regs);
arch/x86/kernel/sev-shared.c +175 -1
194 lines not on this page · raw message
arch/x86/kernel/sev.c +12 -13
@@ -181,6 +181,12 @@ static struct svsm_ca *__svsm_get_caa(void) : boot_svsm_caa; } +static u64 __svsm_get_caa_pa (void ) +{ +return sev_cfg.cas_initialized ?this_cpu_read (svsm_caa_pa) + : boot_svsm_caa_pa; +} + static __always_inline bool on_vc_stack(struct pt_regs *regs) {unsigned long sp = regs->sp;
@@ -798,7 +804,6 @@ early_set_pages_state(unsigned long vaddr, unsigned long paddr, {unsigned long paddr_end;u64 val; -int ret; vaddr = vaddr &PAGE_MASK ;
@@ -806,12 +811,9 @@ early_set_pages_state(unsigned long vaddr, unsigned long paddr, paddr_end = paddr + (npages <<PAGE_SHIFT );while (paddr < paddr_end) { -if (op ==SNP_PAGE_STATE_SHARED ) { -/* Page validation must be rescinded before changing to shared */ - ret =pvalidate (vaddr,RMP_PG_SIZE_4K , false); -if (WARN (ret,"Failed to validate address 0x%lx ret %d" , paddr, ret)) - goto e_term; - } +/* Page validation must be rescinded before changing to shared */ +if (op ==SNP_PAGE_STATE_SHARED ) +pvalidate_4k_page (vaddr, paddr, false);/* * Use the MSR protocol because this function can be called before
@@ -833,12 +835,9 @@ early_set_pages_state(unsigned long vaddr, unsigned long paddr, paddr, GHCB_MSR_PSC_RESP_VAL(val))) goto e_term; -if (op ==SNP_PAGE_STATE_PRIVATE ) { -/* Page validation must be performed after changing to private */ - ret =pvalidate (vaddr,RMP_PG_SIZE_4K , true); -if (WARN (ret,"Failed to validate address 0x%lx ret %d" , paddr, ret)) - goto e_term; - } +/* Page validation must be performed after changing to private */ +if (op ==SNP_PAGE_STATE_PRIVATE ) +pvalidate_4k_page (vaddr, paddr, true); vaddr +=PAGE_SIZE ; paddr +=PAGE_SIZE ;
Signature · 1 line
2.43.2
PATCH v2 6/14 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
@@ -229,6 +229,8 @@ struct svsm_call {#define SVSM_CORE_CALL (x) ((0ULL << 32) | (x))#define SVSM_CORE_REMAP_CA 0#define SVSM_CORE_PVALIDATE 1 +#define SVSM_CORE_CREATE_VCPU 2 +#define SVSM_CORE_DELETE_VCPU 3#ifdef CONFIG_AMD_MEM_ENCRYPT extern void __sev_es_ist_enter (struct pt_regs *regs);
arch/x86/kernel/sev.c +52 -8
119 lines not on this page · raw message
Signature · 1 line
2.43.2
PATCH v2 7/14 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 SNP CPUID table is updated to set bit 28 of the EAX register of the 0x8000001f leaf when an SVSM is present. This bit has been reserved for use in this capacity.
For the MSR support, a new reserved MSR 0xc001f000 has been defined. A #VC should be generated when accessing this MSR. The #VC handler is expected to ignore writes to this MSR and return the physical calling area address (CAA) on reads of this MSR.
--- arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/msr-index.h | 2 ++ arch/x86/kernel/sev-shared.c | 11 +++++++++++ arch/x86/kernel/sev.c | 17 +++++++++++++++++ 4 files changed, 31 insertions(+)
arch/x86/include/asm/cpufeatures.h +1 -0
@@ -446,6 +446,7 @@#define X86_FEATURE_V_TSC_AUX (19*32+ 9)/* "" Virtual TSC_AUX */ #define X86_FEATURE_SME_COHERENT (19*32+10)/* "" AMD hardware-enforced cache coherency */ #define X86_FEATURE_DEBUG_SWAP (19*32+14)/* AMD SEV-ES full debug state swap support */ +#define X86_FEATURE_SVSM_PRESENT (19*32+28)/* "" SNP SVSM is present */ /* AMD-defined Extended Feature 2 EAX, CPUID level 0x80000021 (EAX), word 20 */ #define X86_FEATURE_NO_NESTED_DATA_BP (20*32+ 0)/* "" No Nested Data Breakpoints */
arch/x86/include/asm/msr-index.h +2 -0
@@ -646,6 +646,8 @@#define MSR_AMD64_RMP_BASE 0xc0010132#define MSR_AMD64_RMP_END 0xc0010133 +#define MSR_SVSM_CAA 0xc001f000 +/* AMD Collaborative Processor Performance Control MSRs */ #define MSR_AMD_CPPC_CAP1 0xc00102b0#define MSR_AMD_CPPC_ENABLE 0xc00102b1
arch/x86/kernel/sev-shared.c +11 -0
@@ -1559,6 +1559,8 @@ static enum es_result vc_check_opcode_bytes(struct es_em_ctxt *ctxt,static void __init setup_svsm_ca (const struct cc_blob_sev_info *cc_info) {struct snp_secrets_page_layout *secrets_page; +struct snp_cpuid_table *cpuid_table; +unsigned int i;u64 caa;BUILD_BUG_ON (sizeof (*secrets_page) !=PAGE_SIZE );
@@ -1596,4 +1598,13 @@ static void __init setup_svsm_ca(const struct cc_blob_sev_info *cc_info)*/ boot_svsm_caa = (struct svsm_ca *)caa; boot_svsm_caa_pa = caa; + +/* Advertise the SVSM presence via CPUID. */ + cpuid_table = (struct snp_cpuid_table *)snp_cpuid_get_table (); +for (i =0 ; i < cpuid_table->count; i++) { +struct snp_cpuid_fn *fn = &cpuid_table->fn[i]; + +if (fn->eax_in ==0x8000001f ) + fn->eax |=BIT (28 ); + } }
arch/x86/kernel/sev.c +17 -0
@@ -1347,12 +1347,29 @@ int __init sev_es_efi_map_ghcbs(pgd_t *pgd)return 0 ; } +static enum es_result vc_handle_svsm_caa_msr (struct es_em_ctxt *ctxt) +{ +struct pt_regs *regs = ctxt->regs; + +/* Writes to the SVSM CAA msr are ignored */ +if (ctxt->insn.opcode.bytes[1 ] ==0x30 ) +return ES_OK ; + + regs->ax =lower_32_bits (this_cpu_read (svsm_caa_pa)); + regs->dx =upper_32_bits (this_cpu_read (svsm_caa_pa)); + +return ES_OK ; +} +static enum es_result vc_handle_msr (struct ghcb *ghcb,struct es_em_ctxt *ctxt) {struct pt_regs *regs = ctxt->regs;enum es_result ret;u64 exit_info_1; +if (regs->cx ==MSR_SVSM_CAA ) +return vc_handle_svsm_caa_msr (ctxt); +/* Is it a WRMSR? */ exit_info_1 = (ctxt->insn.opcode.bytes[1 ] ==0x30 ) ?1 :0 ;
Signature · 1 line
2.43.2
PATCH v2 8/14 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
@@ -2529,3 +2529,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.43.2
PATCH v2 9/14 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
@@ -308,6 +308,7 @@ u64 sev_get_status(void);void kdump_sev_callback (void );void sev_show_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 ) { }
@@ -339,6 +340,7 @@ static inline u64 sev_get_status(void) { return 0; }static inline void kdump_sev_callback (void ) { }static inline void sev_show_status (void ) { }static inline void snp_remap_svsm_ca (void ) { } +static inline int snp_get_vmpl (void ) {return 0 ; }#endif #ifdef CONFIG_KVM_AMD_SEV
arch/x86/kernel/sev.c +6 -0
@@ -2466,6 +2466,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.43.2
PATCH v2 10/14 configfs-tsm: Allow the privlevel_floor attribute to be updated
In reply to Tom LendackyWith the introduction of an SVSM, Linux will be running at a non-zero VMPL. Any request for an attestation report at a higher priviledge VMPL than what Linux is currently running will result in an error. Allow for the privlevel_floor attribute to be updated dynamically so that the attribute may be set dynamically.
--- drivers/virt/coco/sev-guest/sev-guest.c | 5 ++++- include/linux/tsm.h | 2 +- 2 files changed, 5 insertions(+), 2 deletions(-)
drivers/virt/coco/sev-guest/sev-guest.c +4 -1
@@ -885,7 +885,7 @@ static int sev_report_new(struct tsm_report *report, void *data)return 0 ; } -static const struct tsm_ops sev_tsm_ops = { +static struct tsm_ops sev_tsm_ops = { .name =KBUILD_MODNAME , .report_new = sev_report_new, };
@@ -972,6 +972,9 @@ static int __init sev_guest_probe(struct platform_device *pdev) snp_dev->input.resp_gpa =__pa (snp_dev->response); snp_dev->input.data_gpa =__pa (snp_dev->certs_data); +/* Set the privlevel_floor attribute based on the current VMPL */ + sev_tsm_ops.privlevel_floor =snp_get_vmpl (); + ret =tsm_register (&sev_tsm_ops, snp_dev, &tsm_report_extra_type);if (ret) goto e_free_cert_data;
include/linux/tsm.h +1 -1
@@ -54,7 +54,7 @@ struct tsm_report {*/ struct tsm_ops {const char *name; -const unsigned int privlevel_floor; +unsigned int privlevel_floor;int (*report_new)(struct tsm_report *report,void *data); };
Signature · 1 line
2.43.2
PATCH v2 11/14 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_manifest_version' (input)
Used with the SVSM_ATTEST_SINGLE_SERVICE call, the service version represents a specific service manifest version be used for the attestation report.
- 'manifestblob' (output)
Used to return the service manifest associated with the attestation report.
--- Documentation/ABI/testing/configfs-tsm | 59 ++++++++++ arch/x86/include/asm/sev.h | 31 ++++- arch/x86/kernel/sev.c | 50 ++++++++ drivers/virt/coco/sev-guest/sev-guest.c | 147 ++++++++++++++++++++++++ drivers/virt/coco/tsm.c | 95 ++++++++++++++- include/linux/tsm.h | 11 ++ 6 files changed, 390 insertions(+), 3 deletions(-)
Documentation/ABI/testing/configfs-tsm +59 -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,47 @@ 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 a 1 (or other boolean + equivalent, e.g. "Y") 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_manifest_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_manifest_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. If this field + is not set by the user, the default manifest version of the + service (the service's initial/first manifest version) is + returned. The initial manifest version is always available. + 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
@@ -209,6 +209,27 @@ struct svsm_pvalidate_call {struct svsm_pvalidate_entry entry[]; }; +/* +* The SVSM Attestation related structures +*/ +struct svsm_location_entry { +u64 pa; +u32 len; +u8 rsvd[4 ]; +}; + +struct svsm_attestation_call { +struct svsm_location_entry report_buffer; +struct svsm_location_entry nonce; +struct svsm_location_entry manifest_buffer; +struct svsm_location_entry certificates_buffer; + +/* For attesting a single service */ +u8 service_guid[16 ]; +u32 service_manifest_version; +u8 rsvd[4 ]; +}; +/* * SVSM protocol structure */
@@ -232,6 +253,10 @@ struct svsm_call {#define SVSM_CORE_CREATE_VCPU 2#define SVSM_CORE_DELETE_VCPU 3 +#define SVSM_ATTEST_CALL (x) ((1ULL << 32) | (x)) +#define SVSM_ATTEST_SERVICES 0 +#define SVSM_ATTEST_SINGLE_SERVICE 1 +#ifdef CONFIG_AMD_MEM_ENCRYPT extern void __sev_es_ist_enter (struct pt_regs *regs);extern void __sev_es_ist_exit (void );
@@ -302,6 +327,7 @@ void snp_set_wakeup_secondary_cpu(void);bool snp_init (struct boot_params *bp);void __noreturn snp_abort (void );int snp_issue_guest_request (u64 exit_code,struct snp_req_data *input,struct snp_guest_request_ioctl *rio); +int snp_issue_svsm_attestation_request (u64 call_id,struct svsm_attestation_call *input);void snp_accept_memory (phys_addr_t start,phys_addr_t end);u64 snp_get_unsupported_features (u64 status);u64 sev_get_status (void );
@@ -333,7 +359,10 @@ static inline int snp_issue_guest_request(u64 exit_code, struct snp_req_data *in {return -ENOTTY ; } - +static inline int snp_issue_svsm_attestation_request (u64 call_id,struct svsm_attestation_call *input) +{ +return -ENOTTY ; +}static inline void snp_accept_memory (phys_addr_t start,phys_addr_t end) { }static inline u64 snp_get_unsupported_features (u64 status) {return 0 ; }static inline u64 sev_get_status (void ) {return 0 ; }
arch/x86/kernel/sev.c +50 -0
56 lines not on this page · raw message
drivers/virt/coco/sev-guest/sev-guest.c +147 -0
165 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_manifest_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_manifest_version; };/**
@@ -33,6 +40,8 @@ struct tsm_desc {* @outblob: generated evidence to provider to the attestation agent * @auxblob_len: sizeof(@auxblob) * @auxblob: (optional) auxiliary data to the report (e.g. certificate data) +* @manifestblob_len: sizeof(@manifestblob) +* @manifestblob: (optional) manifest data associated with the report */ struct tsm_report {struct tsm_desc desc;
@@ -40,6 +49,8 @@ struct tsm_report {u8 *outblob;size_t auxblob_len;u8 *auxblob; +size_t manifestblob_len; +u8 *manifestblob; };/**
Signature · 1 line
2.43.2
Re: [PATCH v2 11/14] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 65 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_manifest_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 | 59 ++++++++++ arch/x86/include/asm/sev.h | 31 ++++- arch/x86/kernel/sev.c | 50 ++++++++ drivers/virt/coco/sev-guest/sev-guest.c | 147 ++++++++++++++++++++++++ drivers/virt/coco/tsm.c | 95 ++++++++++++++- include/linux/tsm.h | 11 ++ 6 files changed, 390 insertions(+), 3 deletions(-)Documentation/ABI/testing/configfs-tsm +15
-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,47 @@ 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 a 1 (or other boolean
Since service_guid can be used for non SVSM services as well, can we use a generic term "service" here? And let user specify the service type (like service=svsm)
Quoted 11 lines
Documentation/ABI/testing/configfs-tsm +11
-0+ equivalent, e.g. "Y") 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
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 127
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +10
-0+ 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_manifest_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 +
I think it will be useful to the user if there is a attribute to list the service GUIDs supported. It can help prevent user using incorrect or unsupported GUIDs.
Quoted 201 lines
Documentation/ABI/testing/configfs-tsm +14
-0+What: /sys/kernel/config/tsm/report/$name/service_manifest_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. If this field + is not set by the user, the default manifest version of the + service (the service's initial/first manifest version) is + returned. The initial manifest version is always available. + 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@@ -209,6 +209,27 @@ struct svsm_pvalidate_call {struct svsm_pvalidate_entry entry[]; }; +/* +* The SVSM Attestation related structures +*/ +struct svsm_location_entry { +u64 pa; +u32 len; +u8 rsvd[4 ]; +}; + +struct svsm_attestation_call { +struct svsm_location_entry report_buffer; +struct svsm_location_entry nonce; +struct svsm_location_entry manifest_buffer; +struct svsm_location_entry certificates_buffer; + +/* For attesting a single service */ +u8 service_guid[16 ]; +u32 service_manifest_version; +u8 rsvd[4 ]; +}; +/* * SVSM protocol structure */ @@ -232,6 +253,10 @@ struct svsm_call {#define SVSM_CORE_CREATE_VCPU 2#define SVSM_CORE_DELETE_VCPU 3 +#define SVSM_ATTEST_CALL (x) ((1ULL << 32) | (x)) +#define SVSM_ATTEST_SERVICES 0 +#define SVSM_ATTEST_SINGLE_SERVICE 1 +#ifdef CONFIG_AMD_MEM_ENCRYPT extern void __sev_es_ist_enter (struct pt_regs *regs);extern void __sev_es_ist_exit (void );@@ -302,6 +327,7 @@ void snp_set_wakeup_secondary_cpu(void);bool snp_init (struct boot_params *bp);void __noreturn snp_abort (void );int snp_issue_guest_request (u64 exit_code,struct snp_req_data *input,struct snp_guest_request_ioctl *rio); +int snp_issue_svsm_attestation_request (u64 call_id,struct svsm_attestation_call *input);void snp_accept_memory (phys_addr_t start,phys_addr_t end);u64 snp_get_unsupported_features (u64 status);u64 sev_get_status (void );@@ -333,7 +359,10 @@ static inline int snp_issue_guest_request(u64 exit_code, struct snp_req_data *in {return -ENOTTY ; } - +static inline int snp_issue_svsm_attestation_request (u64 call_id,struct svsm_attestation_call *input) +{ +return -ENOTTY ; +}static inline void snp_accept_memory (phys_addr_t start,phys_addr_t end) { }static inline u64 snp_get_unsupported_features (u64 status) {return 0 ; }static inline u64 sev_get_status (void ) {return 0 ; }arch/x86/kernel/sev.c +50
-0@@ -2402,6 +2402,56 @@ static int __init init_sev_config(char *str) }__setup ("sev=" , init_sev_config); +static void update_attestation_input (struct svsm_call *call,struct svsm_attestation_call *input) +{ +/* If (new) lengths have been returned, propograte them up */ +if (call->rcx_out != call->rcx) + input->manifest_buffer.len = call->rcx_out; + +if (call->rdx_out != call->rdx) + input->certificates_buffer.len = call->rdx_out; + +if (call->r8_out != call->r8) + input->report_buffer.len = call->r8_out; +} + +int snp_issue_svsm_attestation_request (u64 call_id,struct svsm_attestation_call *input) +{ +struct svsm_attestation_call *attest_call; +struct svsm_call call = {}; +unsigned long flags; +u64 attest_call_pa; +int ret; + +if (!vmpl) +return -EINVAL ; + +local_irq_save (flags); + + call.caa =__svsm_get_caa (); + + attest_call = (struct svsm_attestation_call *)call.caa->svsm_buffer; + attest_call_pa =__svsm_get_caa_pa () + offsetof(struct svsm_ca , svsm_buffer); + + *attest_call = *input; + +/* +* Set input registers for the request and set RDX and R8 to known +* values in order to detect length values being returned in them. +*/ + call.rax = call_id; + call.rcx = attest_call_pa; + call.rdx =-1 ; + call.r8 =-1 ; + ret =svsm_protocol (&call); +update_attestation_input (&call, input); + +local_irq_restore (flags); + +return ret; +} +EXPORT_SYMBOL_GPL (snp_issue_svsm_attestation_request); +int snp_issue_guest_request (u64 exit_code,struct snp_req_data *input,struct snp_guest_request_ioctl *rio) {struct ghcb_state state;drivers/virt/coco/sev-guest/sev-guest.c +48
-0@@ -38,6 +38,8 @@#define SNP_REQ_MAX_RETRY_DURATION (60*HZ)#define SNP_REQ_RETRY_DELAY (2*HZ) +#define SVSM_MAX_RETRIES 3 +struct snp_guest_crypto {struct crypto_aead *tfm;u8 *iv, *authtag;@@ -783,6 +785,148 @@ struct snp_msg_cert_entry {u32 length; }; +static int sev_svsm_report_new (struct tsm_report *report,void *data) +{ +unsigned int report_len, manifest_len, certificates_len; +void *report_blob, *manifest_blob, *certificates_blob; +struct svsm_attestation_call attest_call = {}; +struct tsm_desc *desc = &report->desc; +unsigned int retry_count; +unsigned int size; +bool try_again; +void *buffer; +u64 call_id; +int ret; + +/* +* Allocate pages for the request: +* - Report blob (4K) +* - Manifest blob (4K) +* - Certificate blob (16K) +* +* Above addresses must be 4K aligned +*/ + report_len =SZ_4K ; + manifest_len =SZ_4K ; + certificates_len =SEV_FW_BLOB_MAX_SIZE ; + + retry_count =0 ; + +retry: + size = report_len + manifest_len + certificates_len; + buffer =alloc_pages_exact (size, __GFP_ZERO); +if (!buffer) +return -ENOMEM ; + + report_blob = buffer; + attest_call.report_buffer.pa =__pa (report_blob); + attest_call.report_buffer.len = report_len; + + manifest_blob = report_blob + report_len; + attest_call.manifest_buffer.pa =__pa (manifest_blob); + attest_call.manifest_buffer.len = manifest_len; + + certificates_blob = manifest_blob + manifest_len; + attest_call.certificates_buffer.pa =__pa (certificates_blob); + attest_call.certificates_buffer.len = certificates_len; + + attest_call.nonce.pa =__pa (desc->inblob);
drivers/virt/coco/sev-guest/sev-guest.c struct snp_msg_cert_entry { · line 843
Quoted 10 lines
drivers/virt/coco/sev-guest/sev-guest.c +10
-0+ 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_manifest_version = desc->service_manifest_version; + + call_id =SVSM_ATTEST_CALL (SVSM_ATTEST_SINGLE_SERVICE ); + }
Above initialization will not change during retry, right? Why not move it above retry?
Quoted 152 lines
drivers/virt/coco/sev-guest/sev-guest.c +89
-0+ + ret =snp_issue_svsm_attestation_request (call_id, &attest_call); +switch (ret) { +case SVSM_SUCCESS : +break ; +case SVSM_ERR_INVALID_PARAMETER : + ret = -EINVAL ; + +if (retry_count >=SVSM_MAX_RETRIES ) + goto error; + + try_again = false; + +if (attest_call.report_buffer.len > report_len) { + report_len =PAGE_ALIGN (attest_call.report_buffer.len); + try_again = true; + } + +if (attest_call.manifest_buffer.len > manifest_len) { + manifest_len =PAGE_ALIGN (attest_call.manifest_buffer.len); + try_again = true; + } + +if (attest_call.certificates_buffer.len > certificates_len) { + certificates_len =PAGE_ALIGN (attest_call.certificates_buffer.len); + try_again = true; + } + +/* If one of the buffers wasn't large enough, retry the request */ +if (try_again) { +free_pages_exact (buffer, size); + retry_count++; + goto retry; + } + + goto error; +case SVSM_ERR_BUSY : + ret = -EAGAIN ; + goto error; +default : +pr_err_ratelimited ("SVSM attestation request failed (%#x)\n" , ret); + ret = -EINVAL ; + goto error; + } + + ret = -ENOMEM ; + + report_len = attest_call.report_buffer.len; + void *rbuf __free(kvfree) = kvzalloc(report_len, GFP_KERNEL); +if (!rbuf) + goto error; + +memcpy (rbuf, report_blob, report_len); + report->outblob =no_free_ptr (rbuf); + report->outblob_len = report_len; + + manifest_len = attest_call.manifest_buffer.len; + void *mbuf __free(kvfree) = kvzalloc(manifest_len, GFP_KERNEL); +if (!mbuf) + goto error; + +memcpy (mbuf, manifest_blob, manifest_len); + report->manifestblob =no_free_ptr (mbuf); + report->manifestblob_len = manifest_len; + + certificates_len = attest_call.certificates_buffer.len; +if (!certificates_len) + goto success; + + void *cbuf __free(kvfree) = kvzalloc(certificates_len, GFP_KERNEL); +if (!cbuf) + goto error; + +memcpy (cbuf, certificates_blob, certificates_len); + report->auxblob =no_free_ptr (cbuf); + report->auxblob_len = certificates_len; + +success: + ret =0 ; + +error: +free_pages_exact (buffer, size); + +return ret; +} +static int sev_report_new (struct tsm_report *report,void *data) {struct snp_msg_cert_entry *cert_table;@@ -797,6 +941,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 +30
-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); +bool val; +int rc; + + rc =kstrtobool (buf, &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; +
drivers/virt/coco/tsm.c static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg, · line 160
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; + +/* 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 ; +
I don't think you need above checks. I think guid_parse will fail, if it is not a valid GUID.
drivers/virt/coco/tsm.c static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg, · line 166
Quoted 6 lines
drivers/virt/coco/tsm.c +6
-0+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;
I think the default value will be guid_null right, why reset it to NULL for every failed attempt?
Quoted 150 lines
drivers/virt/coco/tsm.c +47
-1+ } + +return len; +} +CONFIGFS_ATTR_WO (tsm_report_, service_guid); + +static ssize_t tsm_report_service_manifest_version_store (struct config_item *cfg, +const char *buf,size_t len) +{ +struct tsm_report *report =to_tsm_report (cfg); +unsigned int val; +int rc; + + rc =kstrtouint (buf,0 , &val); +if (rc) +return rc; + +guard (rwsem_write)(&tsm_rwsem); + rc =try_advance_write_generation (report); +if (rc) +return rc; + report->desc.service_manifest_version = val; + +return len; +} +CONFIGFS_ATTR_WO (tsm_report_, service_manifest_version); +static ssize_t tsm_report_inblob_write (struct config_item *cfg,const void *buf,size_t count) {@@ -163,6 +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_manifest_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
-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_manifest_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_manifest_version; };/** @@ -33,6 +40,8 @@ struct tsm_desc {* @outblob: generated evidence to provider to the attestation agent * @auxblob_len: sizeof(@auxblob) * @auxblob: (optional) auxiliary data to the report (e.g. certificate data) +* @manifestblob_len: sizeof(@manifestblob) +* @manifestblob: (optional) manifest data associated with the report */ struct tsm_report {struct tsm_desc desc;@@ -40,6 +49,8 @@ struct tsm_report {u8 *outblob;size_t auxblob_len;u8 *auxblob; +size_t manifestblob_len; +u8 *manifestblob; };/**
Signature · 2 lines
Sathyanarayanan Kuppuswamy Linux Kernel Developer
Re: [PATCH v2 11/14] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 43 lines · Sathyanarayanan
Quoted 40 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_manifest_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 | 59 ++++++++++ arch/x86/include/asm/sev.h | 31 ++++- arch/x86/kernel/sev.c | 50 ++++++++ drivers/virt/coco/sev-guest/sev-guest.c | 147 ++++++++++++++++++++++++ drivers/virt/coco/tsm.c | 95 ++++++++++++++- include/linux/tsm.h | 11 ++ 6 files changed, 390 insertions(+), 3 deletions(-)Documentation/ABI/testing/configfs-tsm +0
-0
Quoted 13 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 106
Quoted 9 lines
Documentation/ABI/testing/configfs-tsm +9
-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 a 1 (or other booleanSince
service_guidcan be used for non SVSM services as well, can we use a generic term "service" here? And let user specify the service type (like service=svsm)
I suppose that's possible. I think we would need a better term than just service, though, since service_guid is specific to a service within the service provider... so maybe service_provider.
Quoted 17 lines
Quoted 17 lines
Documentation/ABI/testing/configfs-tsm +16
-0+ equivalent, e.g. "Y") 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
Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 127
Quoted 5 lines
Documentation/ABI/testing/configfs-tsm +5
-0+ specified service using the manifest form specified by the + service_manifest_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 +I think it will be useful to the user if there is a attribute to list the service GUIDs supported. It can help prevent user using incorrect or unsupported GUIDs.
A list of supported GUIDs can be obtained from the manifest of a all-services attestation request.
Quoted 11 lines
Documentation/ABI/testing/configfs-tsm
Quoted 8 lines
Quoted 1 line
drivers/virt/coco/sev-guest/sev-guest.c +1
-0+if (guid_is_null (&desc->service_guid)) {Documentation/ABI/testing/configfs-tsm +7
-0+ call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SERVICES); + } else { + export_guid(attest_call.service_guid, &desc->service_guid); + attest_call.service_manifest_version = desc->service_manifest_version; + + call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SINGLE_SERVICE); + }Above initialization will not change during retry, right? Why not move it above retry?
True, will move it outside of the loop.
Quoted 11 lines
Documentation/ABI/testing/configfs-tsm
Quoted 8 lines
Documentation/ABI/testing/configfs-tsm +6
-0+ + /* 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; +I don't think you need above checks. I think
guid_parsewill fail, if it is not a valid GUID.
Yes and no. The guid_parse() function will succeed if the string is longer than UUID_STRING_LEN as long as it is a valid UUID up to UUID_STRING_LEN. In other words, guid_parse() of:
aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
and
aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee-gg
both succeed.
I'm ok with eliminating the length calculation and check if everyone is in favor of doing that given the above behavior.
Quoted 9 lines
Documentation/ABI/testing/configfs-tsm
Quoted 7 lines
Documentation/ABI/testing/configfs-tsm +6
-0+ 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;I think the default value will be
guid_nullright, why reset it to NULL for every failed attempt?
Default, yes. But what if it is written once, then a second time with an invalid GUID. Should the previously written GUID still be used?
Thanks,
Tom
Quoted 1 line
Re: [PATCH v2 11/14] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 58 lines · Tom Lendacky
Quoted 43 lines · Sathyanarayanan
Quoted 40 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_manifest_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 | 59 ++++++++++ arch/x86/include/asm/sev.h | 31 ++++- arch/x86/kernel/sev.c | 50 ++++++++drivers/virt/coco/sev-guest/sev-guest.c| 147 ++++++++++++++++++++++++ drivers/virt/coco/tsm.c | 95 ++++++++++++++- include/linux/tsm.h | 11 ++6 files changed, 390 insertions(+), 3 deletions(-)Documentation/ABI/testing/configfs-tsm +0
-0Quoted 13 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 106
Quoted 9 lines
Documentation/ABI/testing/configfs-tsm +9
-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 a 1 (or other booleanSince
service_guidcan be used for non SVSM services as well, can we use a generic term "service" here? And let user specify the service type (like service=svsm)
Quoted 1 line
I suppose that's possible. I think we would need a better term than just service, though, since
service_guidis specific to a service within the service provider... so maybeservice_provider.
I am ok with service_provider
Quoted 27 lines
Quoted 18 lines
Quoted 18 lines
+ equivalent, e.g. "Y") 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.pdfDocumentation/ABI/testing/configfs-tsm +12
-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 + a non-null GUID requests an attestation report of just theQuoted 8 lines
Quoted 5 lines
+ specified service using the manifest form specified by the
+service_manifest_versionattribute.
+ 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 think it will be useful to the user if there is a attribute to list the service GUIDs supported. It can help prevent user using incorrect or unsupported GUIDs.
Quoted 1 line
A list of supported GUIDs can be obtained from the manifest of a all-services attestation request.
So they have to make a request twice? Once with a NULL GUID to get the manifest with all service list, and another to make service-specific request? There should be a fixed list of service GUIDs, right? Why not list them by default?
Quoted 29 lines
Quoted 10 lines
>> + if (
guid_is_null(&desc->service_guid)) {Quoted 7 lines
+
call_id=SVSM_ATTEST_CALL(SVSM_ATTEST_SERVICES);
+ } else {
+export_guid(attest_call.service_guid, &desc->service_guid); + attest_call.service_manifest_version =desc->service_manifest_version; +
+call_id=SVSM_ATTEST_CALL(SVSM_ATTEST_SINGLE_SERVICE);
+ }Quoted 2 lines
Above initialization will not change during retry, right? Why not move it above retry?
True, will move it outside of the loop.
Quoted 11 lines
Documentation/ABI/testing/configfs-tsm
Quoted 8 lines
Documentation/ABI/testing/configfs-tsm +6
-0+ + /* 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; +I don't think you need above checks. I think
guid_parsewill fail, if it is not a valid GUID.Yes and no. The
guid_parse()function will succeed if the string is longer thanUUID_STRING_LENas long as it is a valid UUID up toUUID_STRING_LEN. In other words,guid_parse()of:
Quoted 8 lines
aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
and
aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee-ggboth succeed.
I'm ok with eliminating the length calculation and check if everyone is in favor of doing that given the above behavior.
Got it. Existing callers of guid_parse() does not seem to care about it. But I am fine either way.
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
+ 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;
Quoted 4 lines
Quoted 1 line
I think the default value will be
guid_nullright, why reset it to NULL for every failed attempt?Default, yes. But what if it is written once, then a second time with an invalid GUID. Should the previously written GUID still be used?
If the user write fails, why update the state? IMO, we can leave it at the old value. But, lets see what others think.
Quoted 4 lines
Thanks,
TomQuoted 1 line
Signature · 2 lines
Sathyanarayanan Kuppuswamy Linux Kernel Developer
Re: [PATCH v2 11/14] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 68 lines · Kuppuswamy Sathyanarayanan
Quoted 66 lines · Tom Lendacky
Quoted 64 lines · Sathyanarayanan
Quoted 49 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_manifest_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 | 59 ++++++++++ arch/x86/include/asm/sev.h | 31 ++++- arch/x86/kernel/sev.c | 50 ++++++++ drivers/virt/coco/sev-guest/sev-guest.c | 147 ++++++++++++++++++++++++ drivers/virt/coco/tsm.c | 95 ++++++++++++++- include/linux/tsm.h | 11 ++ 6 files changed, 390 insertions(+), 3 deletions(-)Documentation/ABI/testing/configfs-tsm +7
-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 providerDocumentation/ABI/testing/configfs-tsm Contact: [email protected] · line 127
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +10
-0+ 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_manifest_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 +I think it will be useful to the user if there is a attribute to list the service GUIDs supported. It can help prevent user using incorrect or unsupported GUIDs.
Quoted 6 lines
Quoted 1 line
A list of supported GUIDs can be obtained from the manifest of a all-services attestation request.
So they have to make a request twice? Once with a NULL GUID to get the manifest with all service list, and another to make service-specific request? There should be a fixed list of service GUIDs, right? Why not list them by default?
It's not a fixed list. It may appear that way today, but as other services are added, then it is impossible for a kernel to know what services are present in the SVSM without querying it.
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
+ 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;
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
I think the default value will be
guid_nullright, why reset it to NULL for every failed attempt?Default, yes. But what if it is written once, then a second time with an invalid GUID. Should the previously written GUID still be used?
If the user write fails, why update the state? IMO, we can leave it at the old value. But, lets see what others think.
Sounds good.
Thanks,
Tom
Quoted 5 lines
Quoted 5 lines
Thanks,
TomQuoted 1 line
PATCH v2 12/14 fs/configfs: Add a callback to determine attribute visibility
In reply to Tom LendackyIn order to support dynamic decisions as to whether an attribute should be created, add a callback that returns a bool to indicate whether the attribute should be display. If no callback is registered, the attribute is displayed by default.
--- fs/configfs/file.c | 13 +++++ include/linux/configfs.h | 114 +++++++++++++++++++++++++++------------ 2 files changed, 93 insertions(+), 34 deletions(-)
fs/configfs/file.c +13 -0
@@ -451,6 +451,12 @@ int configfs_create_file(struct config_item * item, const struct configfs_attribumode_t mode = (attr->ca_mode &S_IALLUGO ) |S_IFREG ;int error =0 ; +if (attr->ca_is_visible) { + mode = attr->ca_is_visible (item, attr); +if (!mode) +return 0 ; + } +inode_lock_nested (d_inode (dir),I_MUTEX_NORMAL ); error =configfs_make_dirent (parent_sd,NULL , (void *) attr, mode,CONFIGFS_ITEM_ATTR , parent_sd->s_frag);
@@ -470,9 +476,16 @@ int configfs_create_bin_file(struct config_item *item, {struct dentry *dir = item->ci_dentry;struct configfs_dirent *parent_sd = dir->d_fsdata; +const struct configfs_attribute *attr = &bin_attr->cb_attr;umode_t mode = (bin_attr->cb_attr.ca_mode &S_IALLUGO ) |S_IFREG ;int error =0 ; +if (attr->ca_is_visible) { + mode = attr->ca_is_visible (item, attr); +if (!mode) +return 0 ; + } +inode_lock_nested (dir->d_inode,I_MUTEX_NORMAL ); error =configfs_make_dirent (parent_sd,NULL , (void *) bin_attr, mode,CONFIGFS_ITEM_BIN_ATTR , parent_sd->s_frag);
include/linux/configfs.h +80 -34
162 lines not on this page · raw message
Signature · 1 line
2.43.2
Re: [PATCH v2 12/14] fs/configfs: Add a callback to determine attribute visibility
Quoted 18 lines · Tom Lendacky
In order to support dynamic decisions as to whether an attribute should be created, add a callback that returns a bool to indicate whether the attribute should be display. If no callback is registered, the attribute is displayed by default.
Cc Joel Becker <[email protected]>Cc Christoph Hellwig <[email protected]>Signed-off-by Tom Lendacky <[email protected]>--- fs/configfs/file.c | 13 +++++ include/linux/configfs.h | 114 +++++++++++++++++++++++++++------------ 2 files changed, 93 insertions(+), 34 deletions(-)fs/configfs/file.c +0
-0
fs/configfs/file.c int configfs_create_file(struct config_item * item, const struct configfs_attrib · line 451
Quoted 1 line
fs/configfs/file.c +0
-0@@ -451,6 +451,12 @@ int configfs_create_file(struct config_item * item, const struct configfs_attribumode_t mode = (attr->ca_mode &S_IALLUGO ) |S_IFREG ;
I missed making this adjustment on the returned mode parameter below. So this patch will change slightly to just initialize mode to attr->ca_mode and then after the if statement, apply the masks as done above.
Thanks,
Tom
Quoted 28 lines
fs/configfs/file.c +13
-0int error =0 ; +if (attr->ca_is_visible) { + mode = attr->ca_is_visible (item, attr); +if (!mode) +return 0 ; + } +inode_lock_nested (d_inode (dir),I_MUTEX_NORMAL ); error =configfs_make_dirent (parent_sd,NULL , (void *) attr, mode,CONFIGFS_ITEM_ATTR , parent_sd->s_frag);@@ -470,9 +476,16 @@ int configfs_create_bin_file(struct config_item *item, {struct dentry *dir = item->ci_dentry;struct configfs_dirent *parent_sd = dir->d_fsdata; +const struct configfs_attribute *attr = &bin_attr->cb_attr;umode_t mode = (bin_attr->cb_attr.ca_mode &S_IALLUGO ) |S_IFREG ;int error =0 ; +if (attr->ca_is_visible) { + mode = attr->ca_is_visible (item, attr); +if (!mode) +return 0 ; + } +inode_lock_nested (dir->d_inode,I_MUTEX_NORMAL ); error =configfs_make_dirent (parent_sd,NULL , (void *) bin_attr, mode,CONFIGFS_ITEM_BIN_ATTR , parent_sd->s_frag);
Re: [PATCH v2 12/14] fs/configfs: Add a callback to determine attribute visibility
In reply to Tom LendackyQuoted 4 lines · Tom Lendacky
In order to support dynamic decisions as to whether an attribute should be created, add a callback that returns a bool to indicate whether the attribute should be display. If no callback is registered, the attribute is displayed by default.
I'm curious what the strong value is in this extra callback. As opposed to not generating the attribute in the absence of a TPM (why create a config_item at all?), merely having an empty response from the attribute, or having ->show() return -ENODEV or similar.
Quoted 14 lines
Cc Joel Becker <[email protected]>Cc Christoph Hellwig <[email protected]>Signed-off-by Tom Lendacky <[email protected]>--- fs/configfs/file.c | 13 +++++ include/linux/configfs.h | 114 +++++++++++++++++++++++++++------------ 2 files changed, 93 insertions(+), 34 deletions(-)fs/configfs/file.c +0
-0
fs/configfs/file.c int configfs_create_file(struct config_item * item, const struct configfs_attrib · line 457
Quoted 7 lines
fs/configfs/file.c +4
-0@@ -451,6 +451,12 @@ int configfs_create_file(struct config_item * item, const struct configfs_attribumode_t mode = (attr->ca_mode &S_IALLUGO ) |S_IFREG ;int error =0 ; +if (attr->ca_is_visible) { + mode = attr->ca_is_visible (item, attr); +if (!mode) +return 0 ;
What value do we get from carrying the mode through here? The API proposed is "visible or not", which is a boolean. Overloading that with "also set the mode" is confusing, and it also can lead to the divergent codepath problem you mentioned in your response, where ->ca_is_visible() fails to return the mode correctly. If this was simpl a boolean hook, the code could read like so:
``` umode_t mode = (attr->ca_mode & S_IALLUGO) | S_IFREG; int error = 0; if (attr->ca_is_visible && !attr->ca_is_visible(item, attr)) return 0; ```
include/linux/configfs.h static inline void configfs_add_default_group(struct config_group *new_group, · line 117
Quoted 11 lines
include/linux/configfs.h +3
-0@@ -112,39 +112,64 @@ static inline void configfs_add_default_group(struct config_group *new_group,list_add_tail (&new_group->group_entry, &group->default_groups); } +typedef umode_t (*configfs_is_visible_t )(const struct config_item *item, +const struct configfs_attribute *attr); +
We don't use typedefs of op functions anywhere else in configfs or frankly the entire filesystem API. Adding one here would just introduce confusion.
include/linux/configfs.h static inline void configfs_add_default_group(struct config_group *new_group, · line 126
Quoted 9 lines
include/linux/configfs.h +1
-0struct configfs_attribute {const char *ca_name;struct module *ca_owner;umode_t ca_mode; +configfs_is_visible_t ca_is_visible;ssize_t (*show)(struct config_item *,char *);ssize_t (*store)(struct config_item *,const char *,size_t ); };
Thanks,
Joel
Signature · 6 lines
Life's Little Instruction Book #306 "Take a nap on Sunday afternoons." http://www.jlbec.org/ [email protected]
Re: [PATCH v2 12/14] fs/configfs: Add a callback to determine attribute visibility
Quoted 10 lines · Joel Becker
Quoted 4 lines · Tom Lendacky
In order to support dynamic decisions as to whether an attribute should be created, add a callback that returns a bool to indicate whether the attribute should be display. If no callback is registered, the attribute is displayed by default.
I'm curious what the strong value is in this extra callback. As opposed to not generating the attribute in the absence of a TPM (why create a
config_itemat all?), merely having an empty response from the attribute, or having->show()return-ENODEVor similar.
The value is to reduce the complexity of registering with the TSM support across multiple vendors. There is a base set of attributes that are common across vendors and some that are specific to vendors. Creating this structure in the TSM support can get unwieldy. This would make it simple to determine if support is provided since the attribute will either be present or not.
This would also make the support similar to sysfs in the ability to dynamically hide or show attributes.
Quoted 18 lines
Quoted 18 lines
Cc Joel Becker <[email protected]>Cc Christoph Hellwig <[email protected]>Signed-off-by Tom Lendacky <[email protected]>--- fs/configfs/file.c | 13 +++++ include/linux/configfs.h | 114 +++++++++++++++++++++++++++------------ 2 files changed, 93 insertions(+), 34 deletions(-)fs/configfs/file.c +0
-0@@ -451,6 +451,12 @@ int configfs_create_file(struct config_item * item, const struct configfs_attribumode_t mode = (attr->ca_mode &S_IALLUGO ) |S_IFREG ;int error =0 ;
Quoted 11 lines
fs/configfs/file.c int configfs_create_file(struct config_item * item, const struct configfs_attrib · line 457
Quoted 4 lines
fs/configfs/file.c +4
-0+if (attr->ca_is_visible) { + mode = attr->ca_is_visible (item, attr); +if (!mode) +return 0 ;What value do we get from carrying the mode through here? The API proposed is "visible or not", which is a boolean. Overloading that with "also set the mode" is confusing, and it also can lead to the divergent codepath problem you mentioned in your response, where
->ca_is_visible()fails to return the mode correctly. If this was simpl a boolean hook, the code could read like so:
A boolean would work. There was a request to make this similar to the sysfs attribute visibility. I certainly can make this a simple bool function if that is preferable.
Quoted 18 lines
``` umode_t mode = (attr->ca_mode & S_IALLUGO) | S_IFREG; int error = 0; if (attr->ca_is_visible && !attr->ca_is_visible(item, attr)) return 0; ```Quoted 8 lines
include/linux/configfs.h +0
-0@@ -112,39 +112,64 @@ static inline void configfs_add_default_group(struct config_group *new_group,list_add_tail (&new_group->group_entry, &group->default_groups); }
Quoted 7 lines
include/linux/configfs.h static inline void configfs_add_default_group(struct config_group *new_group, · line 117
Quoted 3 lines
include/linux/configfs.h +3
-0+typedef umode_t (*configfs_is_visible_t )(const struct config_item *item, +const struct configfs_attribute *attr); +We don't use typedefs of op functions anywhere else in configfs or frankly the entire filesystem API. Adding one here would just introduce confusion.
Sure, I can remove that and do something similar to show/store.
Thanks,
Tom
Quoted 15 lines
include/linux/configfs.h static inline void configfs_add_default_group(struct config_group *new_group, · line 126
Quoted 10 lines
include/linux/configfs.h +1
-0struct configfs_attribute {const char *ca_name;struct module *ca_owner;umode_t ca_mode; +configfs_is_visible_t ca_is_visible;ssize_t (*show)(struct config_item *,char *);ssize_t (*store)(struct config_item *,const char *,size_t ); };Thanks,
Joel
Re: [PATCH v2 12/14] fs/configfs: Add a callback to determine attribute visibility
Quoted 52 lines · Tom Lendacky
Quoted 10 lines · Joel Becker
Quoted 4 lines · Tom Lendacky
In order to support dynamic decisions as to whether an attribute should be created, add a callback that returns a bool to indicate whether the attribute should be display. If no callback is registered, the attribute is displayed by default.
I'm curious what the strong value is in this extra callback. As opposed to not generating the attribute in the absence of a TPM (why create a
config_itemat all?), merely having an empty response from the attribute, or having->show()return-ENODEVor similar.The value is to reduce the complexity of registering with the TSM support across multiple vendors. There is a base set of attributes that are common across vendors and some that are specific to vendors. Creating this structure in the TSM support can get unwieldy. This would make it simple to determine if support is provided since the attribute will either be present or not.
This would also make the support similar to sysfs in the ability to dynamically hide or show attributes.
Quoted 18 lines
Quoted 18 lines
Cc Joel Becker <[email protected]>Cc Christoph Hellwig <[email protected]>Signed-off-by Tom Lendacky <[email protected]>--- fs/configfs/file.c | 13 +++++ include/linux/configfs.h | 114 +++++++++++++++++++++++++++------------ 2 files changed, 93 insertions(+), 34 deletions(-)fs/configfs/file.c +0
-0@@ -451,6 +451,12 @@ int configfs_create_file(struct config_item * item, const struct configfs_attribumode_t mode = (attr->ca_mode &S_IALLUGO ) |S_IFREG ;int error =0 ;Quoted 11 lines
fs/configfs/file.c int configfs_create_file(struct config_item * item, const struct configfs_attrib · line 457
Quoted 4 lines
fs/configfs/file.c +4
-0+if (attr->ca_is_visible) { + mode = attr->ca_is_visible (item, attr); +if (!mode) +return 0 ;What value do we get from carrying the mode through here? The API proposed is "visible or not", which is a boolean. Overloading that with "also set the mode" is confusing, and it also can lead to the divergent codepath problem you mentioned in your response, where
->ca_is_visible()fails to return the mode correctly. If this was simpl a boolean hook, the code could read like so:
Quoted 3 lines
A boolean would work. There was a request to make this similar to the sysfs attribute visibility. I certainly can make this a simple bool function if that is preferable.
The inspiration was sysfs is_visible() and an idea to reproduce the "static declaration + dynamic visibility" model that sysfs allows. However, in the near term boolean visibility is sufficient since the attributes are either on/off by vendor not read-write/read-only by vendor implementation.
PATCH v2 13/14 x86/sev: Hide SVSM attestation entries if not running under an SVSM
In reply to Tom LendackyConfig-fs provides support to hide individual attribute entries. Using this support, base the display of the SVSM related entries on the presence of an SVSM.
--- arch/x86/coco/core.c | 4 ++++ drivers/virt/coco/tsm.c | 13 +++++++++---- include/linux/cc_platform.h | 8 ++++++++ 3 files changed, 21 insertions(+), 4 deletions(-)
arch/x86/coco/core.c +4 -0
@@ -12,6 +12,7 @@#include <asm/coco.h> #include <asm/processor.h> +#include <asm/sev.h> enum cc_vendor cc_vendor__ro_after_init =CC_VENDOR_NONE ;u64 cc_mask__ro_after_init ;
@@ -78,6 +79,9 @@ static bool noinstr amd_cc_platform_has(enum cc_attr attr)case CC_ATTR_GUEST_STATE_ENCRYPT :return sev_status &MSR_AMD64_SEV_ES_ENABLED ; +case CC_ATTR_GUEST_SVSM_PRESENT : +return snp_get_vmpl (); +/* * With SEV, the rep string I/O instructions need to be unrolled * but SEV-ES supports them through the #VC handler.
drivers/virt/coco/tsm.c +9 -4
@@ -64,6 +64,11 @@ static struct tsm_report_state *to_state(struct tsm_report *report) return container_of(report, struct tsm_report_state, report); } +static umode_t svsm_visibility (const struct config_item *item,const struct configfs_attribute *attr) +{ +return cc_platform_has (CC_ATTR_GUEST_SVSM_PRESENT ) ? attr->ca_mode :0 ; +} +static int try_advance_write_generation (struct tsm_report *report) {struct tsm_report_state *state =to_state (report);
@@ -139,7 +144,7 @@ static ssize_t tsm_report_svsm_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_WO (tsm_report_, svsm); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, svsm, svsm_visibility);static ssize_t tsm_report_service_guid_store (struct config_item *cfg,const char *buf,size_t len)
@@ -168,7 +173,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_WO (tsm_report_, service_guid); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_guid, svsm_visibility);static ssize_t tsm_report_service_manifest_version_store (struct config_item *cfg,const char *buf,size_t len)
@@ -189,7 +194,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfgreturn len; } -CONFIGFS_ATTR_WO (tsm_report_, service_manifest_version); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_manifest_version, svsm_visibility);static ssize_t tsm_report_inblob_write (struct config_item *cfg,const void *buf,size_t count)
@@ -336,7 +341,7 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,return tsm_report_read (report, buf, count,TSM_MANIFEST ); } -CONFIGFS_BIN_ATTR_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX ); +CONFIGFS_BIN_ATTR_VISIBLE_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX , svsm_visibility);#define TSM_DEFAULT_ATTRS () \ &tsm_report_attr_generation, \
include/linux/cc_platform.h +8 -0
@@ -90,6 +90,14 @@ enum cc_attr {* Examples include TDX Guest. */ CC_ATTR_HOTPLUG_DISABLED , + +/** +* @CC_ATTR_GUEST_SVSM_PRESENT: Guest is running under an SVSM +* +* The platform/OS is running as a guest/virtual machine and is +* running under a Secure VM Service Module (SVSM). +*/ + CC_ATTR_GUEST_SVSM_PRESENT, };#ifdef CONFIG_ARCH_HAS_CC_PLATFORM
Signature · 1 line
2.43.2
Re: [PATCH v2 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
Quoted 40 lines · Tom Lendacky
Config-fs provides support to hide individual attribute entries. Using this support, base the display of the SVSM related entries on the presence of an SVSM.
Cc Joel Becker <[email protected]>Cc Christoph Hellwig <[email protected]>Signed-off-by Tom Lendacky <[email protected]>--- arch/x86/coco/core.c | 4 ++++ drivers/virt/coco/tsm.c | 13 +++++++++---- include/linux/cc_platform.h | 8 ++++++++ 3 files changed, 21 insertions(+), 4 deletions(-)arch/x86/coco/core.c +4
-0@@ -12,6 +12,7 @@#include <asm/coco.h> #include <asm/processor.h> +#include <asm/sev.h> enum cc_vendor cc_vendor__ro_after_init =CC_VENDOR_NONE ;u64 cc_mask__ro_after_init ;@@ -78,6 +79,9 @@ static bool noinstr amd_cc_platform_has(enum cc_attr attr)case CC_ATTR_GUEST_STATE_ENCRYPT :return sev_status &MSR_AMD64_SEV_ES_ENABLED ; +case CC_ATTR_GUEST_SVSM_PRESENT : +return snp_get_vmpl (); +/* * With SEV, the rep string I/O instructions need to be unrolled * but SEV-ES supports them through the #VC handler. drivers/virt/coco/tsm.c +0
-0
drivers/virt/coco/tsm.c static struct tsm_report_state *to_state(struct tsm_report *report) · line 71
Quoted 8 lines
drivers/virt/coco/tsm.c +5
-0@@ -64,6 +64,11 @@ static struct tsm_report_state *to_state(struct tsm_report *report) return container_of(report, struct tsm_report_state, report); } +static umode_t svsm_visibility (const struct config_item *item,const struct configfs_attribute *attr) +{ +return cc_platform_has (CC_ATTR_GUEST_SVSM_PRESENT ) ? attr->ca_mode :0 ; +} +
Instead of directly checking for CC flags here, I am wondering if it would make sense to add a callback to vendor drivers and let the callback decide whether the attribute is valid or not? We can't add a CC flag for every ConfigFS attribute, right? For example, privlevel is not used by TDX. If there is a callback, then TDX driver can make this attribute invalid for it.
Quoted 58 lines
drivers/virt/coco/tsm.c +4
-4static int try_advance_write_generation (struct tsm_report *report) {struct tsm_report_state *state =to_state (report);@@ -139,7 +144,7 @@ static ssize_t tsm_report_svsm_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_WO (tsm_report_, svsm); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, svsm, svsm_visibility);static ssize_t tsm_report_service_guid_store (struct config_item *cfg,const char *buf,size_t len)@@ -168,7 +173,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_WO (tsm_report_, service_guid); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_guid, svsm_visibility);static ssize_t tsm_report_service_manifest_version_store (struct config_item *cfg,const char *buf,size_t len)@@ -189,7 +194,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfgreturn len; } -CONFIGFS_ATTR_WO (tsm_report_, service_manifest_version); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_manifest_version, svsm_visibility);static ssize_t tsm_report_inblob_write (struct config_item *cfg,const void *buf,size_t count)@@ -336,7 +341,7 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,return tsm_report_read (report, buf, count,TSM_MANIFEST ); } -CONFIGFS_BIN_ATTR_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX ); +CONFIGFS_BIN_ATTR_VISIBLE_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX , svsm_visibility);#define TSM_DEFAULT_ATTRS () \ &tsm_report_attr_generation, \include/linux/cc_platform.h +8
-0@@ -90,6 +90,14 @@ enum cc_attr {* Examples include TDX Guest. */ CC_ATTR_HOTPLUG_DISABLED , + +/** +* @CC_ATTR_GUEST_SVSM_PRESENT: Guest is running under an SVSM +* +* The platform/OS is running as a guest/virtual machine and is +* running under a Secure VM Service Module (SVSM). +*/ + CC_ATTR_GUEST_SVSM_PRESENT, };#ifdef CONFIG_ARCH_HAS_CC_PLATFORM
Signature · 2 lines
Sathyanarayanan Kuppuswamy Linux Kernel Developer
Re: [PATCH v2 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
Quoted 45 lines · Sathyanarayanan
Quoted 43 lines · Tom Lendacky
Config-fs provides support to hide individual attribute entries. Using this support, base the display of the SVSM related entries on the presence of an SVSM.
Cc Joel Becker <[email protected]>Cc Christoph Hellwig <[email protected]>Signed-off-by Tom Lendacky <[email protected]>--- arch/x86/coco/core.c | 4 ++++ drivers/virt/coco/tsm.c | 13 +++++++++---- include/linux/cc_platform.h | 8 ++++++++ 3 files changed, 21 insertions(+), 4 deletions(-)arch/x86/coco/core.c +4
-0@@ -12,6 +12,7 @@#include <asm/coco.h> #include <asm/processor.h> +#include <asm/sev.h> enum cc_vendor cc_vendor__ro_after_init =CC_VENDOR_NONE ;u64 cc_mask__ro_after_init ;@@ -78,6 +79,9 @@ static bool noinstr amd_cc_platform_has(enum cc_attr attr)case CC_ATTR_GUEST_STATE_ENCRYPT :return sev_status &MSR_AMD64_SEV_ES_ENABLED ; +case CC_ATTR_GUEST_SVSM_PRESENT : +return snp_get_vmpl (); +/* * With SEV, the rep string I/O instructions need to be unrolled * but SEV-ES supports them through the #VC handler. drivers/virt/coco/tsm.c +0
-0@@ -64,6 +64,11 @@ static struct tsm_report_state *to_state(struct tsm_report *report) return container_of(report, struct tsm_report_state, report); }
Quoted 11 lines
drivers/virt/coco/tsm.c static struct tsm_report_state *to_state(struct tsm_report *report) · line 71
Quoted 5 lines
drivers/virt/coco/tsm.c +5
-0+static umode_t svsm_visibility (const struct config_item *item,const struct configfs_attribute *attr) +{ +return cc_platform_has (CC_ATTR_GUEST_SVSM_PRESENT ) ? attr->ca_mode :0 ; +} +Instead of directly checking for CC flags here, I am wondering if it would make sense to add a callback to vendor drivers and let the callback decide whether the attribute is valid or not? We can't add a CC flag for every ConfigFS attribute, right? For example, privlevel is not used by TDX. If there is a callback, then TDX driver can make this attribute invalid for it.
I think that's something that can be looked at after this series.
Thanks,
Tom
Quoted 60 lines
Quoted 59 lines
drivers/virt/coco/tsm.c +4
-4static int try_advance_write_generation (struct tsm_report *report) {struct tsm_report_state *state =to_state (report);@@ -139,7 +144,7 @@ static ssize_t tsm_report_svsm_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_WO (tsm_report_, svsm); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, svsm, svsm_visibility);static ssize_t tsm_report_service_guid_store (struct config_item *cfg,const char *buf,size_t len)@@ -168,7 +173,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_WO (tsm_report_, service_guid); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_guid, svsm_visibility);static ssize_t tsm_report_service_manifest_version_store (struct config_item *cfg,const char *buf,size_t len)@@ -189,7 +194,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfgreturn len; } -CONFIGFS_ATTR_WO (tsm_report_, service_manifest_version); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_manifest_version, svsm_visibility);static ssize_t tsm_report_inblob_write (struct config_item *cfg,const void *buf,size_t count)@@ -336,7 +341,7 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,return tsm_report_read (report, buf, count,TSM_MANIFEST ); } -CONFIGFS_BIN_ATTR_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX ); +CONFIGFS_BIN_ATTR_VISIBLE_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX , svsm_visibility);#define TSM_DEFAULT_ATTRS () \ &tsm_report_attr_generation, \include/linux/cc_platform.h +8
-0@@ -90,6 +90,14 @@ enum cc_attr {* Examples include TDX Guest. */ CC_ATTR_HOTPLUG_DISABLED , + +/** +* @CC_ATTR_GUEST_SVSM_PRESENT: Guest is running under an SVSM +* +* The platform/OS is running as a guest/virtual machine and is +* running under a Secure VM Service Module (SVSM). +*/ + CC_ATTR_GUEST_SVSM_PRESENT, };#ifdef CONFIG_ARCH_HAS_CC_PLATFORM
Re: [PATCH v2 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
Hi,
Quoted 54 lines · Tom Lendacky
Quoted 44 lines · Sathyanarayanan
Quoted 42 lines · Tom Lendacky
Config-fs provides support to hide individual attribute entries. Using this support, base the display of the SVSM related entries on the presence of an SVSM.
Cc Joel Becker <[email protected]>Cc Christoph Hellwig <[email protected]>Signed-off-by Tom Lendacky <[email protected]>---
arch/x86/coco/core.c | 4 ++++
drivers/virt/coco/tsm.c | 13 +++++++++----
include/linux/cc_platform.h| 8 ++++++++3 files changed, 21 insertions(+), 4 deletions(-)arch/x86/coco/core.c +1
-0@@ -12,6 +12,7 @@ #include <asm/coco.h> #include <asm/processor.h> +#include <asm/sev.h> enum cc_vendor cc_vendor __ro_after_init = CC_VENDOR_NONE; u64 cc_mask __ro_after_init;@@ -78,6 +79,9 @@ static bool noinstr amd_cc_platform_has(enum cc_attr attr)case
CC_ATTR_GUEST_STATE_ENCRYPT:
returnsev_status&MSR_AMD64_SEV_ES_ENABLED;
+ caseCC_ATTR_GUEST_SVSM_PRESENT:
+ returnsnp_get_vmpl();
+
/*
* With SEV, the rep string I/O instructions need to be unrolled
* but SEV-ES supports them through the #VC handler.drivers/virt/coco/tsm.c +2
-0@@ -64,6 +64,11 @@ static struct tsm_report_state *to_state(struct tsm_report *report) return container_of(report, struct tsm_report_state, report); } +static umode_t svsm_visibility(const struct config_item *item, const struct configfs_attribute *attr) +{ + return cc_platform_has(CC_ATTR_GUEST_SVSM_PRESENT) ? attr->ca_mode : 0;Quoted 8 lines
drivers/virt/coco/tsm.c static struct tsm_report_state *to_state(struct tsm_report *report) · line 71
Quoted 2 lines
drivers/virt/coco/tsm.c +2
-0+} +Instead of directly checking for CC flags here, I am wondering if it would make sense to add a callback to vendor drivers and let the callback decide whether the attribute is valid or not? We can't add a CC flag for every ConfigFS attribute, right? For example, privlevel is not used by TDX. If there is a callback, then TDX driver can make this attribute invalid for it.
Quoted 2 lines
I think that's something that can be looked at after this series.
Ok. Lets see what Dan also thinks about it.
IMO, CC flag is generally added when there is common code that can be shared across multiple vendors. And this particular use case is specific to SEV for now. if we move this check to the vendor driver, you can use vendor specific call to check for SVSM and don't require a new CC flag.
Quoted 54 lines
Thanks,
TomQuoted 51 lines
Quoted 50 lines
drivers/virt/coco/tsm.c +4
-4static int try_advance_write_generation(struct tsm_report *report) { struct tsm_report_state *state = to_state(report);@@ -139,7 +144,7 @@ static ssize_t tsm_report_svsm_store(struct config_item *cfg, return len; } -CONFIGFS_ATTR_WO (tsm_report_, svsm); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, svsm, svsm_visibility); static ssize_t tsm_report_service_guid_store(struct config_item *cfg, const char *buf, size_t len)@@ -168,7 +173,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg, return len; } -CONFIGFS_ATTR_WO (tsm_report_, service_guid); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_guid, svsm_visibility); static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg, const char *buf, size_t len)@@ -189,7 +194,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg return len; } -CONFIGFS_ATTR_WO (tsm_report_, service_manifest_version); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_manifest_version, svsm_visibility); static ssize_t tsm_report_inblob_write(struct config_item *cfg, const void *buf, size_t count)@@ -336,7 +341,7 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf, return tsm_report_read(report, buf, count, TSM_MANIFEST); } -CONFIGFS_BIN_ATTR_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX ); +CONFIGFS_BIN_ATTR_VISIBLE_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX , svsm_visibility); #define TSM_DEFAULT_ATTRS() \ &tsm_report_attr_generation, \include/linux/cc_platform.h +8
-0@@ -90,6 +90,14 @@ enum cc_attr {* Examples include TDX Guest. */ CC_ATTR_HOTPLUG_DISABLED, + + /** + * @CC_ATTR_GUEST_SVSM_PRESENT: Guest is running under an SVSM + * + * The platform/OS is running as a guest/virtual machine and is + * running under a Secure VM Service Module (SVSM). + */ + CC_ATTR_GUEST_SVSM_PRESENT, }; #ifdef CONFIG_ARCH_HAS_CC_PLATFORM
Signature · 2 lines
Sathyanarayanan Kuppuswamy Linux Kernel Developer
PATCH v2 14/14 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
@@ -619,10 +619,17 @@ void sev_enable(struct boot_params *bp)* features. */ if (sev_status &MSR_AMD64_SEV_SNP_ENABLED ) { -if (!(get_hv_features () &GHCB_HV_FT_SNP )) +u64 hv_features =get_hv_features (); + +if (!(hv_features &GHCB_HV_FT_SNP ))sev_es_terminate (SEV_TERM_SET_GEN ,GHCB_SNP_UNSUPPORTED ); -if (!running_at_vmpl0 (&boot_ghcb_page)) +/* +* VMPL0 is not required if an SVSM is present and the hypervisor +* supports the required SVSM GHCB events. +*/ +if (!running_at_vmpl0 (&boot_ghcb_page) && + !(vmpl && (hv_features &GHCB_HV_FT_SNP_MULTI_VMPL )))sev_es_terminate (SEV_TERM_SET_LINUX ,GHCB_TERM_NOT_VMPL0 ); }
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
@@ -2368,22 +2368,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.43.2