Provide SEV-SNP support for running under an SVSM
Subsystems (6)
v3 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
4e2b6e891aae ("Merge branch into tip/master: 'x86/shstk'")
[1] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
[2] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
---
Changes in v3:
- Rename decompresor snp_setup() to early_snp_setup() to better indicate when it is called.
- Rename the "svsm" config-fs attribute into the more generic "service_provider" attribute that takes a name as input.
- Change config-fs visibility function to be a simple bool return type instead of returning the mode.
- Switch to using new RIP_REL_REF() macro and __head notation where appropriate.
Changes in v2:
- Define X86_FEATURE_SVSM_PRESENT and set the bit in the CPUID table, removing the need to set the CPUID bit in the #VC handler.
- Rename the TSM service_version attribute to service_manifest_version.
- Add support to config-fs to hide attributes and hide the SVSM attributes when an SVSM is not present.
Tom Lendacky (14):
x86/sev: Rename snp_init() in the boot/compressed/sev.c file x86/sev: Make the VMPL0 checking function more generic x86/sev: Check for the presence of an SVSM in the SNP Secrets page x86/sev: Use kernel provided SVSM Calling Areas
x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0 x86/sev: Use the SVSM to create a vCPU when not in VMPL0 x86/sev: Provide SVSM discovery support
x86/sev: Provide guest VMPL level to userspace
virt: sev-guest: Choose the VMPCK key based on executing VMPL
configfs-tsm: Allow the privlevel_floor attribute to be updated x86/sev: Extend the config-fs attestation support for an SVSM fs/configfs: Add a callback to determine attribute visibility x86/sev: Hide SVSM attestation entries if not running under an SVSM x86/sev: Allow non-VMPL0 execution when an SVSM is present
Documentation/ABI/testing/configfs-tsm | 69 ++++ arch/x86/boot/compressed/sev.c | 256 ++++++++------ arch/x86/coco/core.c | 4 + arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/msr-index.h | 2 + arch/x86/include/asm/sev-common.h | 18 + arch/x86/include/asm/sev.h | 114 ++++++- arch/x86/include/uapi/asm/svm.h | 1 + arch/x86/kernel/sev-shared.c | 345 ++++++++++++++++++- arch/x86/kernel/sev.c | 424 +++++++++++++++++++++--- arch/x86/mm/mem_encrypt_amd.c | 8 +- drivers/virt/coco/sev-guest/sev-guest.c | 166 +++++++++- drivers/virt/coco/tsm.c | 99 +++++- fs/configfs/file.c | 7 + include/linux/cc_platform.h | 8 + include/linux/configfs.h | 111 +++++-- include/linux/tsm.h | 13 +- 17 files changed, 1442 insertions(+), 204 deletions(-)
Signature · 1 line
2.43.2
PATCH v3 1/14 x86/sev: Rename snp_init() in the boot/compressed/sev.c file
The snp_init() in boot/compressed/sev.c is local to that file and is not called from outside of the file. Change the name so that it is not tied to the function definition in arch/x86/include/asm/sev.h. Move the renamed snp_init() and related functions up in the file to avoid having to add a forward declaration and make the function static, too.
This will allow the snp_init() function in arch/x86/kernel/sev.c to be changed without having to make the same change in boot/compressed/sev.c.
--- 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 early_snp_init (struct boot_params *bp) +{ +struct cc_blob_sev_info *cc_info; + +if (!bp) +return false; + + cc_info =find_cc_blob (bp); +if (!cc_info) +return false; + +/* +* If a SNP-specific Confidential Computing blob is present, then +* firmware/bootloader have indicated SNP support. Verifying this +* involves CPUID checks which will be more reliable if the SNP +* CPUID table is used. See comments over snp_setup_cpuid_table() for +* more details. +*/ +setup_cpuid_table (cc_info); + +/* +* Pass run-time kernel a pointer to CC info via boot_params so EFI +* config table doesn't need to be searched again during early startup +* phase. +*/ + bp->cc_blob_address = (u32 )(unsigned long )cc_info; + +return true; +} +/* * sev_check_cpu_support - Check for SEV support in the CPU capabilities *
@@ -463,7 +542,7 @@ void sev_enable(struct boot_params *bp) bp->cc_blob_address =0 ;/* -* Do an initial SEV capability check before snp_init() which +* Do an initial SEV capability check before early_snp_init() which * loads the CPUID page and the same checks afterwards are done * without the hypervisor and are trustworthy. *
@@ -478,7 +557,7 @@ void sev_enable(struct boot_params *bp)* Setup/preliminary detection of SNP. This will be sanity-checked * against CPUID/MSR values later. */ - snp =snp_init (bp); + snp =early_snp_init (bp);/* Now repeat the checks with the SNP CPUID table. */
@@ -535,85 +614,6 @@ u64 sev_get_status(void)return m.q; } -/* Search for Confidential Computing blob in the EFI config table. */ -static struct cc_blob_sev_info *find_cc_blob_efi (struct boot_params *bp) -{ -unsigned long cfg_table_pa; -unsigned int cfg_table_len; -int ret; - - ret =efi_get_conf_table (bp, &cfg_table_pa, &cfg_table_len); -if (ret) -return NULL ; - -return (struct cc_blob_sev_info *)efi_find_vendor_table (bp, cfg_table_pa, - cfg_table_len, -EFI_CC_BLOB_GUID ); -} - -/* -* Initial set up of SNP relies on information provided by the -* Confidential Computing blob, which can be passed to the boot kernel -* by firmware/bootloader in the following ways: -* -* - via an entry in the EFI config table -* - via a setup_data structure, as defined by the Linux Boot Protocol -* -* Scan for the blob in that order. -*/ -static struct cc_blob_sev_info *find_cc_blob (struct boot_params *bp) -{ -struct cc_blob_sev_info *cc_info; - - cc_info =find_cc_blob_efi (bp); -if (cc_info) - goto found_cc_info; - - cc_info =find_cc_blob_setup_data (bp); -if (!cc_info) -return NULL ; - -found_cc_info: -if (cc_info->magic !=CC_BLOB_SEV_HDR_MAGIC ) -sev_es_terminate (SEV_TERM_SET_GEN ,GHCB_SNP_UNSUPPORTED ); - -return cc_info; -} - -/* -* Indicate SNP based on presence of SNP-specific CC blob. Subsequent checks -* will verify the SNP CPUID/MSR bits. -*/ -bool snp_init (struct boot_params *bp) -{ -struct cc_blob_sev_info *cc_info; - -if (!bp) -return false; - - cc_info =find_cc_blob (bp); -if (!cc_info) -return false; - -/* -* If a SNP-specific Confidential Computing blob is present, then -* firmware/bootloader have indicated SNP support. Verifying this -* involves CPUID checks which will be more reliable if the SNP -* CPUID table is used. See comments over snp_setup_cpuid_table() for -* more details. -*/ -setup_cpuid_table (cc_info); - -/* -* Pass run-time kernel a pointer to CC info via boot_params so EFI -* config table doesn't need to be searched again during early startup -* phase. -*/ - bp->cc_blob_address = (u32 )(unsigned long )cc_info; - -return true; -} -void sev_prep_identity_maps (unsigned long top_level_pgt) {/*
Signature · 1 line
2.43.2
Borislav Petkov
maintainerRe: [PATCH v3 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file
Quoted 3 lines · Tom Lendacky
The
snp_init()inboot/compressed/sev.cis local to that file and is not called from outside of the file. Change the name so that it is not tied to the function definition inarch/x86/include/asm/sev.h.
That part I don't understand: I can rename the function without making it static and it builds fine, so where is it "tied" to the function definition in kernel proper?
Don't get me wrong - leaking kernel proper symbols into the decompressor has been a pet peeve of mine for a while now but this is not the case here, is it?
And yes, the patch is fine - I'm just asking...
Thx.
Signature · 4 lines
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquetteRe: [PATCH v3 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file
Quoted 8 lines · Borislav Petkov
Quoted 3 lines · Tom Lendacky
The
snp_init()inboot/compressed/sev.cis local to that file and is not called from outside of the file. Change the name so that it is not tied to the function definition inarch/x86/include/asm/sev.h.That part I don't understand: I can rename the function without making it static and it builds fine, so where is it "tied" to the function definition in kernel proper?
When it's not static and has the name snp_init(), then it has to match the definition in arch/x86/include/asm/sev.h, which is really intended for the snp_init() in arch/x86/kernel/sev.c when called from arch/x86/mm/mem_encrypt_identity.c.
So, yes, changing the name would be enough except then it remains not a static and you can get a compiler warning about not having a prototype for it if the -Wmissing-prototypes option is ever applied to that file (I don't believe it is today because it is in the decompressor code, but that can change). And since nothing calls the snp_init() in arch/x86/boot/compressed/sev.c from outside of that file, making it static was appropriate.
Thanks,
Tom
Quoted 9 lines
Don't get me wrong - leaking kernel proper symbols into the decompressor has been a pet peeve of mine for a while now but this is not the case here, is it?
And yes, the patch is fine - I'm just asking...
Thx.
Borislav Petkov
maintainerRe: [PATCH v3 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file
Quoted 5 lines · Tom Lendacky
When it's not static and has the name
snp_init(), then it has to match the definition inarch/x86/include/asm/sev.h, which is really intended for thesnp_init()inarch/x86/kernel/sev.cwhen called fromarch/x86/mm/mem_encrypt_identity.c.
Quoted 7 lines
So, yes, changing the name would be enough except then it remains not a static and you can get a compiler warning about not having a prototype for it if the -Wmissing-prototypes option is ever applied to that file (I don't believe it is today because it is in the decompressor code, but that can change). And since nothing calls the
snp_init()inarch/x86/boot/compressed/sev.cfrom outside of that file, making it static was appropriate.
Yes, then please remove all that text about what could potentially happen from the commit message so that it is not confusing as to what the situation *currently* is.
The two functions are independent right now. It is enough to say that you want to differentiate which one is called when, in order to avoid confusion.
Thx.
Signature · 4 lines
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquetteRe: [PATCH v3 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file
In reply to Tom LendackyQuoted 10 lines · Tom Lendacky
The
snp_init()inboot/compressed/sev.cis local to that file and is not called from outside of the file. Change the name so that it is not tied to the function definition inarch/x86/include/asm/sev.h. Move the renamedsnp_init()and related functions up in the file to avoid having to add a forward declaration and make the function static, too.This will allow the
snp_init()function inarch/x86/kernel/sev.cto be changed without having to make the same change inboot/compressed/sev.c.Signed-off-by Tom Lendacky <[email protected]>
Seems no functional change. Just rename snp_init() & move functions up in the file.
Quoted 198 lines
--- 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 early_snp_init (struct boot_params *bp) +{ +struct cc_blob_sev_info *cc_info; + +if (!bp) +return false; + + cc_info =find_cc_blob (bp); +if (!cc_info) +return false; + +/* +* If a SNP-specific Confidential Computing blob is present, then +* firmware/bootloader have indicated SNP support. Verifying this +* involves CPUID checks which will be more reliable if the SNP +* CPUID table is used. See comments over snp_setup_cpuid_table() for +* more details. +*/ +setup_cpuid_table (cc_info); + +/* +* Pass run-time kernel a pointer to CC info via boot_params so EFI +* config table doesn't need to be searched again during early startup +* phase. +*/ + bp->cc_blob_address = (u32 )(unsigned long )cc_info; + +return true; +} +/* * sev_check_cpu_support - Check for SEV support in the CPU capabilities * @@ -463,7 +542,7 @@ void sev_enable(struct boot_params *bp) bp->cc_blob_address =0 ;/* -* Do an initial SEV capability check before snp_init() which +* Do an initial SEV capability check before early_snp_init() which * loads the CPUID page and the same checks afterwards are done * without the hypervisor and are trustworthy. * @@ -478,7 +557,7 @@ void sev_enable(struct boot_params *bp)* Setup/preliminary detection of SNP. This will be sanity-checked * against CPUID/MSR values later. */ - snp =snp_init (bp); + snp =early_snp_init (bp);/* Now repeat the checks with the SNP CPUID table. */ @@ -535,85 +614,6 @@ u64 sev_get_status(void)return m.q; } -/* Search for Confidential Computing blob in the EFI config table. */ -static struct cc_blob_sev_info *find_cc_blob_efi (struct boot_params *bp) -{ -unsigned long cfg_table_pa; -unsigned int cfg_table_len; -int ret; - - ret =efi_get_conf_table (bp, &cfg_table_pa, &cfg_table_len); -if (ret) -return NULL ; - -return (struct cc_blob_sev_info *)efi_find_vendor_table (bp, cfg_table_pa, - cfg_table_len, -EFI_CC_BLOB_GUID ); -} - -/* -* Initial set up of SNP relies on information provided by the -* Confidential Computing blob, which can be passed to the boot kernel -* by firmware/bootloader in the following ways: -* -* - via an entry in the EFI config table -* - via a setup_data structure, as defined by the Linux Boot Protocol -* -* Scan for the blob in that order. -*/ -static struct cc_blob_sev_info *find_cc_blob (struct boot_params *bp) -{ -struct cc_blob_sev_info *cc_info; - - cc_info =find_cc_blob_efi (bp); -if (cc_info) - goto found_cc_info; - - cc_info =find_cc_blob_setup_data (bp); -if (!cc_info) -return NULL ; - -found_cc_info: -if (cc_info->magic !=CC_BLOB_SEV_HDR_MAGIC ) -sev_es_terminate (SEV_TERM_SET_GEN ,GHCB_SNP_UNSUPPORTED ); - -return cc_info; -} - -/* -* Indicate SNP based on presence of SNP-specific CC blob. Subsequent checks -* will verify the SNP CPUID/MSR bits. -*/ -bool snp_init (struct boot_params *bp) -{ -struct cc_blob_sev_info *cc_info; - -if (!bp) -return false; - - cc_info =find_cc_blob (bp); -if (!cc_info) -return false; - -/* -* If a SNP-specific Confidential Computing blob is present, then -* firmware/bootloader have indicated SNP support. Verifying this -* involves CPUID checks which will be more reliable if the SNP -* CPUID table is used. See comments over snp_setup_cpuid_table() for -* more details. -*/ -setup_cpuid_table (cc_info); - -/* -* Pass run-time kernel a pointer to CC info via boot_params so EFI -* config table doesn't need to be searched again during early startup -* phase. -*/ - bp->cc_blob_address = (u32 )(unsigned long )cc_info; - -return true; -} -void sev_prep_identity_maps (unsigned long top_level_pgt) {/*
PATCH v3 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
Re: [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic
Quoted 9 lines · Tom Lendacky
Currently, the
enforce_vmpl0()function uses a set argument when testing for VMPL0 and terminates the guest if the guest is not running at VMPL0.Make the function more generic by moving it into the common code, renaming it, allowing it to take an argument for use in the VMPL0 check (RMPADJUST instruction) and return the result of the check, allowing the caller to determine the action taken based on the result.
Signed-off-by Tom Lendacky <[email protected]>
This is preparatory patch for patch3.
Quoted 46 lines
--- 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 ))
Borislav Petkov
maintainerRe: [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic
In reply to Tom Lendackyarch/x86/boot/compressed/sev.c void do_boot_stage2_vc(struct pt_regs *regs, unsigned long exit_code) · line 338
Quoted 2 lines · Tom Lendacky
arch/x86/boot/compressed/sev.c +1
-1-static void enforce_vmpl0 (void ) +static bool running_at_vmpl0 (void *va)
Not too crazy about it: you're turning it into a function which runs in boolean context but takes a void *?!
And the boolean result is only a side-effect or what it does to the argument - modify its permissions. Which is weird and not really obvious.
I'd prefer it if you made it into
static void vmpl0_modify_permissions(void *va)
which basically says, modify the permissions of @va in vmpl0, which is a lot closer to what the function does.
And then do
#define running_at_vmpl0(va) vmpl0_modify_permissions((va))
because then through the indirection is at least clear how that "am I running at VMPL0?" check is being done.
And later, if we need other VMPLs, we can extend vmpl0_modify_permissions() and even do a more generic
vmpl_modify_permissions(unsigned int vmpl_level, void *va)
and so on and kill the silly macro.
Thx.
Signature · 4 lines
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquetteRe: [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic
Quoted 10 lines · Borislav Petkov
arch/x86/boot/compressed/sev.c void do_boot_stage2_vc(struct pt_regs *regs, unsigned long exit_code) · line 338
Quoted 2 lines · Tom Lendacky
arch/x86/boot/compressed/sev.c +1
-1-static void enforce_vmpl0 (void ) +static bool running_at_vmpl0 (void *va)Not too crazy about it: you're turning it into a function which runs in boolean context but takes a void *?!
And the boolean result is only a side-effect or what it does to the argument - modify its permissions. Which is weird and not really obvious.
Well, it doesn't really modify any permissions that matter. It tries to change the permission of a lesser privileged VMPL level. Since the kernel only runs at a single VMPL it would never be effected. The operation performed here is to update VMPL1 permission levels (which can only be done successfully at VMPL0) and return the result of the operation. A success implies running at VMPL0 and failure implies not running at VMPL0.
Quoted 4 lines
I'd prefer it if you made it into
static void
vmpl0_modify_permissions(void *va)
I guess this confuses me, since it sounds like you're trying to modify the VMPL0 permissions, which you can't do. Maybe calling it modify_vmpl1_permissions() would be better. And a void return doesn't tell me whether it was successful and, therefore, whether the kernel is running at VMPL0.
Thanks,
Tom
Quoted 20 lines
which basically says, modify the permissions of @va in vmpl0, which is a lot closer to what the function does.
And then do
#define
running_at_vmpl0(va)vmpl0_modify_permissions((va))because then through the indirection is at least clear how that "am I running at VMPL0?" check is being done.
And later, if we need other VMPLs, we can extend
vmpl0_modify_permissions()and even do a more generic
vmpl_modify_permissions(unsigned int vmpl_level, void *va)and so on and kill the silly macro.
Thx.
Borislav Petkov
maintainerRe: [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic
Quoted 2 lines · Tom Lendacky
Well, it doesn't really modify any permissions that matter. It tries to change the permission of a lesser privileged VMPL level.
Potato potato. :-P
Quoted 5 lines
Since the kernel only runs at a single VMPL it would never be effected. The operation performed here is to update VMPL1 permission levels (which can only be done successfully at VMPL0) and return the result of the operation. A success implies running at VMPL0 and failure implies not running at VMPL0.
Yap.
The point is, it is calling RMPADJUST. And it does modify RMP permissions of a guest page.
Thus, if you prefer, you can go all out and call the helper
rmp_adjust_permissions(unsigned int tgt_vmpl, void *pa)
and make it generic from the get-go.
And then have the macro wrap around it in order to explain that particular use with the macro name.
If it is still not clear what I mean, lemme know and I'll do a diff ontop.
Thx.
Signature · 4 lines
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquetteRe: [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic
Quoted 4 lines · Borislav Petkov
On Wed, Apr 17, 2024 at 03:35:53PM -0500, Tom Lendacky wrote:
Yap.
Quoted 8 lines
The point is, it is calling RMPADJUST. And it does modify RMP permissions of a guest page.
Thus, if you prefer, you can go all out and call the helper
rmp_adjust_permissions(unsigned int tgt_vmpl, void *pa)and make it generic from the get-go.
I think I'll just eliminate the function then and call rmpadjust directly, that should make it clear.
Thanks,
Tom
Quoted 9 lines
And then have the macro wrap around it in order to explain that particular use with the macro name.
If it is still not clear what I mean, lemme know and I'll do a diff ontop.
Thx.
Borislav Petkov
maintainerRe: [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic
Quoted 2 lines · Tom Lendacky
I think I'll just eliminate the function then and call rmpadjust directly, that should make it clear.
Your call.
However, if we're anticipating more uses around RMPADJUST like that we might as well design the interface properly from the very beginning.
Signature · 4 lines
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquettePATCH v3 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 early_snp_init(struct boot_params *bp)*/ setup_cpuid_table (cc_info); +/* +* Record the SVSM Calling Area address (CAA) if the guest is not +* running at VMPL0. The CA will be used to communicate with the +* SVSM to perform the SVSM services. +*/ +setup_svsm_ca (cc_info); +/* * Pass run-time kernel a pointer to CC info via boot_params so EFI * config table doesn't need to be searched again during early startup
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 v3 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page
Quoted 10 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]>
Looks good.
Quoted 241 lines
--- 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 early_snp_init(struct boot_params *bp)*/ setup_cpuid_table (cc_info); +/* +* Record the SVSM Calling Area address (CAA) if the guest is not +* running at VMPL0. The CA will be used to communicate with the +* SVSM to perform the SVSM services. +*/ +setup_svsm_ca (cc_info); +/* * Pass run-time kernel a pointer to CC info via boot_params so EFI * config table doesn't need to be searched again during early startup 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@@ -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. */ @@ -1267,3 +1285,49 @@ static enum es_result vc_check_opcode_bytes(struct es_em_ctxt *ctxt,return ES_UNSUPPORTED ; } + +/* +* Maintain the GPA of the SVSM Calling Area (CA) in order to utilize the SVSM +* services needed when not running in VMPL0. +*/ +static void __head setup_svsm_ca(const struct cc_blob_sev_info *cc_info) +{ +struct snp_secrets_page_layout *secrets_page; +u64 caa; + +BUILD_BUG_ON (sizeof (*secrets_page) !=PAGE_SIZE ); + +/* +* Use __pa() since this routine is running identity mapped when +* called, both by the decompressor code and the early kernel code. +*/ +if (running_at_vmpl0 ((void *)__pa (&boot_ghcb_page))) +return ; + +/* +* Not running at VMPL0, ensure everything has been properly supplied +* for running under an SVSM. +*/ +if (!cc_info || !cc_info->secrets_phys || cc_info->secrets_len !=PAGE_SIZE ) +sev_es_terminate (SEV_TERM_SET_LINUX ,GHCB_TERM_SECRETS_PAGE ); + + secrets_page = (struct snp_secrets_page_layout *)cc_info->secrets_phys; +if (!secrets_page->svsm_size) +sev_es_terminate (SEV_TERM_SET_LINUX ,GHCB_TERM_NO_SVSM ); + +if (!secrets_page->svsm_guest_vmpl) +sev_es_terminate (SEV_TERM_SET_LINUX ,GHCB_TERM_SVSM_VMPL0 ); + + vmpl = secrets_page->svsm_guest_vmpl; + + caa = secrets_page->svsm_caa; +if (!PAGE_ALIGNED (caa)) +sev_es_terminate (SEV_TERM_SET_LINUX ,GHCB_TERM_SVSM_CAA ); + +/* +* The CA is identity mapped when this routine is called, both by the +* decompressor code and the early kernel code. +*/ + boot_svsm_caa = (struct svsm_ca *)caa; + boot_svsm_caa_pa = caa; +}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.
Borislav Petkov
maintainerRe: [PATCH v3 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page
In reply to Tom LendackyQuoted 8 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.
Where are we pointing to the SVSM spec?
This is in the 0th message
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
but pls add it to our documentation here:
Documentation/arch/x86/amd-memory-encryption.rst
Quoted 23 lines
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 +1
-0@@ -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) ;
arch/x86/boot/compressed/sev.c line 40
Quoted 10 lines
arch/x86/boot/compressed/sev.c +8
-0struct ghcb *boot_ghcb; +/* +* SVSM related information: +* When running under an SVSM, the VMPL that Linux is executing at must be +* non-zero. The VMPL is therefore used to indicate the presence of an SVSM. +*/ +static u8 vmpl __section(".data"); +static u64 boot_svsm_caa_pa __section(".data"); +static struct svsm_ca *boot_svsm_caa __section(".data");
Explain what those last 2 are in comments above it pls.
arch/x86/boot/compressed/sev.c static bool early_snp_init(struct boot_params *bp) · line 476
Quoted 9 lines
arch/x86/boot/compressed/sev.c +2
-0/* * SNP_FEATURES_IMPL_REQ is the mask of SNP features that will need * guest side implementation for proper functioning of the guest. If any @@ -480,6 +472,13 @@ static bool early_snp_init(struct boot_params *bp)*/ setup_cpuid_table (cc_info); +/* +* Record the SVSM Calling Area address (CAA) if the guest is not
Calling Area (CA) address
arch/x86/boot/compressed/sev.c static bool early_snp_init(struct boot_params *bp) · line 477
Quoted 1 line
arch/x86/boot/compressed/sev.c +1
-0+* running at VMPL0. The CA will be used to communicate with the
and then you can use "CA" here.
Quoted 12 lines
arch/x86/boot/compressed/sev.c +4
-0+* 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 +0
-0
arch/x86/include/asm/sev-common.h struct snp_psc_desc { · line 165
Quoted 7 lines
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 */
"CAA" in the comment I guess. :)
arch/x86/include/asm/sev-common.h struct snp_psc_desc {
Quoted 7 lines
arch/x86/include/asm/sev-common.h +7
-0+/* +* Maintain the GPA of the SVSM Calling Area (CA) in order to utilize the SVSM +* services needed when not running in VMPL0. +*/ +static void __head setup_svsm_ca(const struct cc_blob_sev_info *cc_info) +{ +struct snp_secrets_page_layout *secrets_page;
Why was that thing ever called "_layout" and not simply snp_secrets_page?
Fix it?
arch/x86/include/asm/sev-common.h
Quoted 3 lines
arch/x86/include/asm/sev-common.h +3
-0+u64 caa; + +BUILD_BUG_ON (sizeof (*secrets_page) !=PAGE_SIZE );
Put it in the header under the struct definition I guess.
Quoted 40 lines
arch/x86/include/asm/sev-common.h +34
-0+/* +* 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 +0
-0@@ -135,6 +135,15 @@ struct ghcb_state { static DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data);
arch/x86/kernel/sev.c struct ghcb_state { · line 145
Quoted 10 lines
arch/x86/kernel/sev.c +8
-0static DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa); +/* +* SVSM related information: +* When running under an SVSM, the VMPL that Linux is executing at must be +* non-zero. The VMPL is therefore used to indicate the presence of an SVSM. +*/ +static u8 vmpl__ro_after_init ; +static struct svsm_ca *boot_svsm_caa__ro_after_init ; +static u64 boot_svsm_caa_pa__ro_after_init ;
Uff, duplication.
Let's put them in sev-shared.c pls and avoid that.
Thx.
Signature · 4 lines
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquetteRe: [PATCH v3 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page
Quoted 12 lines · Borislav Petkov
Quoted 8 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.Where are we pointing to the SVSM spec?
Quoted 7 lines
This is in the 0th message
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
but pls add it to our documentation here:
Documentation/arch/x86/amd-memory-encryption.rst
Do you want it added as a in this patch or in a documentation patch at the end of the series?
Quoted 26 lines
Quoted 26 lines
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 +1
-0@@ -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;
Quoted 10 lines
arch/x86/boot/compressed/sev.c line 40
Quoted 8 lines
arch/x86/boot/compressed/sev.c +8
-0+/* +* SVSM related information: +* When running under an SVSM, the VMPL that Linux is executing at must be +* non-zero. The VMPL is therefore used to indicate the presence of an SVSM. +*/ +static u8 vmpl __section(".data"); +static u64 boot_svsm_caa_pa __section(".data"); +static struct svsm_ca *boot_svsm_caa __section(".data");Explain what those last 2 are in comments above it pls.
Will do.
Quoted 8 lines
Quoted 8 lines
arch/x86/boot/compressed/sev.c +0
-0/* * SNP_FEATURES_IMPL_REQ is the mask of SNP features that will need * guest side implementation for proper functioning of the guest. If any @@ -480,6 +472,13 @@ static bool early_snp_init(struct boot_params *bp)*/ setup_cpuid_table (cc_info);
Quoted 8 lines
arch/x86/boot/compressed/sev.c static bool early_snp_init(struct boot_params *bp) · line 476
Quoted 2 lines
arch/x86/boot/compressed/sev.c +2
-0+/* +* Record the SVSM Calling Area address (CAA) if the guest is not Calling Area (CA) address
arch/x86/boot/compressed/sev.c static bool early_snp_init(struct boot_params *bp) · line 477
Quoted 1 line
arch/x86/boot/compressed/sev.c +1
-0+* running at VMPL0. The CA will be used to communicate with the and then you can use "CA" here.
Will do.
Quoted 14 lines
Quoted 14 lines
arch/x86/boot/compressed/sev.c +4
-0+* 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 +0
-0@@ -159,6 +159,10 @@ struct snp_psc_desc {#define GHCB_TERM_NOT_VMPL0 3/* SNP guest is not running at VMPL-0 */
Quoted 8 lines
arch/x86/include/asm/sev-common.h struct snp_psc_desc { · line 165
Quoted 6 lines
arch/x86/include/asm/sev-common.h +4
-0#define GHCB_TERM_CPUID 4/* CPUID-validation failure */ #define GHCB_TERM_CPUID_HV 5/* CPUID failure during hypervisor fallback */ +#define GHCB_TERM_SECRETS_PAGE 6/* Secrets page failure */ +#define GHCB_TERM_NO_SVSM 7/* SVSM is not advertised in the secrets page */ +#define GHCB_TERM_SVSM_VMPL0 8/* SVSM is present but has set VMPL to 0 */ +#define GHCB_TERM_SVSM_CAA 9/* SVSM is present but the CA is not page aligned */ "CAA" in the comment I guess. :)
Will do.
Quoted 12 lines
arch/x86/include/asm/sev-common.h struct snp_psc_desc {
Quoted 8 lines
arch/x86/include/asm/sev-common.h +7
-0+/* +* Maintain the GPA of the SVSM Calling Area (CA) in order to utilize the SVSM +* services needed when not running in VMPL0. +*/ +static void __head setup_svsm_ca(const struct cc_blob_sev_info *cc_info) +{ +struct snp_secrets_page_layout *secrets_page;Why was that thing ever called "
_layout" and not simplysnp_secrets_page?
Quoted 1 line
Fix it?
Sure, I can change that as a pre-patch to the series.
Quoted 6 lines
arch/x86/include/asm/sev-common.h
Quoted 4 lines
arch/x86/include/asm/sev-common.h +3
-0+u64 caa; + +BUILD_BUG_ON (sizeof (*secrets_page) !=PAGE_SIZE );Put it in the header under the struct definition I guess.
It can't stand on it's own in the header file. I'd have to put it in a #define or an inline function and then use that in some code. So it's probably best to keep it here.
Quoted 54 lines
Quoted 41 lines
arch/x86/include/asm/sev-common.h +34
-0+/* +* 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 +0
-0@@ -135,6 +135,15 @@ struct ghcb_state { static DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data);arch/x86/kernel/sev.c struct ghcb_state { · line 145
Quoted 10 lines
arch/x86/kernel/sev.c +8
-0static DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa); +/* +* SVSM related information: +* When running under an SVSM, the VMPL that Linux is executing at must be +* non-zero. The VMPL is therefore used to indicate the presence of an SVSM. +*/ +static u8 vmpl__ro_after_init ; +static struct svsm_ca *boot_svsm_caa__ro_after_init ; +static u64 boot_svsm_caa_pa__ro_after_init ;Uff, duplication.
Quoted 1 line
Let's put them in
sev-shared.cpls and avoid that.
Ok, but it will require moving some functions after the inclusion of sev-shared.c and then (later) adding some advance function declarations.
Thanks,
Tom
Quoted 3 lines
Thx.
Borislav Petkov
maintainerRe: [PATCH v3 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page
Quoted 2 lines · Tom Lendacky
Do you want it added as a in this patch or in a documentation patch at the end of the series?
Either way's fine.
Quoted 6 lines
Quoted 4 lines
Why was that thing ever called "
_layout" and not simplysnp_secrets_page?Fix it?
Sure, I can change that as a pre-patch to the series.
Ack.
Quoted 11 lines
Quoted 7 lines
arch/x86/kernel/sev-shared.c static enum es_result vc_check_opcode_bytes(struct es_em_ctxt *ctxt, · line 1298
Quoted 5 lines
arch/x86/kernel/sev-shared.c +3
-0+u64 caa; + +BUILD_BUG_ON (sizeof (*secrets_page) !=PAGE_SIZE );Put it in the header under the struct definition I guess.
It can't stand on it's own in the header file. I'd have to put it in a #define or an inline function and then use that in some code. So it's probably best to keep it here.
You can always put it in an inline function in the header to move this macro out of the way but ok, one macro is not too nasty yet. :-)
Quoted 6 lines
Quoted 3 lines
Uff, duplication.
Let's put them in
sev-shared.cpls and avoid that.Ok, but it will require moving some functions after the inclusion of
sev-shared.cand then (later) adding some advance function declarations.
I guess I'll have to see it.
I get the feeling that this sev-shared.c is starting to get problematic and we have to do some dancing to get it all to work nicely.
In this particular case, those decompressor and kernel proper variables should probably be passed explicitly to the shared function or returned from it so that there's no "magic" fitting of the shared function touching external variables of the same name and thus those names are kept the same and it all becomes fragile.
IOW:
svsm_ca = setup_svsm_ca(...); svsm_ca_pa = (unsigned long)svsm_ca;
or whatever needs to happen. But you get the idea...
Thx.
Signature · 4 lines
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquettePATCH v3 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 | 205 +++++++++++++++++++++++++----- arch/x86/mm/mem_encrypt_amd.c | 8 +- 6 files changed, 318 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 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 +172 -33
273 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
Re: [PATCH v3 04/14] x86/sev: Use kernel provided SVSM Calling Areas
Quoted 9 lines · Tom Lendacky
The SVSM Calling Area (CA) is used to communicate between Linux and the SVSM. Since the firmware supplied CA for the BSP is likely to be in reserved memory, switch off that CA to a kernel provided CA so that access and use of the CA is available during boot. The CA switch is done using the SVSM core protocol
SVSM_CORE_REMAP_CAcall.An SVSM call is executed by filling out the SVSM CA and setting the proper register state as documented by the SVSM protocol. The SVSM is invoked by by requesting the hypervisor to run VMPL0.
s/by/''
Quoted 7 lines
Once it is safe to allocate/reserve memory, allocate a CA for each CPU. After allocating the new CAs, the BSP will switch from the boot CA to the per-CPU CA. The CA for an AP is identified to the SVSM when creating the VMSA in preparation for booting the AP.
Signed-off-by Tom Lendacky <[email protected]>
Quoted 441 lines
--- arch/x86/include/asm/sev-common.h | 13 ++ arch/x86/include/asm/sev.h | 32 +++++ arch/x86/include/uapi/asm/svm.h | 1 + arch/x86/kernel/sev-shared.c | 94 +++++++++++++- arch/x86/kernel/sev.c | 205 +++++++++++++++++++++++++----- arch/x86/mm/mem_encrypt_amd.c | 8 +- 6 files changed, 318 insertions(+), 35 deletions(-)arch/x86/include/asm/sev-common.h +13
-0@@ -96,6 +96,19 @@ enum psc_op {/* GHCBData[63:32] */ \ (((u64)(val) &GENMASK_ULL (63 ,32 )) >>32 ) +/* GHCB Run at VMPL Request/Response */ +#define GHCB_MSR_VMPL_REQ 0x016 +#define GHCB_MSR_VMPL_REQ_LEVEL(v) \ + /* GHCBData[39:32] */ \ + (((u64)(v) & GENMASK_ULL(7, 0) << 32) | \ + /* GHCBDdata[11:0] */ \ +GHCB_MSR_VMPL_REQ ) + +#define GHCB_MSR_VMPL_RESP 0x017 +#define GHCB_MSR_VMPL_RESP_VAL (v) \ +/* GHCBData[63:32] */ \ + (((u64)(v) & GENMASK_ULL(63, 32)) >> 32) +/* GHCB Hypervisor Feature Request/Response */ #define GHCB_MSR_HV_FT_REQ 0x080#define GHCB_MSR_HV_FT_RESP 0x081arch/x86/include/asm/sev.h +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 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@@ -18,9 +18,11 @@#define sev_printk_rtl (fmt, ...) printk_ratelimited(fmt, ##__VA_ARGS__)#else #undef WARN -#define WARN(condition, format...) (!!(condition)) +#define WARN(condition, format...) (!!(condition))#define sev_printk (fmt, ...)#define sev_printk_rtl (fmt, ...) +#undef vc_forward_exception +#define vc_forward_exception (c) panic("SNP: Hypervisor requested exception\n")#endif /* I/O parameters for CPUID-related helpers */ @@ -247,6 +249,96 @@ static enum es_result verify_exception_info(struct ghcb *ghcb, struct es_em_ctxtreturn ES_VMM_ERROR ; } +static __always_inline void issue_svsm_call(struct svsm_call *call, u8 *pending) +{ +/* +* Issue the VMGEXIT to run the SVSM: +* - Load the SVSM register state (RAX, RCX, RDX, R8 and R9) +* - Set the CA call pending field to 1 +* - Issue VMGEXIT +* - Save the SVSM return register state (RAX, RCX, RDX, R8 and R9) +* - Perform atomic exchange of the CA call pending field +*/ + asmvolatile ("mov %9, %%r8\n\t" +"mov %10, %%r9\n\t" +"movb $1, %11\n\t" +"rep; vmmcall\n\t" +"mov %%r8, %3\n\t" +"mov %%r9, %4\n\t" +"xchgb %5, %11\n\t" + :"=a" (call->rax_out),"=c" (call->rcx_out),"=d" (call->rdx_out), +"=m" (call->r8_out),"=m" (call->r9_out), +"+r" (*pending) + :"a" (call->rax),"c" (call->rcx),"d" (call->rdx), +"r" (call->r8),"r" (call->r9), +"m" (call->caa->call_pending) + :"r8" ,"r9" ,"memory" ); +} + +static int __svsm_msr_protocol (struct svsm_call *call) +{ +u64 val, resp; +u8 pending; + + val =sev_es_rd_ghcb_msr (); + +sev_es_wr_ghcb_msr (GHCB_MSR_VMPL_REQ_LEVEL (0 )); + + pending =0 ; +issue_svsm_call (call, &pending); + + resp =sev_es_rd_ghcb_msr (); + +sev_es_wr_ghcb_msr (val); + +if (pending) +return -EINVAL ; + +if (GHCB_RESP_CODE (resp) !=GHCB_MSR_VMPL_RESP ) +return -EINVAL ; + +if (GHCB_MSR_VMPL_RESP_VAL (resp) !=0 ) +return -EINVAL ; + +return call->rax_out; +} + +static int __svsm_ghcb_protocol (struct ghcb *ghcb,struct svsm_call *call) +{ +struct es_em_ctxt ctxt; +u8 pending; + +vc_ghcb_invalidate (ghcb); + +/* Fill in protocol and format specifiers */ + ghcb->protocol_version = ghcb_version; + ghcb->ghcb_usage =GHCB_DEFAULT_USAGE ; + +ghcb_set_sw_exit_code (ghcb,SVM_VMGEXIT_SNP_RUN_VMPL ); +ghcb_set_sw_exit_info_1 (ghcb,0 ); +ghcb_set_sw_exit_info_2 (ghcb,0 ); + +sev_es_wr_ghcb_msr (__pa (ghcb)); + + pending =0 ; +issue_svsm_call (call, &pending); + +if (pending) +return -EINVAL ; + +switch (verify_exception_info (ghcb, &ctxt)) { +case ES_OK : +break ; +case ES_EXCEPTION : +vc_forward_exception (&ctxt); + fallthrough; +default : +return -EINVAL ; + } + +return call->rax_out; +} + static enum es_result sev_es_ghcb_hv_call(struct ghcb *ghcb, struct es_em_ctxt *ctxt, u64 exit_code, u64 exit_info_1,arch/x86/kernel/sev.c +129
-27@@ -134,6 +134,8 @@ struct ghcb_state { static DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data); static DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa); +static DEFINE_PER_CPU(struct svsm_ca *, svsm_caa); +static DEFINE_PER_CPU(u64, svsm_caa_pa);/* * SVSM related information: @@ -141,6 +143,7 @@ static DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa);* non-zero. The VMPL is therefore used to indicate the presence of an SVSM. */ static u8 vmpl__ro_after_init ; +static struct svsm_ca boot_svsm_ca_page__aligned(PAGE_SIZE) ;static struct svsm_ca *boot_svsm_caa__ro_after_init ;static u64 boot_svsm_caa_pa__ro_after_init ;@@ -158,11 +161,26 @@ struct sev_config {*/ ghcbs_initialized :1 , +/* +* A flag used to indicate when the per-CPU SVSM CA is to be +* used instead of the boot SVSM CA. +* +* For APs, the per-CPU SVSM CA is created as part of the AP +* bringup, so this flag can be used globally for the BSP and APs. +*/ + cas_initialized : 1, + __reserved : 62; };static struct sev_config sev_cfg__read_mostly ; +static struct svsm_ca *__svsm_get_caa (void ) +{ +return sev_cfg.cas_initialized ?this_cpu_read (svsm_caa) + : boot_svsm_caa; +} + static __always_inline bool on_vc_stack(struct pt_regs *regs) {unsigned long sp = regs->sp;@@ -580,6 +598,33 @@ static enum es_result vc_ioio_check(struct es_em_ctxt *ctxt, u16 port, size_t sireturn ES_EXCEPTION ; } +static __always_inline void vc_forward_exception(struct es_em_ctxt *ctxt) +{ +long error_code = ctxt->fi.error_code; +int trapnr = ctxt->fi.vector; + + ctxt->regs->orig_ax = ctxt->fi.error_code; + +switch (trapnr) { +case X86_TRAP_GP : +exc_general_protection (ctxt->regs, error_code); +break ; +case X86_TRAP_UD : +exc_invalid_op (ctxt->regs); +break ; +case X86_TRAP_PF : +write_cr2 (ctxt->fi.cr2); +exc_page_fault (ctxt->regs, error_code); +break ; +case X86_TRAP_AC : +exc_alignment_check (ctxt->regs, error_code); +break ; +default : +pr_emerg ("Unsupported exception in #VC instruction emulation - can't continue\n" ); +BUG (); + } +} +/* Include code shared with pre-decompression boot stage */ #include "sev-shared.c" @@ -608,6 +653,42 @@ static noinstr void __sev_put_ghcb(struct ghcb_state *state) } } +static int svsm_protocol (struct svsm_call *call) +{ +struct ghcb_state state; +unsigned long flags; +struct ghcb *ghcb; +int ret; + +/* +* This can be called very early in the boot, use native functions in +* order to avoid paravirt issues. +*/ + flags =native_save_fl (); +if (flags &X86_EFLAGS_IF ) +native_irq_disable (); + +if (sev_cfg.ghcbs_initialized) + ghcb =__sev_get_ghcb (&state); +else if (boot_ghcb) + ghcb = boot_ghcb; +else + ghcb =NULL ; + +do { + ret = ghcb ?__svsm_ghcb_protocol (ghcb, call) + :__svsm_msr_protocol (call); + }while (ret ==SVSM_ERR_BUSY ); + +if (sev_cfg.ghcbs_initialized) +__sev_put_ghcb (&state); + +if (flags &X86_EFLAGS_IF ) +native_irq_enable (); + +return ret; +} + void noinstr __sev_es_nmi_complete(void) {struct ghcb_state state;@@ -1369,6 +1450,18 @@ static void __init alloc_runtime_data(int cpu)panic ("Can't allocate SEV-ES runtime data" );per_cpu (runtime_data, cpu) = data; + +if (vmpl) { +struct svsm_ca *caa; + +/* Allocate the SVSM CA page if an SVSM is present */ + caa =memblock_alloc (sizeof (*caa),PAGE_SIZE ); +if (!caa) +panic ("Can't allocate SVSM CA page\n" ); + +per_cpu (svsm_caa, cpu) = caa; +per_cpu (svsm_caa_pa, cpu) =__pa (caa); + } }static void __init init_ghcb (int cpu)@@ -1418,6 +1511,31 @@ void __init sev_es_init_vc_handling(void)init_ghcb (cpu); } +/* If running under an SVSM, switch to the per-cpu CA */ +if (vmpl) { +struct svsm_call call = {}; +unsigned long flags; +int ret; + +local_irq_save (flags); + +/* +* SVSM_CORE_REMAP_CA call: +* RAX = 0 (Protocol=0, CallID=0) +* RCX = New CA GPA +*/ + call.caa =__svsm_get_caa (); + call.rax =SVSM_CORE_CALL (SVSM_CORE_REMAP_CA ); + call.rcx =this_cpu_read (svsm_caa_pa); + ret =svsm_protocol (&call); +if (ret !=SVSM_SUCCESS ) +panic ("Can't remap the SVSM CA, ret=%#x (%d)\n" , ret, ret); + + sev_cfg.cas_initialized = true; + +local_irq_restore (flags); + } +sev_es_setup_play_dead ();/* Secondary CPUs use the runtime #VC handler */ @@ -1842,33 +1960,6 @@ static enum es_result vc_handle_exitcode(struct es_em_ctxt *ctxt,return result; } -static __always_inline void vc_forward_exception(struct es_em_ctxt *ctxt) -{ -long error_code = ctxt->fi.error_code; -int trapnr = ctxt->fi.vector; - - ctxt->regs->orig_ax = ctxt->fi.error_code; - -switch (trapnr) { -case X86_TRAP_GP : -exc_general_protection (ctxt->regs, error_code); -break ; -case X86_TRAP_UD : -exc_invalid_op (ctxt->regs); -break ; -case X86_TRAP_PF : -write_cr2 (ctxt->fi.cr2); -exc_page_fault (ctxt->regs, error_code); -break ; -case X86_TRAP_AC : -exc_alignment_check (ctxt->regs, error_code); -break ; -default : -pr_emerg ("Unsupported exception in #VC instruction emulation - can't continue\n" ); -BUG (); - } -} - static __always_inline bool is_vc2_stack(unsigned long sp) {return (sp >=__this_cpu_ist_bottom_va (VC2 ) && sp <__this_cpu_ist_top_va (VC2 ));@@ -2118,6 +2209,50 @@ static __head struct cc_blob_sev_info *find_cc_blob(struct boot_params *bp)return cc_info; } +static __head void setup_svsm(struct cc_blob_sev_info *cc_info) +{ +struct svsm_call call = {}; +int ret; +u64 pa; + +/* +* Record the SVSM Calling Area address (CAA) if the guest is not +* running at VMPL0. The CA will be used to communicate with the +* SVSM to perform the SVSM services. +*/
arch/x86/kernel/sev.c static __head struct cc_blob_sev_info *find_cc_blob(struct boot_params *bp) · line 2232
Quoted 10 lines
arch/x86/kernel/sev.c +10
-0+setup_svsm_ca (cc_info); + +/* Nothing to do if not running under an SVSM. */ +if (!vmpl) +return ; + +/* +* It is very early in the boot and the kernel is running identity +* mapped but without having adjusted the pagetables to where the +* kernel was loaded (physbase), so the get the CA address using
\..> s/the/''
Quoted 79 lines
arch/x86/kernel/sev.c +33
-6+* RIP-relative addressing. +*/ + pa = (u64)&RIP_REL_REF (boot_svsm_ca_page); + +/* +* Switch over to the boot SVSM CA while the current CA is still +* addressable. There is no GHCB at this point so use the MSR protocol. +* +* SVSM_CORE_REMAP_CA call: +* RAX = 0 (Protocol=0, CallID=0) +* RCX = New CA GPA +*/ + call.caa =__svsm_get_caa (); + call.rax =SVSM_CORE_CALL (SVSM_CORE_REMAP_CA ); + call.rcx = pa; + ret =svsm_protocol (&call); +if (ret !=SVSM_SUCCESS ) +panic ("Can't remap the SVSM CA, ret=%#x (%d)\n" , ret, ret); + + boot_svsm_caa = (struct svsm_ca *)pa; + boot_svsm_caa_pa = pa; +} + bool __head snp_init(struct boot_params *bp) {struct cc_blob_sev_info *cc_info;@@ -2131,12 +2266,7 @@ bool __head snp_init(struct boot_params *bp)setup_cpuid_table (cc_info); -/* -* Record the SVSM Calling Area address (CAA) if the guest is not -* running at VMPL0. The CA will be used to communicate with the -* SVSM to perform the SVSM services. -*/ -setup_svsm_ca (cc_info); +setup_svsm (cc_info);/* * The CC blob will be used later to access the secrets page. Cache @@ -2328,3 +2458,12 @@ void sev_show_status(void) }pr_cont ("\n" ); } + +void __init snp_remap_svsm_ca (void ) +{ +if (!vmpl) +return ; + +/* Update the CAA to a proper kernel address */ + boot_svsm_caa = &boot_svsm_ca_page; +}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 )
PATCH v3 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 v3 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
Re: [PATCH v3 06/14] x86/sev: Use the SVSM to create a vCPU when not in VMPL0
Quoted 10 lines · Tom Lendacky
Using the RMPADJUST instruction, the VSMA attribute can only be changed at VMPL0. An SVSM will be present when running at VMPL1 or a lower privilege level.
When an SVSM is present, use the
SVSM_CORE_CREATE_VCPUcall or theSVSM_CORE_DESTROY_VCPUcall to perform VMSA attribute changes. Use the VMPL level supplied by the SVSM within the VMSA and when starting the AP.Signed-off-by Tom Lendacky <[email protected]>
Quoted 149 lines
--- 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@@ -1016,7 +1016,7 @@ void snp_accept_memory(phys_addr_t start, phys_addr_t end)set_pages_state (vaddr, npages,SNP_PAGE_STATE_PRIVATE ); } -static int snp_set_vmsa (void *va,bool vmsa) +static int base_snp_set_vmsa (void *va,bool vmsa) {u64 attrs;@@ -1034,6 +1034,40 @@ static int snp_set_vmsa(void *va, bool vmsa)return rmpadjust ((unsigned long )va,RMP_PG_SIZE_4K , attrs); } +static int svsm_snp_set_vmsa (void *va,void *caa,int apic_id,bool vmsa) +{ +struct svsm_call call = {}; +unsigned long flags; +int ret; + +local_irq_save (flags); + + call.caa =this_cpu_read (svsm_caa); + call.rcx =__pa (va); + +if (vmsa) { +/* Protocol 0, Call ID 2 */ + call.rax =SVSM_CORE_CALL (SVSM_CORE_CREATE_VCPU ); + call.rdx =__pa (caa); + call.r8 = apic_id; + }else { +/* Protocol 0, Call ID 3 */ + call.rax =SVSM_CORE_CALL (SVSM_CORE_DELETE_VCPU ); + } + + ret =svsm_protocol (&call); + +local_irq_restore (flags); + +return ret; +} + +static int snp_set_vmsa (void *va,void *caa,int apic_id,bool vmsa) +{ +return vmpl ?svsm_snp_set_vmsa (va, caa, apic_id, vmsa) + :base_snp_set_vmsa (va, vmsa); +} +#define __ATTR_BASE (SVM_SELECTOR_P_MASK | SVM_SELECTOR_S_MASK)#define INIT_CS_ATTRIBS (__ATTR_BASE | SVM_SELECTOR_READ_MASK | SVM_SELECTOR_CODE_MASK)#define INIT_DS_ATTRIBS (__ATTR_BASE | SVM_SELECTOR_WRITE_MASK)@@ -1065,11 +1099,11 @@ static void *snp_alloc_vmsa_page(void)return page_address (p +1 ); } -static void snp_cleanup_vmsa (struct sev_es_save_area *vmsa) +static void snp_cleanup_vmsa (struct sev_es_save_area *vmsa,int apic_id) {int err; - err =snp_set_vmsa (vmsa, false); + err =snp_set_vmsa (vmsa,NULL , apic_id, false);if (err)pr_err ("clear VMSA page failed (%u), leaking page\n" , err);else @@ -1080,6 +1114,7 @@ static int wakeup_cpu_via_vmgexit(u32 apic_id, unsigned long start_ip) {struct sev_es_save_area *cur_vmsa, *vmsa;struct ghcb_state state; +struct svsm_ca *caa;unsigned long flags;struct ghcb *ghcb;u8 sipi_vector;@@ -1126,6 +1161,12 @@ static int wakeup_cpu_via_vmgexit(u32 apic_id, unsigned long start_ip)if (!vmsa)return -ENOMEM ; +/* +* If an SVSM is present, then the SVSM CAA per-CPU variable will +* have a value, otherwise it will be NULL. +*/ + caa =per_cpu (svsm_caa, cpu); +/* CR4 should maintain the MCE value */ cr4 =native_read_cr4 () &X86_CR4_MCE ;@@ -1173,11 +1214,11 @@ static int wakeup_cpu_via_vmgexit(u32 apic_id, unsigned long start_ip)* VMPL level * SEV_FEATURES (matches the SEV STATUS MSR right shifted 2 bits) */ - vmsa->vmpl =0 ; + vmsa->vmpl = vmpl; vmsa->sev_features = sev_status >>2 ;/* Switch the page over to a VMSA page now that it is initialized */ - ret =snp_set_vmsa (vmsa, true); + ret =snp_set_vmsa (vmsa, caa, apic_id, true);if (ret) {pr_err ("set VMSA page failed (%u)\n" , ret);free_page ((unsigned long )vmsa);@@ -1193,7 +1234,10 @@ static int wakeup_cpu_via_vmgexit(u32 apic_id, unsigned long start_ip)vc_ghcb_invalidate (ghcb);ghcb_set_rax (ghcb, vmsa->sev_features);ghcb_set_sw_exit_code (ghcb,SVM_VMGEXIT_AP_CREATION ); -ghcb_set_sw_exit_info_1 (ghcb, ((u64 )apic_id <<32 ) |SVM_VMGEXIT_AP_CREATE ); +ghcb_set_sw_exit_info_1 (ghcb, + ((u64 )apic_id <<32 ) | + ((u64 )vmpl <<16 ) | +SVM_VMGEXIT_AP_CREATE );ghcb_set_sw_exit_info_2 (ghcb,__pa (vmsa));sev_es_wr_ghcb_msr (__pa (ghcb));@@ -1211,13 +1255,13 @@ static int wakeup_cpu_via_vmgexit(u32 apic_id, unsigned long start_ip)/* Perform cleanup if there was an error */ if (ret) { -snp_cleanup_vmsa (vmsa); +snp_cleanup_vmsa (vmsa, apic_id); vmsa =NULL ; }/* Free up any previous VMSA page */ if (cur_vmsa) -snp_cleanup_vmsa (cur_vmsa); +snp_cleanup_vmsa (cur_vmsa, apic_id);/* Record the current VMSA page */ per_cpu (sev_vmsa, cpu) = vmsa;
PATCH v3 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
@@ -654,6 +654,8 @@#define MSR_AMD64_RMP_BASE 0xc0010132#define MSR_AMD64_RMP_END 0xc0010133 +#define MSR_SVSM_CAA 0xc001f000 +/* AMD Collaborative Processor Performance Control MSRs */ #define MSR_AMD_CPPC_CAP1 0xc00102b0#define MSR_AMD_CPPC_ENABLE 0xc00102b1
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 __head setup_svsm_ca(const struct cc_blob_sev_info *cc_info) {struct snp_secrets_page_layout *secrets_page; +struct snp_cpuid_table *cpuid_table; +unsigned int i;u64 caa;BUILD_BUG_ON (sizeof (*secrets_page) !=PAGE_SIZE );
@@ -1596,4 +1598,13 @@ static void __head setup_svsm_ca(const struct cc_blob_sev_info *cc_info)*/ boot_svsm_caa = (struct svsm_ca *)caa; boot_svsm_caa_pa = caa; + +/* Advertise the SVSM presence via CPUID. */ + cpuid_table = (struct snp_cpuid_table *)snp_cpuid_get_table (); +for (i =0 ; i < cpuid_table->count; i++) { +struct snp_cpuid_fn *fn = &cpuid_table->fn[i]; + +if (fn->eax_in ==0x8000001f ) + fn->eax |=BIT (28 ); + } }
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
Re: [PATCH v3 07/14] x86/sev: Provide SVSM discovery support
Quoted 7 lines · Tom Lendacky
The SVSM specification documents an alternative method of discovery for the SVSM using a reserved CPUID bit and a reserved MSR.
For the CPUID support, the SNP CPUID table is updated to set bit 28 of the EAX register of the
0x8000001fleaf when an SVSM is present. This bit has been reserved for use in this capacity.
Quoted 6 lines
For the MSR support, a new reserved MSR
0xc001f000has been defined. A #VC should be generated when accessing this MSR. The #VC handler is expected to ignore writes to this MSR and return the physical calling area address (CAA) on reads of this MSR.Signed-off-by Tom Lendacky <[email protected]>
Quoted 93 lines
--- 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@@ -654,6 +654,8 @@#define MSR_AMD64_RMP_BASE 0xc0010132#define MSR_AMD64_RMP_END 0xc0010133 +#define MSR_SVSM_CAA 0xc001f000 +/* AMD Collaborative Processor Performance Control MSRs */ #define MSR_AMD_CPPC_CAP1 0xc00102b0#define MSR_AMD_CPPC_ENABLE 0xc00102b1arch/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 __head setup_svsm_ca(const struct cc_blob_sev_info *cc_info) {struct snp_secrets_page_layout *secrets_page; +struct snp_cpuid_table *cpuid_table; +unsigned int i;u64 caa;BUILD_BUG_ON (sizeof (*secrets_page) !=PAGE_SIZE );@@ -1596,4 +1598,13 @@ static void __head setup_svsm_ca(const struct cc_blob_sev_info *cc_info)*/ boot_svsm_caa = (struct svsm_ca *)caa; boot_svsm_caa_pa = caa; + +/* Advertise the SVSM presence via CPUID. */ + cpuid_table = (struct snp_cpuid_table *)snp_cpuid_get_table (); +for (i =0 ; i < cpuid_table->count; i++) { +struct snp_cpuid_fn *fn = &cpuid_table->fn[i]; + +if (fn->eax_in ==0x8000001f ) + fn->eax |=BIT (28 ); + } }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 ;
PATCH v3 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
@@ -2527,3 +2527,40 @@ void __init snp_remap_svsm_ca(void)/* Update the CAA to a proper kernel address */ boot_svsm_caa = &boot_svsm_ca_page; } + +static ssize_t vmpl_show (struct kobject *kobj, +struct kobj_attribute *attr,char *buf) +{ +return sysfs_emit (buf,"%d\n" , vmpl); +} + +static struct kobj_attribute vmpl_attr =__ATTR_RO (vmpl); + +static struct attribute *vmpl_attrs[] = { + &vmpl_attr.attr, +NULL +}; + +static struct attribute_group sev_attr_group = { + .attrs = vmpl_attrs, +}; + +static int __init sev_sysfs_init (void ) +{ +struct kobject *sev_kobj; +int ret; + +if (!cc_platform_has (CC_ATTR_GUEST_SEV_SNP )) +return -ENODEV ; + + sev_kobj =kobject_create_and_add ("sev" , kernel_kobj); +if (!sev_kobj) +return -ENOMEM ; + + ret =sysfs_create_group (sev_kobj, &sev_attr_group); +if (ret) +kobject_put (sev_kobj); + +return ret; +} +arch_initcall (sev_sysfs_init);
Signature · 1 line
2.43.2
PATCH v3 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 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
@@ -2464,6 +2464,12 @@ int snp_issue_guest_request(u64 exit_code, struct snp_req_data *input, struct sn }EXPORT_SYMBOL_GPL (snp_issue_guest_request); +int snp_get_vmpl (void ) +{ +return vmpl; +} +EXPORT_SYMBOL_GPL (snp_get_vmpl); +static struct platform_device sev_guest_device = { .name ="sev-guest" , .id =-1 ,
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
Re: [PATCH v3 09/14] virt: sev-guest: Choose the VMPCK key based on executing VMPL
Hey, Tom, came looking to review the tsm_report changes and noticed this...
Quoted 4 lines · Tom Lendacky
Currently, the sev-guest driver uses the vmpck-0 key by default. When an SVSM is present the kernel is running at a VMPL other than 0 and the vmpck-0 key is no longer available. So choose the vmpck key based on the active VMPL level.
The module parameter is not mentioned in the changelog. Is it not sufficient to always use snp_get_vmpl(), and if not should there be some documentation about when to specify vmpck_id?
Do users know that "vmpl" and "vmpck_id" are interchangeable?
Re: [PATCH v3 09/14] virt: sev-guest: Choose the VMPCK key based on executing VMPL
Quoted 4 lines · Dan Williams
Hey, Tom, came looking to review the
tsm_reportchanges and noticed this...Tom Lendacky wrote:
Quoted 8 lines
Quoted 4 lines
Currently, the sev-guest driver uses the vmpck-0 key by default. When an SVSM is present the kernel is running at a VMPL other than 0 and the vmpck-0 key is no longer available. So choose the vmpck key based on the active VMPL level.
The module parameter is not mentioned in the changelog. Is it not sufficient to always use
snp_get_vmpl(), and if not should there be some documentation about when to specifyvmpck_id?
It is possible to encounter an issue that causes the vmpck key to be cleared. In that situation, the guest is allowed to use a vmpck key associated with a lower VMPL. For that reason, the module parameter was added to the driver when it was initially created.
I can update the changelog to mention this.
Note that as long as the vmpck key exists, a guest running at VMPL2 could request a VMPL0 report using the vmpck0 key, that is why it is important that the SVSM clear to zero any vmpck key that represents a higher privilege. For example, if the SVSM (running at VMPL0) launches the guest at VMPL2, it should zero out the vmpck0 and vmpck1 keys in the SNP Secrets Page supplied to the guest.
Quoted 2 lines
Do users know that "vmpl" and "
vmpck_id" are interchangeable?
Yes, they should be aware of the relation of VMPL to VMPCK from the SNP specification.
Thanks,
Tom
Re: [PATCH v3 09/14] virt: sev-guest: Choose the VMPCK key based on executing VMPL
Quoted 10 lines · Tom Lendacky
Quoted 9 lines · Dan Williams
Hey, Tom, came looking to review the
tsm_reportchanges and noticed this...Quoted 4 lines · Tom Lendacky
Currently, the sev-guest driver uses the vmpck-0 key by default. When an SVSM is present the kernel is running at a VMPL other than 0 and the vmpck-0 key is no longer available. So choose the vmpck key based on the active VMPL level.
Quoted 8 lines
Quoted 3 lines
The module parameter is not mentioned in the changelog. Is it not sufficient to always use
snp_get_vmpl(), and if not should there be some documentation about when to specifyvmpck_id?It is possible to encounter an issue that causes the vmpck key to be cleared. In that situation, the guest is allowed to use a vmpck key associated with a lower VMPL. For that reason, the module parameter was added to the driver when it was initially created.
Oh, sorry, misread that the module parameter was not new.
Quoted 1 line
I can update the changelog to mention this.
I guess it is too late now, but a proper sysfs attribute rather than a module parameter would let you do sanity checking on the writes and allow a natural place to document behavior in Documentation/ABI/testing/sysfs-devices-sev-guest.
PATCH v3 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
Re: [PATCH v3 10/14] configfs-tsm: Allow the privlevel_floor attribute to be updated
Quoted 26 lines · Tom Lendacky
With the introduction of an SVSM, Linux will be running at a non-zero VMPL. Any request for an attestation report at a higher priviledge VMPL than what Linux is currently running will result in an error. Allow for the
privlevel_floorattribute to be updated dynamically so that the attribute may be set dynamically.Signed-off-by Tom Lendacky <[email protected]>--- 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 +1
-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, };
drivers/virt/coco/sev-guest/sev-guest.c static int __init sev_guest_probe(struct platform_device *pdev) · line 976
Quoted 5 lines
drivers/virt/coco/sev-guest/sev-guest.c +2
-0@@ -972,6 +972,9 @@ static int __init sev_guest_probe(struct platform_device *pdev) snp_dev->input.resp_gpa =__pa (snp_dev->response); snp_dev->input.data_gpa =__pa (snp_dev->certs_data); +/* Set the privlevel_floor attribute based on the current VMPL */ + sev_tsm_ops.privlevel_floor =snp_get_vmpl ();
Why is this not vmpck_id?
Re: [PATCH v3 10/14] configfs-tsm: Allow the privlevel_floor attribute to be updated
Quoted 30 lines · Dan Williams
Quoted 29 lines · Tom Lendacky
With the introduction of an SVSM, Linux will be running at a non-zero VMPL. Any request for an attestation report at a higher priviledge VMPL than what Linux is currently running will result in an error. Allow for the
privlevel_floorattribute to be updated dynamically so that the attribute may be set dynamically.Signed-off-by Tom Lendacky <[email protected]>--- 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 +1
-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);
Quoted 4 lines
drivers/virt/coco/sev-guest/sev-guest.c static int __init sev_guest_probe(struct platform_device *pdev) · line 976
Quoted 2 lines
drivers/virt/coco/sev-guest/sev-guest.c +2
-0+/* Set the privlevel_floor attribute based on the current VMPL */ + sev_tsm_ops.privlevel_floor =snp_get_vmpl ();Why is this not
vmpck_id?
Good catch, this probably should be pulled out separately and submitted as a Fixes: against the current support. If you think it's important enough, I can do that and put this at the beginning of the series. Or I can just modify this to use the vmpck_id value. Any preference?
Thanks,
Tom
Re: [PATCH v3 10/14] configfs-tsm: Allow the privlevel_floor attribute to be updated
Quoted 36 lines · Tom Lendacky
Quoted 30 lines · Dan Williams
Quoted 29 lines · Tom Lendacky
With the introduction of an SVSM, Linux will be running at a non-zero VMPL. Any request for an attestation report at a higher priviledge VMPL than what Linux is currently running will result in an error. Allow for the
privlevel_floorattribute to be updated dynamically so that the attribute may be set dynamically.Signed-off-by Tom Lendacky <[email protected]>--- 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 +1
-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);Quoted 4 lines
drivers/virt/coco/sev-guest/sev-guest.c static int __init sev_guest_probe(struct platform_device *pdev) · line 976
Quoted 2 lines
drivers/virt/coco/sev-guest/sev-guest.c +2
-0+/* Set the privlevel_floor attribute based on the current VMPL */ + sev_tsm_ops.privlevel_floor =snp_get_vmpl ();Why is this not
vmpck_id?
Quoted 4 lines
Good catch, this probably should be pulled out separately and submitted as a Fixes: against the current support. If you think it's important enough, I can do that and put this at the beginning of the series. Or I can just modify this to use the
vmpck_idvalue. Any preference?
I dunno, you tell me. What breaks if privlevel_floor is mismatched vs vmpl and/or vmpck_id? If it warrants a "Fixes:" it should probably be broken out.
However, I *guess* it is just adding some sanity checking precision to userspace requests and makes some input validation not catch errors when userspace tries to generate reports from the wrong level, right? I.e. privlevel_floor may be lower than expected, but userspace should not be depending on that since the report generation will fail.
Re: [PATCH v3 10/14] configfs-tsm: Allow the privlevel_floor attribute to be updated
Quoted 46 lines · Dan Williams
Quoted 36 lines · Tom Lendacky
Quoted 30 lines · Dan Williams
Quoted 29 lines · Tom Lendacky
With the introduction of an SVSM, Linux will be running at a non-zero VMPL. Any request for an attestation report at a higher priviledge VMPL than what Linux is currently running will result in an error. Allow for the
privlevel_floorattribute to be updated dynamically so that the attribute may be set dynamically.Signed-off-by Tom Lendacky <[email protected]>--- 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 +1
-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);Quoted 4 lines
drivers/virt/coco/sev-guest/sev-guest.c static int __init sev_guest_probe(struct platform_device *pdev) · line 976
Quoted 2 lines
drivers/virt/coco/sev-guest/sev-guest.c +2
-0+/* Set the privlevel_floor attribute based on the current VMPL */ + sev_tsm_ops.privlevel_floor =snp_get_vmpl ();Why is this not
vmpck_id?Quoted 4 lines
Good catch, this probably should be pulled out separately and submitted as a Fixes: against the current support. If you think it's important enough, I can do that and put this at the beginning of the series. Or I can just modify this to use the
vmpck_idvalue. Any preference?I dunno, you tell me. What breaks if
privlevel_flooris mismatched vs vmpl and/orvmpck_id? If it warrants a "Fixes:" it should probably be broken out.
Quoted 5 lines
However, I *guess* it is just adding some sanity checking precision to userspace requests and makes some input validation not catch errors when userspace tries to generate reports from the wrong level, right? I.e.
privlevel_floormay be lower than expected, but userspace should not be depending on that since the report generation will fail.
Yeah, it just results in a different type of error. If the VMPL specified by the user is numerically lower than the vmpck_id, then the request will fail with a specific return code value. With the change to privlevel_floor to use vmpck_id, then you would just get the error that much sooner when trying to set a value that is lower than the floor.
Since I don't think the vmpck_id module parameter is a common case today, let's just leave that change in this patch.
Thanks,
Tom
PATCH v3 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:
- 'service-provider' (input)
This attribute is used to determine whether the attestation request should be sent to the specified service provider or to the SEV firmware. The SVSM service provider is represented by the value 'svsm'.
- 'service_guid' (input)
Used for requesting the attestation of a single service within the service provider. A null GUID implies that the SVSM_ATTEST_SERVICES call should be used to request the attestation report. A non-null GUID implies that the SVSM_ATTEST_SINGLE_SERVICE call should be used.
- 'service_manifest_version' (input)
Used with the SVSM_ATTEST_SINGLE_SERVICE call, the service version represents a specific service manifest version be used for the attestation report.
- 'manifestblob' (output)
Used to return the service manifest associated with the attestation report.
--- Documentation/ABI/testing/configfs-tsm | 69 +++++++++++ arch/x86/include/asm/sev.h | 31 ++++- arch/x86/kernel/sev.c | 50 ++++++++ drivers/virt/coco/sev-guest/sev-guest.c | 151 ++++++++++++++++++++++++ drivers/virt/coco/tsm.c | 93 ++++++++++++++- include/linux/tsm.h | 11 ++ 6 files changed, 402 insertions(+), 3 deletions(-)
Documentation/ABI/testing/configfs-tsm +69 -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.10 +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 @service_provider is + "svsm" this file contains the service manifest used for the SVSM + attestation report from the Secure VM Service Module for SEV-SNP + Guests v1.00 Section 7. + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf + What: /sys/kernel/config/tsm/report/$name/provider Date: September, 2023 KernelVersion: v6.7
@@ -80,3 +95,57 @@ Contact: [email protected] Description: (RO) Indicates the minimum permissible value that can be written to @privlevel. + +What: /sys/kernel/config/tsm/report/$name/service_provider +Date: January, 2024 +KernelVersion: v6.10 +Contact: [email protected] +Description: + (WO) Attribute is visible if a TSM implementation provider + supports the concept of attestation reports from a service + provider for TVMs, like SEV-SNP running under an SVSM. + Specifying the service provider via this attribute will create + an attestation report as specified by the service provider. + Currently supported service-providers are: + svsm + + For the SVSM service provider, see the Secure VM Service Module + for SEV-SNP Guests v1.00 Section 7. + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf + +What: /sys/kernel/config/tsm/report/$name/service_guid +Date: January, 2024 +KernelVersion: v6.10 +Contact: [email protected] +Description: + (WO) Attribute is visible if a TSM implementation provider + supports the concept of attestation reports from a service + provider for TVMs, like SEV-SNP running under an SVSM. + Specifying an empty/null GUID (00000000-0000-0000-0000-000000) + requests all active services within the service provider be + part of the attestation report. Specifying a GUID request + an attestation report of just the specified service using the + manifest form specified by the service_manifest_version + attribute. + + For the SVSM service provider, see the Secure VM Service Module + for SEV-SNP Guests v1.00 Section 7. + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf + +What: /sys/kernel/config/tsm/report/$name/service_manifest_version +Date: January, 2024 +KernelVersion: v6.10 +Contact: [email protected] +Description: + (WO) Attribute is visible if a TSM implementation provider + supports the concept of attestation reports from a service + provider for TVMs, like SEV-SNP running under an SVSM. + Indicates the service manifest version requested for the + attestation report. If this field is not set by the user, + the default manifest version of the service (the service's + initial/first manifest version) is returned. The initial + manifest version is always available. + + For the SVSM service provider, see the Secure VM Service Module + for SEV-SNP Guests v1.00 Section 7. + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
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 +151 -0
169 lines not on this page · raw message
drivers/virt/coco/tsm.c +91 -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 +* @service_provider: optional name of where to obtain the tsm report blob +* @service_guid: optional service-provider service guid to attest +* @service_manifest_version: optional service-provider service manifest version requested */ struct tsm_desc {unsigned int privlevel;size_t inblob_len;u8 inblob[TSM_INBLOB_MAX ]; +char *service_provider; +guid_t service_guid; +unsigned int service_manifest_version; };/**
@@ -33,6 +40,8 @@ struct tsm_desc {* @outblob: generated evidence to provider to the attestation agent * @auxblob_len: sizeof(@auxblob) * @auxblob: (optional) auxiliary data to the report (e.g. certificate data) +* @manifestblob_len: sizeof(@manifestblob) +* @manifestblob: (optional) manifest data associated with the report */ struct tsm_report {struct tsm_desc desc;
@@ -40,6 +49,8 @@ struct tsm_report {u8 *outblob;size_t auxblob_len;u8 *auxblob; +size_t manifestblob_len; +u8 *manifestblob; };/**
Signature · 1 line
2.43.2
Re: [PATCH v3 11/14] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 50 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:
- 'service-provider' (input)
This attribute is used to determine whether the attestation request should be sent to the specified service provider or to the SEV firmware. The SVSM service provider is represented by the value 'svsm'.- '
service_guid' (input)
Used for requesting the attestation of a single service within the service provider. A null GUID implies that 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 | 69 +++++++++++ arch/x86/include/asm/sev.h | 31 ++++- arch/x86/kernel/sev.c | 50 ++++++++ drivers/virt/coco/sev-guest/sev-guest.c | 151 ++++++++++++++++++++++++ drivers/virt/coco/tsm.c | 93 ++++++++++++++- include/linux/tsm.h | 11 ++ 6 files changed, 402 insertions(+), 3 deletions(-)Documentation/ABI/testing/configfs-tsm +4
-0@@ -31,6 +31,21 @@ Description: Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ. https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf +What: /sys/kernel/config/tsm/report/$name/manifestblob +Date: January, 2024 +KernelVersion: v6.10 +Contact: [email protected]
Documentation/ABI/testing/configfs-tsm Description: · line 47
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +10
-0+Description: + (RO) Optional supplemental data that a TSM may emit, visibility + of this attribute depends on TSM, and may be empty if no + manifest data is available. + + When @provider is "sev_guest" and the @service_provider is + "svsm" this file contains the service manifest used for the SVSM + attestation report from the Secure VM Service Module for SEV-SNP + Guests v1.00 Section 7. + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
Should this be "See 'service_provider' for the format of this blob"? To date external "format specification" links are only referenced once in this file, and this one is now duplicated.
Quoted 15 lines
Documentation/ABI/testing/configfs-tsm +8
-0+ What: /sys/kernel/config/tsm/report/$name/provider Date: September, 2023 KernelVersion: v6.7@@ -80,3 +95,57 @@ Contact: [email protected] Description: (RO) Indicates the minimum permissible value that can be written to @privlevel. + +What: /sys/kernel/config/tsm/report/$name/service_provider +Date: January, 2024 +KernelVersion: v6.10 +Contact: [email protected] +Description: + (WO) Attribute is visible if a TSM implementation provider
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 114
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +10
-0+ supports the concept of attestation reports from a service + provider for TVMs, like SEV-SNP running under an SVSM. + Specifying the service provider via this attribute will create + an attestation report as specified by the service provider. + Currently supported service-providers are: + svsm + + For the SVSM service provider, see the Secure VM Service Module + for SEV-SNP Guests v1.00 Section 7. + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
Given "SVSM" is a cross vendor concept should this explicitly
callout: "For provider.service_provider == sev_guest.svsm" as preparation for other implementations defining their "svsm" manifest format?
Quoted 9 lines
Documentation/ABI/testing/configfs-tsm +9
-0+ +What: /sys/kernel/config/tsm/report/$name/service_guid +Date: January, 2024 +KernelVersion: v6.10 +Contact: [email protected] +Description: + (WO) Attribute is visible if a TSM implementation provider + supports the concept of attestation reports from a service + provider for TVMs, like SEV-SNP running under an SVSM.
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 133
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +10
-0+ Specifying an empty/null GUID (00000000-0000-0000-0000-000000) + requests all active services within the service provider be + part of the attestation report. Specifying a GUID request + an attestation report of just the specified service using the + manifest form specified by the service_manifest_version + attribute. + + For the SVSM service provider, see the Secure VM Service Module + for SEV-SNP Guests v1.00 Section 7. + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
...another "See..." instead of duplicate.
Quoted 4 lines
Documentation/ABI/testing/configfs-tsm +4
-0+ +What: /sys/kernel/config/tsm/report/$name/service_manifest_version +Date: January, 2024 +KernelVersion: v6.10
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 147
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +10
-0+Contact: [email protected] +Description: + (WO) Attribute is visible if a TSM implementation provider + supports the concept of attestation reports from a service + provider for TVMs, like SEV-SNP running under an SVSM. + Indicates the service manifest version requested for the + attestation report. If this field is not set by the user, + the default manifest version of the service (the service's + initial/first manifest version) is returned. The initial + manifest version is always available.
...and that number is zero? Is there any expectation that the kernel sanity checks this version, or how does the user figure out they need to roll this request back?
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 114
Quoted 4 lines
Documentation/ABI/testing/configfs-tsm +4
-0+ + For the SVSM service provider, see the Secure VM Service Module + for SEV-SNP Guests v1.00 Section 7. + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
Ditto on replacing this with a "See.." reference.
Quoted 329 lines
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@@ -2400,6 +2400,56 @@ static int __init init_sev_config(char *str) }__setup ("sev=" , init_sev_config); +static void update_attestation_input (struct svsm_call *call,struct svsm_attestation_call *input) +{ +/* If (new) lengths have been returned, propograte them up */ +if (call->rcx_out != call->rcx) + input->manifest_buffer.len = call->rcx_out; + +if (call->rdx_out != call->rdx) + input->certificates_buffer.len = call->rdx_out; + +if (call->r8_out != call->r8) + input->report_buffer.len = call->r8_out; +} + +int snp_issue_svsm_attestation_request (u64 call_id,struct svsm_attestation_call *input) +{ +struct svsm_attestation_call *attest_call; +struct svsm_call call = {}; +unsigned long flags; +u64 attest_call_pa; +int ret; + +if (!vmpl) +return -EINVAL ; + +local_irq_save (flags); + + call.caa =__svsm_get_caa (); + + attest_call = (struct svsm_attestation_call *)call.caa->svsm_buffer; + attest_call_pa =__svsm_get_caa_pa () + offsetof(struct svsm_ca , svsm_buffer); + + *attest_call = *input; + +/* +* Set input registers for the request and set RDX and R8 to known +* values in order to detect length values being returned in them. +*/ + call.rax = call_id; + call.rcx = attest_call_pa; + call.rdx =-1 ; + call.r8 =-1 ; + ret =svsm_protocol (&call); +update_attestation_input (&call, input); + +local_irq_restore (flags); + +return ret; +} +EXPORT_SYMBOL_GPL (snp_issue_svsm_attestation_request); +int snp_issue_guest_request (u64 exit_code,struct snp_req_data *input,struct snp_guest_request_ioctl *rio) {struct ghcb_state state;drivers/virt/coco/sev-guest/sev-guest.c +151
-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 ; + +if (guid_is_null (&desc->service_guid)) { + call_id =SVSM_ATTEST_CALL (SVSM_ATTEST_SERVICES ); + }else { +export_guid (attest_call.service_guid, &desc->service_guid); + attest_call.service_manifest_version = desc->service_manifest_version; + + call_id =SVSM_ATTEST_CALL (SVSM_ATTEST_SINGLE_SERVICE ); + } + + retry_count =0 ; + +retry: + size = report_len + manifest_len + certificates_len; + buffer =alloc_pages_exact (size, __GFP_ZERO); +if (!buffer) +return -ENOMEM ; + + report_blob = buffer; + attest_call.report_buffer.pa =__pa (report_blob); + attest_call.report_buffer.len = report_len; + + manifest_blob = report_blob + report_len; + attest_call.manifest_buffer.pa =__pa (manifest_blob); + attest_call.manifest_buffer.len = manifest_len; + + certificates_blob = manifest_blob + manifest_len; + attest_call.certificates_buffer.pa =__pa (certificates_blob); + attest_call.certificates_buffer.len = certificates_len; + + attest_call.nonce.pa =__pa (desc->inblob); + attest_call.nonce.len = desc->inblob_len; + + ret =snp_issue_svsm_attestation_request (call_id, &attest_call); +switch (ret) { +case SVSM_SUCCESS : +break ; +case SVSM_ERR_INVALID_PARAMETER : + ret = -EINVAL ; + +if (retry_count >=SVSM_MAX_RETRIES ) + goto error; + + try_again = false; + +if (attest_call.report_buffer.len > report_len) { + report_len =PAGE_ALIGN (attest_call.report_buffer.len); + try_again = true; + } + +if (attest_call.manifest_buffer.len > manifest_len) { + manifest_len =PAGE_ALIGN (attest_call.manifest_buffer.len); + try_again = true; + } + +if (attest_call.certificates_buffer.len > certificates_len) { + certificates_len =PAGE_ALIGN (attest_call.certificates_buffer.len); + try_again = true; + } + +/* If one of the buffers wasn't large enough, retry the request */ +if (try_again) { +free_pages_exact (buffer, size); + retry_count++; + goto retry; + } + + goto error; +case SVSM_ERR_BUSY : + ret = -EAGAIN ; + goto error; +default : +pr_err_ratelimited ("SVSM attestation request failed (%#x)\n" , ret); + ret = -EINVAL ; + goto error; + } + + ret = -ENOMEM ; + + report_len = attest_call.report_buffer.len; + void *rbuf __free(kvfree) = kvzalloc(report_len, GFP_KERNEL); +if (!rbuf) + goto error; + +memcpy (rbuf, report_blob, report_len); + report->outblob =no_free_ptr (rbuf); + report->outblob_len = report_len; + + manifest_len = attest_call.manifest_buffer.len; + void *mbuf __free(kvfree) = kvzalloc(manifest_len, GFP_KERNEL); +if (!mbuf) + goto error; + +memcpy (mbuf, manifest_blob, manifest_len); + report->manifestblob =no_free_ptr (mbuf); + report->manifestblob_len = manifest_len; + + certificates_len = attest_call.certificates_buffer.len; +if (!certificates_len) + goto success; + + void *cbuf __free(kvfree) = kvzalloc(certificates_len, GFP_KERNEL); +if (!cbuf) + goto error; + +memcpy (cbuf, certificates_blob, certificates_len); + report->auxblob =no_free_ptr (cbuf); + report->auxblob_len = certificates_len; + +success: + ret =0 ; + +error: +free_pages_exact (buffer, size); + +return ret; +} +static int sev_report_new (struct tsm_report *report,void *data) {struct snp_msg_cert_entry *cert_table;@@ -797,6 +941,13 @@ static int sev_report_new(struct tsm_report *report, void *data)if (desc->inblob_len !=SNP_REPORT_USER_DATA_SIZE )return -EINVAL ; +if (desc->service_provider) { +if (strcmp (desc->service_provider,"svsm" )) +return -EINVAL ; + +return sev_svsm_report_new (report, data); + } + void *buf __free(kvfree) = kvzalloc(size, GFP_KERNEL);if (!buf)return -ENOMEM ;drivers/virt/coco/tsm.c +6
-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,74 @@ static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg, }CONFIGFS_ATTR_RO (tsm_report_, privlevel_floor); +static ssize_t tsm_report_service_provider_store (struct config_item *cfg, +const char *buf,size_t len) +{ +struct tsm_report *report =to_tsm_report (cfg);
drivers/virt/coco/tsm.c static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg, · line 136
Quoted 10 lines
drivers/virt/coco/tsm.c +10
-0+size_t sp_len; +char *sp; +int rc; + +guard (rwsem_write)(&tsm_rwsem); + rc =try_advance_write_generation (report); +if (rc) +return rc; + + sp_len = (buf[len -1 ] !='\n' ) ? len : len -1 ;
This feels like it wants a sysfs_strdup().
Quoted 104 lines
drivers/virt/coco/tsm.c +69
-1+ + sp =kstrndup (buf, sp_len,GFP_KERNEL ); +if (!sp) +return -ENOMEM ; +kfree (report->desc.service_provider); + + report->desc.service_provider = sp; + +return len; +} +CONFIGFS_ATTR_WO (tsm_report_, service_provider); + +static ssize_t tsm_report_service_guid_store (struct config_item *cfg, +const char *buf,size_t len) +{ +struct tsm_report *report =to_tsm_report (cfg); +int rc; + +guard (rwsem_write)(&tsm_rwsem); + rc =try_advance_write_generation (report); +if (rc) +return rc; + + report->desc.service_guid = guid_null; + + rc =guid_parse (buf, &report->desc.service_guid); +if (rc) +return rc; + +return len; +} +CONFIGFS_ATTR_WO (tsm_report_, service_guid); + +static ssize_t tsm_report_service_manifest_version_store (struct config_item *cfg, +const char *buf,size_t len) +{ +struct tsm_report *report =to_tsm_report (cfg); +unsigned int val; +int rc; + + rc =kstrtouint (buf,0 , &val); +if (rc) +return rc; + +guard (rwsem_write)(&tsm_rwsem); + rc =try_advance_write_generation (report); +if (rc) +return rc; + report->desc.service_manifest_version = val; + +return len; +} +CONFIGFS_ATTR_WO (tsm_report_, service_manifest_version); +static ssize_t tsm_report_inblob_write (struct config_item *cfg,const void *buf,size_t count) {@@ -163,6 +232,9 @@ static ssize_t __read_report(struct tsm_report *report, void *buf, size_t count,if (select ==TSM_REPORT ) { out = report->outblob; len = report->outblob_len; + }else if (select ==TSM_MANIFEST ) { + out = report->manifestblob; + len = report->manifestblob_len; }else { out = report->auxblob; len = report->auxblob_len;@@ -188,7 +260,7 @@ static ssize_t read_cached_report(struct tsm_report *report, void *buf,/* * A given TSM backend always fills in ->outblob regardless of -* whether the report includes an auxblob or not. +* whether the report includes an auxblob/manifestblob or not. */ if (!report->outblob || state->read_generation != state->write_generation)@@ -224,8 +296,10 @@ static ssize_t tsm_report_read(struct tsm_report *report, void *buf,kvfree (report->outblob);kvfree (report->auxblob); +kvfree (report->manifestblob); report->outblob =NULL ; report->auxblob =NULL ; + report->manifestblob =NULL ; rc = ops->report_new (report, provider.data);if (rc <0 )return rc;@@ -252,6 +326,15 @@ static ssize_t tsm_report_auxblob_read(struct config_item *cfg, void *buf, }CONFIGFS_BIN_ATTR_RO (tsm_report_, auxblob,NULL ,TSM_OUTBLOB_MAX ); +static ssize_t tsm_report_manifestblob_read (struct config_item *cfg,void *buf, +size_t count) +{ +struct tsm_report *report =to_tsm_report (cfg); + +return tsm_report_read (report, buf, count,TSM_MANIFEST ); +} +CONFIGFS_BIN_ATTR_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX ); +#define TSM_DEFAULT_ATTRS () \ &tsm_report_attr_generation, \ &tsm_report_attr_provider
drivers/virt/coco/tsm.c static struct configfs_attribute *tsm_report_extra_attrs[] = { · line 353
Quoted 6 lines
drivers/virt/coco/tsm.c +3
-0@@ -265,6 +348,9 @@ static struct configfs_attribute *tsm_report_extra_attrs[] = {TSM_DEFAULT_ATTRS (), &tsm_report_attr_privlevel, &tsm_report_attr_privlevel_floor, + &tsm_report_attr_service_provider, + &tsm_report_attr_service_guid, + &tsm_report_attr_service_manifest_version,
Shouldn't this patch come after the configfs dynamic visibility so there is no point in the history where vestigial attributes show up?
Re: [PATCH v3 11/14] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 57 lines · Dan Williams
Quoted 56 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:
- 'service-provider' (input)
This attribute is used to determine whether the attestation request should be sent to the specified service provider or to the SEV firmware. The SVSM service provider is represented by the value 'svsm'.- '
service_guid' (input)
Used for requesting the attestation of a single service within the service provider. A null GUID implies that 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 | 69 +++++++++++ arch/x86/include/asm/sev.h | 31 ++++- arch/x86/kernel/sev.c | 50 ++++++++ drivers/virt/coco/sev-guest/sev-guest.c | 151 ++++++++++++++++++++++++ drivers/virt/coco/tsm.c | 93 ++++++++++++++- include/linux/tsm.h | 11 ++ 6 files changed, 402 insertions(+), 3 deletions(-)Documentation/ABI/testing/configfs-tsm +10
-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.10 +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 @service_provider is
Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Description: · line 47
Quoted 4 lines
Documentation/ABI/testing/configfs-tsm +4
-0+ "svsm" this file contains the service manifest used for the SVSM + attestation report from the Secure VM Service Module for SEV-SNP + Guests v1.00 Section 7. + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdfShould this be "See '
service_provider' for the format of this blob"? To date external "format specification" links are only referenced once in this file, and this one is now duplicated.
Yes, I can do that for this and the other ones you identified below.
Quoted 24 lines
Quoted 24 lines
Documentation/ABI/testing/configfs-tsm +15
-0+ What: /sys/kernel/config/tsm/report/$name/provider Date: September, 2023 KernelVersion: v6.7@@ -80,3 +95,57 @@ Contact: [email protected] Description: (RO) Indicates the minimum permissible value that can be written to @privlevel. + +What: /sys/kernel/config/tsm/report/$name/service_provider +Date: January, 2024 +KernelVersion: v6.10 +Contact: [email protected] +Description: + (WO) Attribute is visible if a TSM implementation provider + supports the concept of attestation reports from a service + provider for TVMs, like SEV-SNP running under an SVSM. + Specifying the service provider via this attribute will create + an attestation report as specified by the service provider. + Currently supported service-providers are: + svsm +
Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 114
Quoted 3 lines
Documentation/ABI/testing/configfs-tsm +3
-0+ For the SVSM service provider, see the Secure VM Service Module + for SEV-SNP Guests v1.00 Section 7. + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdfGiven "SVSM" is a cross vendor concept should this explicitly
callout: "For provider.service_provider == sev_guest.svsm" as preparation for other implementations defining their "svsm" manifest format?
I'm not sure. Do we need to get that specific? If SVSM is cross vendor, will it be using / adding to the existing SVSM specification? If not, then each vendor is likely to have its own name for the SVSM concept that would be unique enough...
Quoted 18 lines
Quoted 6 lines
Documentation/ABI/testing/configfs-tsm +4
-0+ +What: /sys/kernel/config/tsm/report/$name/service_manifest_version +Date: January, 2024 +KernelVersion: v6.10Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 147
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +10
-0+Contact: [email protected] +Description: + (WO) Attribute is visible if a TSM implementation provider + supports the concept of attestation reports from a service + provider for TVMs, like SEV-SNP running under an SVSM. + Indicates the service manifest version requested for the + attestation report. If this field is not set by the user, + the default manifest version of the service (the service's + initial/first manifest version) is returned. The initial + manifest version is always available....and that number is zero? Is there any expectation that the kernel
Yes, that number is zero.
Quoted 2 lines
sanity checks this version, or how does the user figure out they need to roll this request back?
Right now there aren't any non-zero versions, so there is nothing for the user to figure out. However, the service will determine when it creates a new version and then the user will need to understand what the reason for that is and decide. I'm not sure I can give you a specific answer at this stage, but we need to allow for a change in the manifest without affecting existing users.
And since the spec has been approved already, I can't really go back and add a requirement that manifest format always be additive.
Quoted 7 lines
Quoted 5 lines
Documentation/ABI/testing/configfs-tsm +4
-0+ + For the SVSM service provider, see the Secure VM Service Module + for SEV-SNP Guests v1.00 Section 7. + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
Quoted 16 lines
Quoted 4 lines
Documentation/ABI/testing/configfs-tsm +4
-0+static ssize_t tsm_report_service_provider_store(struct config_item *cfg, + const char *buf, size_t len) +{ + struct tsm_report *report = to_tsm_report(cfg);Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 146
Quoted 10 lines
Documentation/ABI/testing/configfs-tsm +10
-0+ size_t sp_len; + char *sp; + int rc; + + guard(rwsem_write)(&tsm_rwsem); + rc = try_advance_write_generation(report); + if (rc) + return rc; + + sp_len = (buf[len - 1] != '\n') ? len : len - 1;This feels like it wants a
sysfs_strdup().
If there start to be more string oriented operations in the file, then it might be worth it. For now I don't really see a reason.
Quoted 14 lines
Quoted 13 lines
Documentation/ABI/testing/configfs-tsm +12
-0+ + sp = kstrndup(buf, sp_len, GFP_KERNEL); + if (!sp) + return -ENOMEM; + kfree(report->desc.service_provider); + + report->desc.service_provider = sp; + + return len; +} +CONFIGFS_ATTR_WO(tsm_report_, service_provider); +
Quoted 13 lines
Documentation/ABI/testing/configfs-tsm static struct configfs_attribute *tsm_report_extra_attrs[] = { · line 353
Quoted 10 lines
#define TSM_DEFAULT_ATTRS() \ &tsm_report_attr_generation, \ &tsm_report_attr_providerDocumentation/ABI/testing/configfs-tsm +3
-0@@ -265,6 +348,9 @@ static struct configfs_attribute *tsm_report_extra_attrs[] = { TSM_DEFAULT_ATTRS(), &tsm_report_attr_privlevel, &tsm_report_attr_privlevel_floor, + &tsm_report_attr_service_provider, + &tsm_report_attr_service_guid, + &tsm_report_attr_service_manifest_version,Shouldn't this patch come after the configfs dynamic visibility so there is no point in the history where vestigial attributes show up?
Sure, I can do that.
Thanks,
Tom
Re: [PATCH v3 11/14] x86/sev: Extend the config-fs attestation support for an SVSM
Quoted 31 lines · Tom Lendacky
Quoted 30 lines · Dan Williams
Quoted 29 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:
- 'service-provider' (input)
This attribute is used to determine whether the attestation request should be sent to the specified service provider or to the SEV firmware. The SVSM service provider is represented by the value 'svsm'.- '
service_guid' (input)
Used for requesting the attestation of a single service within the service provider. A null GUID implies that 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]>
[..]
Quoted 22 lines
Quoted 13 lines
Quoted 13 lines
Documentation/ABI/testing/configfs-tsm +13
-0+What: /sys/kernel/config/tsm/report/$name/service_provider +Date: January, 2024 +KernelVersion: v6.10 +Contact: [email protected] +Description: + (WO) Attribute is visible if a TSM implementation provider + supports the concept of attestation reports from a service + provider for TVMs, like SEV-SNP running under an SVSM. + Specifying the service provider via this attribute will create + an attestation report as specified by the service provider. + Currently supported service-providers are: + svsm +Quoted 8 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 114
Quoted 3 lines
Documentation/ABI/testing/configfs-tsm +3
-0+ For the SVSM service provider, see the Secure VM Service Module + for SEV-SNP Guests v1.00 Section 7. + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdfGiven "SVSM" is a cross vendor concept should this explicitly
callout: "For provider.service_provider == sev_guest.svsm" as preparation for other implementations defining their "svsm" manifest format?
Quoted 4 lines
I'm not sure. Do we need to get that specific? If SVSM is cross vendor, will it be using / adding to the existing SVSM specification? If not, then each vendor is likely to have its own name for the SVSM concept that would be unique enough...
Yeah, I guess we can kick can that down the road and see what other vendors do. I know the coconut-svsm project is cross vendor, but I do not know the details.
Quoted 22 lines
Quoted 8 lines
Quoted 8 lines
Documentation/ABI/testing/configfs-tsm +8
-0+ +What: /sys/kernel/config/tsm/report/$name/service_manifest_version +Date: January, 2024 +KernelVersion: v6.10 +Contact: [email protected] +Description: + (WO) Attribute is visible if a TSM implementation provider + supports the concept of attestation reports from a serviceQuoted 8 lines
Documentation/ABI/testing/configfs-tsm Contact: [email protected] · line 147
Quoted 6 lines
Documentation/ABI/testing/configfs-tsm +6
-0+ provider for TVMs, like SEV-SNP running under an SVSM. + Indicates the service manifest version requested for the + attestation report. If this field is not set by the user, + the default manifest version of the service (the service's + initial/first manifest version) is returned. The initial + manifest version is always available....and that number is zero? Is there any expectation that the kernel
Yes, that number is zero.
Quoted 2 lines
sanity checks this version, or how does the user figure out they need to roll this request back?
Quoted 6 lines
Right now there aren't any non-zero versions, so there is nothing for the user to figure out. However, the service will determine when it creates a new version and then the user will need to understand what the reason for that is and decide. I'm not sure I can give you a specific answer at this stage, but we need to allow for a change in the manifest without affecting existing users.
Right, but it feels odd that userspace could write UINT_MAX to this value and the kernel says, "yup, looks like a valid manifest version to me".
Quoted 2 lines
And since the spec has been approved already, I can't really go back and add a requirement that manifest format always be additive.
Those breaking changes have not arrived yet so still a chance to influence, no?
The documentation here at least guarantees that the initial manifest version is always valid, and I expect the spec authors to realize that the kernel has a role to play in not breaking existing userspace. I.e. it is not in the spec's interest to disallow fallback to any version between 0 and N-1 where N is the latest.
The kernel need not tolerate version induced breakage from ACPI specification updates because that spec is committed to compatibility, why does this spec need to be less disciplined than that?
Quoted 23 lines
Quoted 6 lines
Quoted 4 lines
Documentation/ABI/testing/configfs-tsm +4
-0+ + For the SVSM service provider, see the Secure VM Service Module + for SEV-SNP Guests v1.00 Section 7. + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdfQuoted 16 lines
Quoted 4 lines
drivers/virt/coco/tsm.c +4
-0+static ssize_t tsm_report_service_provider_store (struct config_item *cfg, +const char *buf,size_t len) +{ +struct tsm_report *report =to_tsm_report (cfg);drivers/virt/coco/tsm.c static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg, · line 136
Quoted 10 lines
drivers/virt/coco/tsm.c +10
-0+size_t sp_len; +char *sp; +int rc; + +guard (rwsem_write)(&tsm_rwsem); + rc =try_advance_write_generation (report); +if (rc) +return rc; + + sp_len = (buf[len -1 ] !='\n' ) ? len : len -1 ;This feels like it wants a
sysfs_strdup().
Quoted 2 lines
If there start to be more string oriented operations in the file, then it might be worth it. For now I don't really see a reason.
To be clear I was thinking of occurrences of this patten outside of this file. Turns out this pattern is not as prevalent as I would have guessed, resource_alignment_store() was the only occurrence I could find. Skip for now works for me.
PATCH v3 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 | 7 +++ include/linux/configfs.h | 111 +++++++++++++++++++++++++++------------ 2 files changed, 84 insertions(+), 34 deletions(-)
fs/configfs/file.c +7 -0
@@ -451,6 +451,9 @@ 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->is_visible && !attr->is_visible (item, attr)) +return 0 ; +inode_lock_nested (d_inode (dir),I_MUTEX_NORMAL ); error =configfs_make_dirent (parent_sd,NULL , (void *) attr, mode,CONFIGFS_ITEM_ATTR , parent_sd->s_frag);
@@ -470,9 +473,13 @@ int configfs_create_bin_file(struct config_item *item, {struct dentry *dir = item->ci_dentry;struct configfs_dirent *parent_sd = dir->d_fsdata; +const struct configfs_attribute *attr = &bin_attr->cb_attr;umode_t mode = (bin_attr->cb_attr.ca_mode &S_IALLUGO ) |S_IFREG ;int error =0 ; +if (attr->is_visible && !attr->is_visible (item, attr)) +return 0 ; +inode_lock_nested (dir->d_inode,I_MUTEX_NORMAL ); error =configfs_make_dirent (parent_sd,NULL , (void *) bin_attr, mode,CONFIGFS_ITEM_BIN_ATTR , parent_sd->s_frag);
include/linux/configfs.h +77 -34
155 lines not on this page · raw message
Signature · 1 line
2.43.2
Re: [PATCH v3 12/14] fs/configfs: Add a callback to determine attribute visibility
Quoted 3 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
s/display/displayed/
Quoted 50 lines
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 | 7 +++ include/linux/configfs.h | 111 +++++++++++++++++++++++++++------------ 2 files changed, 84 insertions(+), 34 deletions(-)fs/configfs/file.c +7
-0@@ -451,6 +451,9 @@ 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->is_visible && !attr->is_visible (item, attr)) +return 0 ; +inode_lock_nested (d_inode (dir),I_MUTEX_NORMAL ); error =configfs_make_dirent (parent_sd,NULL , (void *) attr, mode,CONFIGFS_ITEM_ATTR , parent_sd->s_frag);@@ -470,9 +473,13 @@ int configfs_create_bin_file(struct config_item *item, {struct dentry *dir = item->ci_dentry;struct configfs_dirent *parent_sd = dir->d_fsdata; +const struct configfs_attribute *attr = &bin_attr->cb_attr;umode_t mode = (bin_attr->cb_attr.ca_mode &S_IALLUGO ) |S_IFREG ;int error =0 ; +if (attr->is_visible && !attr->is_visible (item, attr)) +return 0 ; +inode_lock_nested (dir->d_inode,I_MUTEX_NORMAL ); error =configfs_make_dirent (parent_sd,NULL , (void *) bin_attr, mode,CONFIGFS_ITEM_BIN_ATTR , parent_sd->s_frag);include/linux/configfs.h +1
-0@@ -116,35 +116,57 @@ struct configfs_attribute {const char *ca_name;struct module *ca_owner;umode_t ca_mode; +bool (*is_visible)(const struct config_item *,const struct configfs_attribute *);ssize_t (*show)(struct config_item *,char *);ssize_t (*store)(struct config_item *,const char *,size_t ); };
include/linux/configfs.h struct configfs_attribute { · line 131
Quoted 10 lines
include/linux/configfs.h +2
-1-#define CONFIGFS_ATTR (_pfx, _name) \ +#define __CONFIGFS_ATTR (_pfx, _name, _vis) \ static struct configfs_attribute _pfx##attr_##_name = { \ .ca_name = __stringify(_name), \ .ca_mode = S_IRUGO | S_IWUSR, \ .ca_owner = THIS_MODULE, \ + .is_visible = _vis, \ .show = _pfx##_name##_show, \ .store = _pfx##_name##_store, \
Shouldn't this operation live in configfs_group_operations? That would mirror the sysfs organization, and likely saves some memory.
Re: [PATCH v3 12/14] fs/configfs: Add a callback to determine attribute visibility
Quoted 6 lines · Dan Williams
Quoted 3 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
s/display/displayed/
Will fix.
Quoted 52 lines
Quoted 52 lines
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 | 7 +++ include/linux/configfs.h | 111 +++++++++++++++++++++++++++------------ 2 files changed, 84 insertions(+), 34 deletions(-)fs/configfs/file.c +7
-0@@ -451,6 +451,9 @@ 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->is_visible && !attr->is_visible (item, attr)) +return 0 ; +inode_lock_nested (d_inode (dir),I_MUTEX_NORMAL ); error =configfs_make_dirent (parent_sd,NULL , (void *) attr, mode,CONFIGFS_ITEM_ATTR , parent_sd->s_frag);@@ -470,9 +473,13 @@ int configfs_create_bin_file(struct config_item *item, {struct dentry *dir = item->ci_dentry;struct configfs_dirent *parent_sd = dir->d_fsdata; +const struct configfs_attribute *attr = &bin_attr->cb_attr;umode_t mode = (bin_attr->cb_attr.ca_mode &S_IALLUGO ) |S_IFREG ;int error =0 ; +if (attr->is_visible && !attr->is_visible (item, attr)) +return 0 ; +inode_lock_nested (dir->d_inode,I_MUTEX_NORMAL ); error =configfs_make_dirent (parent_sd,NULL , (void *) bin_attr, mode,CONFIGFS_ITEM_BIN_ATTR , parent_sd->s_frag);include/linux/configfs.h +1
-0@@ -116,35 +116,57 @@ struct configfs_attribute {const char *ca_name;struct module *ca_owner;umode_t ca_mode; +bool (*is_visible)(const struct config_item *,const struct configfs_attribute *);ssize_t (*show)(struct config_item *,char *);ssize_t (*store)(struct config_item *,const char *,size_t ); };
Quoted 12 lines
include/linux/configfs.h struct configfs_attribute { · line 131
Quoted 9 lines
include/linux/configfs.h +2
-1-#define CONFIGFS_ATTR (_pfx, _name) \ +#define __CONFIGFS_ATTR (_pfx, _name, _vis) \ static struct configfs_attribute _pfx##attr_##_name = { \ .ca_name = __stringify(_name), \ .ca_mode = S_IRUGO | S_IWUSR, \ .ca_owner = THIS_MODULE, \ + .is_visible = _vis, \ .show = _pfx##_name##_show, \ .store = _pfx##_name##_store, \Shouldn't this operation live in
configfs_group_operations? That would mirror the sysfs organization, and likely saves some memory.
I suppose it can, but then you lose the grouping of attributes within the same directory, right? A configfs group will result in moving the entries into a subdirectory, right? If we go with the group level, then we will be moving the existing TSM extra attributes and the new TSM SVSM attributes into new, separate sub-directories.
Thanks,
Tom
Re: [PATCH v3 12/14] fs/configfs: Add a callback to determine attribute visibility
Quoted 5 lines · Tom Lendacky
Quoted 4 lines · Dan Williams
Quoted 3 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
[..]
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Cc Joel Becker <[email protected]>Cc Christoph Hellwig <[email protected]>Signed-off-by Tom Lendacky <[email protected]>--- fs/configfs/file.c | 7 +++ include/linux/configfs.h | 111 +++++++++++++++++++++++++++------------ 2 files changed, 84 insertions(+), 34 deletions(-)
[..]
Quoted 26 lines
Quoted 13 lines
Quoted 13 lines
include/linux/configfs.h +1
-0@@ -116,35 +116,57 @@ struct configfs_attribute {const char *ca_name;struct module *ca_owner;umode_t ca_mode; +bool (*is_visible)(const struct config_item *,const struct configfs_attribute *);ssize_t (*show)(struct config_item *,char *);ssize_t (*store)(struct config_item *,const char *,size_t ); };Quoted 12 lines
include/linux/configfs.h struct configfs_attribute { · line 131
Quoted 9 lines
include/linux/configfs.h +2
-1-#define CONFIGFS_ATTR (_pfx, _name) \ +#define __CONFIGFS_ATTR (_pfx, _name, _vis) \ static struct configfs_attribute _pfx##attr_##_name = { \ .ca_name = __stringify(_name), \ .ca_mode = S_IRUGO | S_IWUSR, \ .ca_owner = THIS_MODULE, \ + .is_visible = _vis, \ .show = _pfx##_name##_show, \ .store = _pfx##_name##_store, \Shouldn't this operation live in
configfs_group_operations? That would mirror the sysfs organization, and likely saves some memory.
Quoted 5 lines
I suppose it can, but then you lose the grouping of attributes within the same directory, right? A configfs group will result in moving the entries into a subdirectory, right? If we go with the group level, then we will be moving the existing TSM extra attributes and the new TSM SVSM attributes into new, separate sub-directories.
I am not following the concern about "losing the grouping"? Here is what I was thinking with having the visibility routines in group operations. This is just the broard strokes, it compiles, but still needs the finer detail work to make tdx-guest skip all the attributes that do not apply to it. Might need to be broken up a bit more, but hopefully conveys the idea. Does this address your grouping concern?
drivers/virt/coco/sev-guest/sev-guest.c +1 -1
@@ -968,7 +968,7 @@ static int __init sev_guest_probe(struct platform_device *pdev) snp_dev->input.resp_gpa =__pa (snp_dev->response); snp_dev->input.data_gpa =__pa (snp_dev->certs_data); - ret =tsm_register (&sev_tsm_ops, snp_dev, &tsm_report_extra_type); + ret =tsm_register (&sev_tsm_ops, snp_dev);if (ret) goto e_free_cert_data;
drivers/virt/coco/tdx-guest/tdx-guest.c +1 -1
@@ -301,7 +301,7 @@ static int __init tdx_guest_init(void) goto free_misc; } - ret =tsm_register (&tdx_tsm_ops,NULL ,NULL ); + ret =tsm_register (&tdx_tsm_ops,NULL );if (ret) goto free_quote;
drivers/virt/coco/tsm.c +36 -44
140 lines not on this page · raw message
fs/configfs/dir.c +6 -0
@@ -580,6 +580,7 @@ static void detach_attrs(struct config_item * item)static int populate_attrs (struct config_item *item) {const struct config_item_type *t = item->ci_type; +struct configfs_group_operations *ops = t->ct_group_ops;struct configfs_attribute *attr;struct configfs_bin_attribute *bin_attr;int error =0 ;
@@ -589,12 +590,17 @@ static int populate_attrs(struct config_item *item)return -EINVAL ;if (t->ct_attrs) {for (i =0 ; (attr = t->ct_attrs[i]) !=NULL ; i++) { +if (ops && ops->is_visible && !ops->is_visible (attr, i)) +continue ;if ((error =configfs_create_file (item, attr)))break ; } }if (t->ct_bin_attrs) {for (i =0 ; (bin_attr = t->ct_bin_attrs[i]) !=NULL ; i++) { +if (ops && ops->is_bin_visible && + !ops->is_bin_visible (bin_attr, i)) +continue ; error =configfs_create_bin_file (item, bin_attr);if (error)break ;
fs/configfs/file.c +2 -1
@@ -444,7 +444,8 @@ const struct file_operations configfs_bin_file_operations = {* @attr: atrribute descriptor. */ -int configfs_create_file (struct config_item * item,const struct configfs_attribute * attr) +int configfs_create_file (struct config_item *item, +const struct configfs_attribute *attr) {struct dentry *dir = item->ci_dentry;struct configfs_dirent *parent_sd = dir->d_fsdata;
include/linux/configfs.h +2 -0
@@ -216,6 +216,8 @@ struct configfs_group_operations {struct config_group *(*make_group)(struct config_group *group,const char *name);void (*disconnect_notify)(struct config_group *group,struct config_item *item);void (*drop_item)(struct config_group *group,struct config_item *item); +bool (*is_visible)(struct configfs_attribute *attr,int n); +bool (*is_bin_visible)(struct configfs_bin_attribute *attr,int n); };struct configfs_subsystem {
include/linux/tsm.h +16 -7
@@ -42,6 +42,19 @@ struct tsm_report {u8 *auxblob; }; +enum tsm_attr_index { +TSM_REPORT_GENERATION , +TSM_REPORT_PROVIDER , +TSM_REPORT_PRIVLEVEL , +TSM_REPORT_PRIVLEVEL_FLOOR , +}; + +enum tsm_bin_attr_index { +TSM_REPORT_INBLOB , +TSM_REPORT_OUTBLOB , +TSM_REPORT_AUXBLOB , +}; +/** * struct tsm_ops - attributes and operations for tsm instances * @name: tsm id reflected in /sys/kernel/config/tsm/report/$report/provider
@@ -55,15 +68,11 @@ struct tsm_report {struct tsm_ops {const char *name;const unsigned int privlevel_floor; +bool (*is_visible)(enum tsm_attr_index index); +bool (*is_bin_visible)(enum tsm_bin_attr_index index);int (*report_new)(struct tsm_report *report,void *data); }; -extern const struct config_item_type tsm_report_default_type; - -/* publish @privlevel, @privlevel_floor, and @auxblob attributes */ -extern const struct config_item_type tsm_report_extra_type; - -int tsm_register (const struct tsm_ops *ops,void *priv, -const struct config_item_type *type); +int tsm_register (const struct tsm_ops *ops,void *priv);int tsm_unregister (const struct tsm_ops *ops);#endif /* __TSM_H */
Re: [PATCH v3 12/14] fs/configfs: Add a callback to determine attribute visibility
Quoted 48 lines · Dan Williams
Quoted 5 lines · Tom Lendacky
Quoted 4 lines · Dan Williams
Quoted 3 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
[..]
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Cc Joel Becker <[email protected]>Cc Christoph Hellwig <[email protected]>Signed-off-by Tom Lendacky <[email protected]>--- fs/configfs/file.c | 7 +++ include/linux/configfs.h | 111 +++++++++++++++++++++++++++------------ 2 files changed, 84 insertions(+), 34 deletions(-)[..]
Quoted 26 lines
Quoted 13 lines
Quoted 13 lines
include/linux/configfs.h +1
-0@@ -116,35 +116,57 @@ struct configfs_attribute {const char *ca_name;struct module *ca_owner;umode_t ca_mode; +bool (*is_visible)(const struct config_item *,const struct configfs_attribute *);ssize_t (*show)(struct config_item *,char *);ssize_t (*store)(struct config_item *,const char *,size_t ); };Quoted 12 lines
include/linux/configfs.h struct configfs_attribute { · line 131
Quoted 9 lines
include/linux/configfs.h +2
-1-#define CONFIGFS_ATTR (_pfx, _name) \ +#define __CONFIGFS_ATTR (_pfx, _name, _vis) \ static struct configfs_attribute _pfx##attr_##_name = { \ .ca_name = __stringify(_name), \ .ca_mode = S_IRUGO | S_IWUSR, \ .ca_owner = THIS_MODULE, \ + .is_visible = _vis, \ .show = _pfx##_name##_show, \ .store = _pfx##_name##_store, \Shouldn't this operation live in
configfs_group_operations? That would mirror the sysfs organization, and likely saves some memory.Quoted 5 lines
I suppose it can, but then you lose the grouping of attributes within the same directory, right? A configfs group will result in moving the entries into a subdirectory, right? If we go with the group level, then we will be moving the existing TSM extra attributes and the new TSM SVSM attributes into new, separate sub-directories.
Quoted 6 lines
I am not following the concern about "losing the grouping"? Here is what I was thinking with having the visibility routines in group operations. This is just the broard strokes, it compiles, but still needs the finer detail work to make tdx-guest skip all the attributes that do not apply to it. Might need to be broken up a bit more, but hopefully conveys the idea. Does this address your grouping concern?
Yes and no. Basically the is_visible()/is_bin_visible() callback will have to check every index value for a "group" against the passed in value. I was trying to group the values together using an enum in order to make it a bit easier and more readable in the callback. Adding another attribute to the group requires updates in multiple places. But thats just how I was looking at it. I can also see where you might want to selectively hide/show entries and this method works well for that.
I'll follow this approach (add you as Co-developed-by: or Suggested-by:, whichever you prefer) and submit a v4.
Thanks,
Tom
Quoted 278 lines
drivers/virt/coco/sev-guest/sev-guest.c +1
-1@@ -968,7 +968,7 @@ static int __init sev_guest_probe(struct platform_device *pdev) snp_dev->input.resp_gpa =__pa (snp_dev->response); snp_dev->input.data_gpa =__pa (snp_dev->certs_data); - ret =tsm_register (&sev_tsm_ops, snp_dev, &tsm_report_extra_type); + ret =tsm_register (&sev_tsm_ops, snp_dev);if (ret) goto e_free_cert_data;drivers/virt/coco/tdx-guest/tdx-guest.c +1
-1@@ -301,7 +301,7 @@ static int __init tdx_guest_init(void) goto free_misc; } - ret =tsm_register (&tdx_tsm_ops,NULL ,NULL ); + ret =tsm_register (&tdx_tsm_ops,NULL );if (ret) goto free_quote;drivers/virt/coco/tsm.c +36
-44@@ -14,7 +14,6 @@static struct tsm_provider {const struct tsm_ops *ops; -const struct config_item_type *type;void *data; } provider;static DECLARE_RWSEM (tsm_rwsem);@@ -252,34 +251,18 @@ static ssize_t tsm_report_auxblob_read(struct config_item *cfg, void *buf, }CONFIGFS_BIN_ATTR_RO (tsm_report_, auxblob,NULL ,TSM_OUTBLOB_MAX ); -#define TSM_DEFAULT_ATTRS () \ - &tsm_report_attr_generation, \ - &tsm_report_attr_provider -static struct configfs_attribute *tsm_report_attrs[] = { -TSM_DEFAULT_ATTRS (), -NULL , -}; - -static struct configfs_attribute *tsm_report_extra_attrs[] = { -TSM_DEFAULT_ATTRS (), - &tsm_report_attr_privlevel, - &tsm_report_attr_privlevel_floor, + [TSM_REPORT_GENERATION ] = &tsm_report_attr_generation, + [TSM_REPORT_PROVIDER ] = &tsm_report_attr_provider, + [TSM_REPORT_PRIVLEVEL ] = &tsm_report_attr_privlevel, + [TSM_REPORT_PRIVLEVEL_FLOOR ] = &tsm_report_attr_privlevel_floor,NULL , }; -#define TSM_DEFAULT_BIN_ATTRS () \ - &tsm_report_attr_inblob, \ - &tsm_report_attr_outblob -static struct configfs_bin_attribute *tsm_report_bin_attrs[] = { -TSM_DEFAULT_BIN_ATTRS (), -NULL , -}; - -static struct configfs_bin_attribute *tsm_report_bin_extra_attrs[] = { -TSM_DEFAULT_BIN_ATTRS (), - &tsm_report_attr_auxblob, + [TSM_REPORT_INBLOB ] = &tsm_report_attr_inblob, + [TSM_REPORT_OUTBLOB ] = &tsm_report_attr_outblob, + [TSM_REPORT_AUXBLOB ] = &tsm_report_attr_auxblob,NULL , };@@ -297,21 +280,12 @@ static struct configfs_item_operations tsm_report_item_ops = { .release = tsm_report_item_release, }; -const struct config_item_type tsm_report_default_type = { +static const struct config_item_type tsm_report_type = { .ct_owner =THIS_MODULE , .ct_bin_attrs = tsm_report_bin_attrs, .ct_attrs = tsm_report_attrs, .ct_item_ops = &tsm_report_item_ops, }; -EXPORT_SYMBOL_GPL (tsm_report_default_type); - -const struct config_item_type tsm_report_extra_type = { - .ct_owner =THIS_MODULE , - .ct_bin_attrs = tsm_report_bin_extra_attrs, - .ct_attrs = tsm_report_extra_attrs, - .ct_item_ops = &tsm_report_item_ops, -}; -EXPORT_SYMBOL_GPL (tsm_report_extra_type);static struct config_item *tsm_report_make_item (struct config_group *group,const char *name)@@ -326,12 +300,38 @@ static struct config_item *tsm_report_make_item(struct config_group *group,if (!state)return ERR_PTR (-ENOMEM ); -config_item_init_type_name (&state->cfg, name, provider.type); +config_item_init_type_name (&state->cfg, name, &tsm_report_type);return &state->cfg; } +static bool tsm_report_attr_visible (struct configfs_attribute *attr,int n) +{ +guard (rwsem_read)(&tsm_rwsem); +if (!provider.ops) +return false; + +if (!provider.ops->is_visible) +return true; + +return provider.ops->is_visible (n); +} + +static bool tsm_report_bin_attr_visible (struct configfs_bin_attribute *attr, +int n) +{ +if (!provider.ops) +return false; + +if (!provider.ops->is_bin_visible) +return true; + +return provider.ops->is_bin_visible (n); +} +static struct configfs_group_operations tsm_report_group_ops = { .make_item = tsm_report_make_item, + .is_visible = tsm_report_attr_visible, + .is_bin_visible = tsm_report_bin_attr_visible, };static const struct config_item_type tsm_reports_type = {@@ -353,16 +353,10 @@ static struct configfs_subsystem tsm_configfs = { .su_mutex = __MUTEX_INITIALIZER(tsm_configfs.su_mutex), }; -int tsm_register (const struct tsm_ops *ops,void *priv, -const struct config_item_type *type) +int tsm_register (const struct tsm_ops *ops,void *priv) {const struct tsm_ops *conflict; -if (!type) - type = &tsm_report_default_type; -if (!(type == &tsm_report_default_type || type == &tsm_report_extra_type)) -return -EINVAL ; -guard (rwsem_write)(&tsm_rwsem); conflict = provider.ops;if (conflict) {@@ -372,7 +366,6 @@ int tsm_register(const struct tsm_ops *ops, void *priv, provider.ops = ops; provider.data = priv; - provider.type = type;return 0 ; }EXPORT_SYMBOL_GPL (tsm_register);@@ -384,7 +377,6 @@ int tsm_unregister(const struct tsm_ops *ops)return -EBUSY ; provider.ops =NULL ; provider.data =NULL ; - provider.type =NULL ;return 0 ; }EXPORT_SYMBOL_GPL (tsm_unregister);fs/configfs/dir.c +6
-0@@ -580,6 +580,7 @@ static void detach_attrs(struct config_item * item)static int populate_attrs (struct config_item *item) {const struct config_item_type *t = item->ci_type; +struct configfs_group_operations *ops = t->ct_group_ops;struct configfs_attribute *attr;struct configfs_bin_attribute *bin_attr;int error =0 ;@@ -589,12 +590,17 @@ static int populate_attrs(struct config_item *item)return -EINVAL ;if (t->ct_attrs) {for (i =0 ; (attr = t->ct_attrs[i]) !=NULL ; i++) { +if (ops && ops->is_visible && !ops->is_visible (attr, i)) +continue ;if ((error =configfs_create_file (item, attr)))break ; } }if (t->ct_bin_attrs) {for (i =0 ; (bin_attr = t->ct_bin_attrs[i]) !=NULL ; i++) { +if (ops && ops->is_bin_visible && + !ops->is_bin_visible (bin_attr, i)) +continue ; error =configfs_create_bin_file (item, bin_attr);if (error)break ;fs/configfs/file.c +2
-1@@ -444,7 +444,8 @@ const struct file_operations configfs_bin_file_operations = {* @attr: atrribute descriptor. */ -int configfs_create_file (struct config_item * item,const struct configfs_attribute * attr) +int configfs_create_file (struct config_item *item, +const struct configfs_attribute *attr) {struct dentry *dir = item->ci_dentry;struct configfs_dirent *parent_sd = dir->d_fsdata;include/linux/configfs.h +2
-0@@ -216,6 +216,8 @@ struct configfs_group_operations {struct config_group *(*make_group)(struct config_group *group,const char *name);void (*disconnect_notify)(struct config_group *group,struct config_item *item);void (*drop_item)(struct config_group *group,struct config_item *item); +bool (*is_visible)(struct configfs_attribute *attr,int n); +bool (*is_bin_visible)(struct configfs_bin_attribute *attr,int n); };struct configfs_subsystem {include/linux/tsm.h +16
-7@@ -42,6 +42,19 @@ struct tsm_report {u8 *auxblob; }; +enum tsm_attr_index { +TSM_REPORT_GENERATION , +TSM_REPORT_PROVIDER , +TSM_REPORT_PRIVLEVEL , +TSM_REPORT_PRIVLEVEL_FLOOR , +}; + +enum tsm_bin_attr_index { +TSM_REPORT_INBLOB , +TSM_REPORT_OUTBLOB , +TSM_REPORT_AUXBLOB , +}; +/** * struct tsm_ops - attributes and operations for tsm instances * @name: tsm id reflected in /sys/kernel/config/tsm/report/$report/provider @@ -55,15 +68,11 @@ struct tsm_report {struct tsm_ops {const char *name;const unsigned int privlevel_floor; +bool (*is_visible)(enum tsm_attr_index index); +bool (*is_bin_visible)(enum tsm_bin_attr_index index);int (*report_new)(struct tsm_report *report,void *data); }; -extern const struct config_item_type tsm_report_default_type; - -/* publish @privlevel, @privlevel_floor, and @auxblob attributes */ -extern const struct config_item_type tsm_report_extra_type; - -int tsm_register (const struct tsm_ops *ops,void *priv, -const struct config_item_type *type); +int tsm_register (const struct tsm_ops *ops,void *priv);int tsm_unregister (const struct tsm_ops *ops);#endif /* __TSM_H */
Re: [PATCH v3 12/14] fs/configfs: Add a callback to determine attribute visibility
Quoted 64 lines · Tom Lendacky
Quoted 48 lines · Dan Williams
Quoted 5 lines · Tom Lendacky
Quoted 4 lines · Dan Williams
Quoted 3 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
[..]
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Cc Joel Becker <[email protected]>Cc Christoph Hellwig <[email protected]>Signed-off-by Tom Lendacky <[email protected]>--- fs/configfs/file.c | 7 +++ include/linux/configfs.h | 111 +++++++++++++++++++++++++++------------ 2 files changed, 84 insertions(+), 34 deletions(-)[..]
Quoted 26 lines
Quoted 13 lines
Quoted 13 lines
include/linux/configfs.h +1
-0@@ -116,35 +116,57 @@ struct configfs_attribute {const char *ca_name;struct module *ca_owner;umode_t ca_mode; +bool (*is_visible)(const struct config_item *,const struct configfs_attribute *);ssize_t (*show)(struct config_item *,char *);ssize_t (*store)(struct config_item *,const char *,size_t ); };Quoted 12 lines
include/linux/configfs.h struct configfs_attribute { · line 131
Quoted 9 lines
include/linux/configfs.h +2
-1-#define CONFIGFS_ATTR (_pfx, _name) \ +#define __CONFIGFS_ATTR (_pfx, _name, _vis) \ static struct configfs_attribute _pfx##attr_##_name = { \ .ca_name = __stringify(_name), \ .ca_mode = S_IRUGO | S_IWUSR, \ .ca_owner = THIS_MODULE, \ + .is_visible = _vis, \ .show = _pfx##_name##_show, \ .store = _pfx##_name##_store, \Shouldn't this operation live in
configfs_group_operations? That would mirror the sysfs organization, and likely saves some memory.Quoted 5 lines
I suppose it can, but then you lose the grouping of attributes within the same directory, right? A configfs group will result in moving the entries into a subdirectory, right? If we go with the group level, then we will be moving the existing TSM extra attributes and the new TSM SVSM attributes into new, separate sub-directories.
Quoted 6 lines
I am not following the concern about "losing the grouping"? Here is what I was thinking with having the visibility routines in group operations. This is just the broard strokes, it compiles, but still needs the finer detail work to make tdx-guest skip all the attributes that do not apply to it. Might need to be broken up a bit more, but hopefully conveys the idea. Does this address your grouping concern?
Yes and no. Basically the is_visible()/is_bin_visible() callback will have to check every index value for a "group" against the passed in value. I was trying to group the values together using an enum in order to make it a bit easier and more readable in the callback. Adding another attribute to the group requires updates in multiple places. But thats just how I was looking at it. I can also see where you might want to selectively hide/show entries and this method works well for that.
Quoted 2 lines
I'll follow this approach (add you as Co-developed-by: or Suggested-by:, whichever you prefer) and submit a v4.
Sure, you can add:
...if you want to reuse any of this sample patch.
PATCH v3 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 | 14 ++++++++++---- include/linux/cc_platform.h | 8 ++++++++ 3 files changed, 22 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 +10 -4
@@ -64,6 +64,12 @@ static struct tsm_report_state *to_state(struct tsm_report *report) return container_of(report, struct tsm_report_state, report); } +static bool provider_visibility (const struct config_item *item, +const struct configfs_attribute *attr) +{ +return cc_platform_has (CC_ATTR_GUEST_SVSM_PRESENT ); +} +static int try_advance_write_generation (struct tsm_report *report) {struct tsm_report_state *state =to_state (report);
@@ -144,7 +150,7 @@ static ssize_t tsm_report_service_provider_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_WO (tsm_report_, service_provider); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_provider, provider_visibility);static ssize_t tsm_report_service_guid_store (struct config_item *cfg,const char *buf,size_t len)
@@ -165,7 +171,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_WO (tsm_report_, service_guid); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_guid, provider_visibility);static ssize_t tsm_report_service_manifest_version_store (struct config_item *cfg,const char *buf,size_t len)
@@ -186,7 +192,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfgreturn len; } -CONFIGFS_ATTR_WO (tsm_report_, service_manifest_version); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_manifest_version, provider_visibility);static ssize_t tsm_report_inblob_write (struct config_item *cfg,const void *buf,size_t count)
@@ -333,7 +339,7 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,return tsm_report_read (report, buf, count,TSM_MANIFEST ); } -CONFIGFS_BIN_ATTR_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX ); +CONFIGFS_BIN_ATTR_VISIBLE_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX , provider_visibility);#define TSM_DEFAULT_ATTRS () \ &tsm_report_attr_generation, \
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 v3 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 | 14 ++++++++++---- include/linux/cc_platform.h | 8 ++++++++ 3 files changed, 22 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 72
Quoted 9 lines
drivers/virt/coco/tsm.c +6
-0@@ -64,6 +64,12 @@ static struct tsm_report_state *to_state(struct tsm_report *report) return container_of(report, struct tsm_report_state, report); } +static bool provider_visibility (const struct config_item *item, +const struct configfs_attribute *attr) +{ +return cc_platform_has (CC_ATTR_GUEST_SVSM_PRESENT ); +} +
Any comment about the following query? I think introducing a CC flag for this use case is over kill.
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);@@ -144,7 +150,7 @@ static ssize_t tsm_report_service_provider_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_WO (tsm_report_, service_provider); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_provider, provider_visibility);static ssize_t tsm_report_service_guid_store (struct config_item *cfg,const char *buf,size_t len)@@ -165,7 +171,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_WO (tsm_report_, service_guid); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_guid, provider_visibility);static ssize_t tsm_report_service_manifest_version_store (struct config_item *cfg,const char *buf,size_t len)@@ -186,7 +192,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfgreturn len; } -CONFIGFS_ATTR_WO (tsm_report_, service_manifest_version); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_manifest_version, provider_visibility);static ssize_t tsm_report_inblob_write (struct config_item *cfg,const void *buf,size_t count)@@ -333,7 +339,7 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,return tsm_report_read (report, buf, count,TSM_MANIFEST ); } -CONFIGFS_BIN_ATTR_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX ); +CONFIGFS_BIN_ATTR_VISIBLE_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX , provider_visibility);#define TSM_DEFAULT_ATTRS () \ &tsm_report_attr_generation, \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 v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
Quoted 55 lines · Kuppuswamy Sathyanarayanan
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 | 14 ++++++++++---- include/linux/cc_platform.h | 8 ++++++++ 3 files changed, 22 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
-0drivers/virt/coco/tsm.c static struct tsm_report_state *to_state(struct tsm_report *report) · line 72
Quoted 9 lines
drivers/virt/coco/tsm.c +6
-0@@ -64,6 +64,12 @@ static struct tsm_report_state *to_state(struct tsm_report *report) return container_of(report, struct tsm_report_state, report); } +static bool provider_visibility (const struct config_item *item, +const struct configfs_attribute *attr) +{ +return cc_platform_has (CC_ATTR_GUEST_SVSM_PRESENT ); +} +Any comment about the following query? I think introducing a CC flag for this use case is over kill.
Quoted 1 line
If you don't think TDX will be able to make use of the SVSM attribute I can look at adding a callback. But I was waiting to see if anyone else had comments, for or against, before re-doing it all.
Thanks,
Tom
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);@@ -144,7 +150,7 @@ static ssize_t tsm_report_service_provider_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_WO (tsm_report_, service_provider); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_provider, provider_visibility);static ssize_t tsm_report_service_guid_store (struct config_item *cfg,const char *buf,size_t len)@@ -165,7 +171,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_WO (tsm_report_, service_guid); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_guid, provider_visibility);static ssize_t tsm_report_service_manifest_version_store (struct config_item *cfg,const char *buf,size_t len)@@ -186,7 +192,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfgreturn len; } -CONFIGFS_ATTR_WO (tsm_report_, service_manifest_version); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_manifest_version, provider_visibility);static ssize_t tsm_report_inblob_write (struct config_item *cfg,const void *buf,size_t count)@@ -333,7 +339,7 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,return tsm_report_read (report, buf, count,TSM_MANIFEST ); } -CONFIGFS_BIN_ATTR_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX ); +CONFIGFS_BIN_ATTR_VISIBLE_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX , provider_visibility);#define TSM_DEFAULT_ATTRS () \ &tsm_report_attr_generation, \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 v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
Quoted 17 lines · Tom Lendacky
Quoted 16 lines · Kuppuswamy Sathyanarayanan
Quoted 13 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 | 14 ++++++++++---- include/linux/cc_platform.h | 8 ++++++++ 3 files changed, 22 insertions(+), 4 deletions(-)
Quoted 7 lines
Quoted 4 lines
Any comment about the following query? I think introducing a CC flag for this use case is over kill.
If you don't think TDX will be able to make use of the SVSM attribute I can look at adding a callback. But I was waiting to see if anyone else had comments, for or against, before re-doing it all.
What about something like this (applied on top of patch 13):
arch/x86/coco/core.c +0 -4
@@ -12,7 +12,6 @@#include <asm/coco.h> #include <asm/processor.h> -#include <asm/sev.h> enum cc_vendor cc_vendor__ro_after_init =CC_VENDOR_NONE ;u64 cc_mask__ro_after_init ;
@@ -79,9 +78,6 @@ static bool noinstr amd_cc_platform_has(enum cc_attr attr)case CC_ATTR_GUEST_STATE_ENCRYPT :return sev_status &MSR_AMD64_SEV_ES_ENABLED ; -case CC_ATTR_GUEST_SVSM_PRESENT : -return snp_get_vmpl (); -/* * With SEV, the rep string I/O instructions need to be unrolled * but SEV-ES supports them through the #VC handler.
drivers/virt/coco/sev-guest/sev-guest.c +13 -1
@@ -1036,6 +1036,17 @@ static int sev_report_new(struct tsm_report *report, void *data)return 0 ; } +static bool sev_tsm_visibility (enum tsm_type type) +{ +/* Check for SVSM-related attributes */ +switch (type) { +case TSM_TYPE_SERVICE_PROVIDER : +return snp_get_vmpl (); +default : +return false; + } +} +static struct tsm_ops sev_tsm_ops = { .name =KBUILD_MODNAME , .report_new = sev_report_new,
@@ -1126,7 +1137,8 @@ static int __init sev_guest_probe(struct platform_device *pdev)/* Set the privlevel_floor attribute based on the current VMPL */ sev_tsm_ops.privlevel_floor =snp_get_vmpl (); - ret =tsm_register (&sev_tsm_ops, snp_dev, &tsm_report_extra_type); + ret =tsm_register (&sev_tsm_ops, snp_dev, &tsm_report_extra_type, + sev_tsm_visibility);if (ret) goto e_free_cert_data;
drivers/virt/coco/tdx-guest/tdx-guest.c +1 -1
@@ -301,7 +301,7 @@ static int __init tdx_guest_init(void) goto free_misc; } - ret =tsm_register (&tdx_tsm_ops,NULL ,NULL ); + ret =tsm_register (&tdx_tsm_ops,NULL ,NULL ,NULL );if (ret) goto free_quote;
drivers/virt/coco/tsm.c +16 -8
@@ -16,6 +16,7 @@ static struct tsm_provider {const struct tsm_ops *ops;const struct config_item_type *type;void *data; +tsm_visibility_t visibility; } provider;static DECLARE_RWSEM (tsm_rwsem);
@@ -64,10 +65,13 @@ static struct tsm_report_state *to_state(struct tsm_report *report) return container_of(report, struct tsm_report_state, report); } -static bool provider_visibility (const struct config_item *item, -const struct configfs_attribute *attr) +static bool service_provider_visibility (const struct config_item *item, +const struct configfs_attribute *attr) { -return cc_platform_has (CC_ATTR_GUEST_SVSM_PRESENT ); +if (!provider.visibility) +return true; + +return provider.visibility (TSM_TYPE_SERVICE_PROVIDER ); }static int try_advance_write_generation (struct tsm_report *report)
@@ -150,7 +154,7 @@ static ssize_t tsm_report_service_provider_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_provider, provider_visibility); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_provider, service_provider_visibility);static ssize_t tsm_report_service_guid_store (struct config_item *cfg,const char *buf,size_t len)
@@ -171,7 +175,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_guid, provider_visibility); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_guid, service_provider_visibility);static ssize_t tsm_report_service_manifest_version_store (struct config_item *cfg,const char *buf,size_t len)
@@ -192,7 +196,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfgreturn len; } -CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_manifest_version, provider_visibility); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_manifest_version, service_provider_visibility);static ssize_t tsm_report_inblob_write (struct config_item *cfg,const void *buf,size_t count)
@@ -339,7 +343,8 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,return tsm_report_read (report, buf, count,TSM_MANIFEST ); } -CONFIGFS_BIN_ATTR_VISIBLE_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX , provider_visibility); +CONFIGFS_BIN_ATTR_VISIBLE_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX , + service_provider_visibility);#define TSM_DEFAULT_ATTRS () \ &tsm_report_attr_generation, \
@@ -449,7 +454,8 @@ static struct configfs_subsystem tsm_configfs = { };int tsm_register (const struct tsm_ops *ops,void *priv, -const struct config_item_type *type) +const struct config_item_type *type, +tsm_visibility_t visibility) {const struct tsm_ops *conflict;
@@ -468,6 +474,7 @@ int tsm_register(const struct tsm_ops *ops, void *priv, provider.ops = ops; provider.data = priv; provider.type = type; + provider.visibility = visibility;return 0 ; }EXPORT_SYMBOL_GPL (tsm_register);
@@ -480,6 +487,7 @@ int tsm_unregister(const struct tsm_ops *ops) provider.ops =NULL ; provider.data =NULL ; provider.type =NULL ; + provider.visibility =NULL ;return 0 ; }EXPORT_SYMBOL_GPL (tsm_unregister);
include/linux/cc_platform.h +0 -8
@@ -90,14 +90,6 @@ enum cc_attr {* Examples include TDX Guest. */ CC_ATTR_HOTPLUG_DISABLED, - -/** -* @CC_ATTR_GUEST_SVSM_PRESENT: Guest is running under an SVSM -* -* The platform/OS is running as a guest/virtual machine and is -* running under a Secure VM Service Module (SVSM). -*/ - CC_ATTR_GUEST_SVSM_PRESENT, };#ifdef CONFIG_ARCH_HAS_CC_PLATFORM
include/linux/tsm.h +14 -1
@@ -74,7 +74,20 @@ extern const struct config_item_type tsm_report_default_type;/* publish @privlevel, @privlevel_floor, and @auxblob attributes */ extern const struct config_item_type tsm_report_extra_type; +/* +* Used to indicate the attribute group type to the visibility callback to +* avoid the callback having to examine the attribute name. +*/ +enum tsm_type { +TSM_TYPE_SERVICE_PROVIDER , + +TSM_TYPE_MAX +}; + +typedef bool (*tsm_visibility_t )(enum tsm_type type); +int tsm_register (const struct tsm_ops *ops,void *priv, -const struct config_item_type *type); +const struct config_item_type *type, +tsm_visibility_t visibility);int tsm_unregister (const struct tsm_ops *ops);#endif /* __TSM_H */
Quoted 3 lines
Thanks,
Tom
Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
Hi,
Quoted 213 lines · Tom Lendacky
Quoted 17 lines · Tom Lendacky
Quoted 16 lines · Kuppuswamy Sathyanarayanan
Quoted 13 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 | 14 ++++++++++----
include/linux/cc_platform.h| 8 ++++++++3 files changed, 22 insertions(+), 4 deletions(-)Quoted 7 lines
Quoted 4 lines
Any comment about the following query? I think introducing a CC flag for this use case is over kill.
If you don't think TDX will be able to make use of the SVSM attribute I can look at adding a callback. But I was waiting to see if anyone else had comments, for or against, before re-doing it all.
What about something like this (applied on top of patch 13):
arch/x86/coco/core.c +0
-0@@ -12,7 +12,6 @@
#include <asm/coco.h>
#include <asm/processor.h>
-#include <asm/sev.h>
enumcc_vendorcc_vendor__ro_after_init=CC_VENDOR_NONE; u64cc_mask__ro_after_init;arch/x86/coco/core.c +0
-0@@ -79,9 +78,6 @@ 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/sev-guest/sev-guest.c +0
-0@@ -1036,6 +1036,17 @@ static int sev_report_new(struct tsm_report *report, void *data) return 0; }drivers/virt/coco/sev-guest/sev-guest.c +11
-0+static bool sev_tsm_visibility (enum tsm_type type) +{ + /* Check for SVSM-related attributes */ + switch (type) { + case TSM_TYPE_SERVICE_PROVIDER: + return snp_get_vmpl(); + default: + return false; + } +} +static struct
tsm_opssev_tsm_ops= {
.name =KBUILD_MODNAME,
.report_new =sev_report_new,drivers/virt/coco/sev-guest/sev-guest.c +0
-0@@ -1126,7 +1137,8 @@ static int __init sev_guest_probe(struct platform_device *pdev) /* Set the privlevel_floor attribute based on the current VMPL */ sev_tsm_ops.privlevel_floor = snp_get_vmpl();
- ret =tsm_register(&sev_tsm_ops, snp_dev, &tsm_report_extra_type); + ret =tsm_register(&sev_tsm_ops, snp_dev, &tsm_report_extra_type, + sev_tsm_visibility);
if (ret)
gotoe_free_cert_data;drivers/virt/coco/tdx-guest/tdx-guest.c +0
-0@@ -301,7 +301,7 @@ static int __init tdx_guest_init(void) goto free_misc; }
- ret =tsm_register(&tdx_tsm_ops, NULL, NULL); + ret =tsm_register(&tdx_tsm_ops, NULL, NULL, NULL); if (ret)
gotofree_quote;drivers/virt/coco/tsm.c +1
-0@@ -16,6 +16,7 @@ static struct tsm_provider { const struct tsm_ops *ops; const struct config_item_type *type; void *data; + tsm_visibility_t visibility; } provider; static DECLARE_RWSEM(tsm_rwsem);drivers/virt/coco/tsm.c +0
-0@@ -64,10 +65,13 @@ static struct tsm_report_state *to_state(struct tsm_report *report) return container_of(report, struct tsm_report_state, report); }drivers/virt/coco/tsm.c +2
-2-static bool provider_visibility (const struct config_item *item, - const struct configfs_attribute *attr) +static bool service_provider_visibility (const struct config_item *item, + const struct configfs_attribute *attr){
- returncc_platform_has(CC_ATTR_GUEST_SVSM_PRESENT); + if (!provider.visibility)
+ return true;
+
+ returnprovider.visibility(TSM_TYPE_SERVICE_PROVIDER); }
static inttry_advance_write_generation(struct tsm_report *report)drivers/virt/coco/tsm.c +0
-0@@ -150,7 +154,7 @@ static ssize_t tsm_report_service_provider_store(struct config_item *cfg,
return len;
}drivers/virt/coco/tsm.c +1
-1-CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_provider, provider_visibility); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_provider, service_provider_visibility);
staticssize_ttsm_report_service_guid_store(struct config_item *cfg, const char *buf, size_t len)drivers/virt/coco/tsm.c +0
-0@@ -171,7 +175,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
return len;
}drivers/virt/coco/tsm.c +1
-1-CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_guid, provider_visibility); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_guid, service_provider_visibility);
staticssize_ttsm_report_service_manifest_version_store(struct config_item *cfg, const char *buf, size_t len)drivers/virt/coco/tsm.c +0
-0@@ -192,7 +196,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg
return len;
}drivers/virt/coco/tsm.c +1
-1-CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_manifest_version, provider_visibility); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_manifest_version, service_provider_visibility);
staticssize_ttsm_report_inblob_write(struct config_item *cfg, const void *buf, size_t count)drivers/virt/coco/tsm.c +0
-0@@ -339,7 +343,8 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,
returntsm_report_read(report, buf, count, TSM_MANIFEST); }drivers/virt/coco/tsm.c +2
-1-CONFIGFS_BIN_ATTR_VISIBLE_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX , provider_visibility); +CONFIGFS_BIN_ATTR_VISIBLE_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX , + service_provider_visibility);
#defineTSM_DEFAULT_ATTRS()\
&tsm_report_attr_generation, \drivers/virt/coco/tsm.c +0
-0@@ -449,7 +454,8 @@ static struct configfs_subsystem tsm_configfs = { };
inttsm_register(const struct tsm_ops *ops, void *priv, - const struct config_item_type *type)+ const structconfig_item_type*type, +tsm_visibility_tvisibility)
{
const structtsm_ops*conflict;drivers/virt/coco/tsm.c +2
-0@@ -468,6 +474,7 @@ int tsm_register(const struct tsm_ops *ops, void *priv, provider.ops = ops; provider.data = priv; provider.type = type; + provider.visibility = visibility; return 0; } EXPORT_SYMBOL_GPL(tsm_register);@@ -480,6 +487,7 @@ int tsm_unregister(const struct tsm_ops *ops) provider.ops = NULL; provider.data = NULL; provider.type = NULL; + provider.visibility = NULL; return 0; } EXPORT_SYMBOL_GPL(tsm_unregister);include/linux/cc_platform.h +0
-8@@ -90,14 +90,6 @@ enum cc_attr {* Examples include TDX Guest. */ CC_ATTR_HOTPLUG_DISABLED, - - /** - * @CC_ATTR_GUEST_SVSM_PRESENT: Guest is running under an SVSM - * - * The platform/OS is running as a guest/virtual machine and is - * running under a Secure VM Service Module (SVSM). - */ - CC_ATTR_GUEST_SVSM_PRESENT, };
#ifdefCONFIG_ARCH_HAS_CC_PLATFORMinclude/linux/tsm.h +0
-0@@ -74,7 +74,20 @@ extern const struct config_item_type tsm_report_default_type; /* publish @privlevel, @privlevel_floor, and @auxblob attributes */ extern const struct config_item_type tsm_report_extra_type;
Quoted 4 lines
+/*
+ * Used to indicate the attribute group type to the visibility callback to
+ * avoid the callback having to examine the attribute name.
Checking the attribute name will give more flexibility, right? Since it is one time check, it should not be costly, right?
Quoted 8 lines
include/linux/tsm.h +8
-0+enum tsm_type { + TSM_TYPE_SERVICE_PROVIDER, + + TSM_TYPE_MAX +}; + +typedef bool (*tsm_visibility_t )(enum tsm_type type); +
Quoted 7 lines
int
tsm_register(const struct tsm_ops *ops, void *priv, - const struct config_item_type *type); + const structconfig_item_type*type, +tsm_visibility_tvisibility);
inttsm_unregister(const struct tsm_ops *ops); #endif /*__TSM_H*/
Why not add a callback in tsm_ops?
Quoted 3 lines
Quoted 3 lines
Thanks,
Tom
Signature · 2 lines
Sathyanarayanan Kuppuswamy Linux Kernel Developer
Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
Quoted 40 lines · Kuppuswamy Sathyanarayanan
Hi,
Quoted 37 lines · Tom Lendacky
Quoted 17 lines · Tom Lendacky
Quoted 16 lines · Kuppuswamy Sathyanarayanan
Quoted 13 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 | 14 ++++++++++---- include/linux/cc_platform.h | 8 ++++++++ 3 files changed, 22 insertions(+), 4 deletions(-)Quoted 7 lines
Quoted 4 lines
Any comment about the following query? I think introducing a CC flag for this use case is over kill.
If you don't think TDX will be able to make use of the SVSM attribute I can look at adding a callback. But I was waiting to see if anyone else had comments, for or against, before re-doing it all.
What about something like this (applied on top of patch 13):
include/linux/tsm.h +0
-0@@ -74,7 +74,20 @@ extern const struct config_item_type tsm_report_default_type; /* publish @privlevel, @privlevel_floor, and @auxblob attributes */ extern const struct config_item_type tsm_report_extra_type;
Quoted 6 lines
include/linux/tsm.h extern const struct config_item_type tsm_report_default_type; · line 79
Quoted 3 lines
include/linux/tsm.h +3
-0+/* +* Used to indicate the attribute group type to the visibility callback to +* avoid the callback having to examine the attribute name. Checking the attribute name will give more flexibility, right? Since it is one time check, it should not be costly, right?
I thought about checking the name(s), but what if in the future another attribute is added, then you have to remember to update multiple places. This way you have an enum that represents the related attributes. Is there a scenario where you would want to not hide all attributes that are related? String comparisons just seem awkward to me.
I suppose the config_item and configfs_attr could also be supplied on the callback if that's a requirement.
Quoted 10 lines
Quoted 10 lines
include/linux/tsm.h +8
-0+enum tsm_type { + TSM_TYPE_SERVICE_PROVIDER, + + TSM_TYPE_MAX +}; + +typedef bool (*tsm_visibility_t )(enum tsm_type type); + int tsm_register(const struct tsm_ops *ops, void *priv,
Quoted 8 lines
include/linux/tsm.h extern const struct config_item_type tsm_report_default_type; · line 93
Quoted 6 lines
include/linux/tsm.h +2
-1- const struct config_item_type *type); + const struct config_item_type *type, + tsm_visibility_t visibility); int tsm_unregister(const struct tsm_ops *ops); #endif /* __TSM_H */Why not add a callback in
tsm_ops?
That's an option, too. Either way works for me.
Thanks,
Tom
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Thanks,
Tom
Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
Quoted 47 lines · Tom Lendacky
Quoted 32 lines · Kuppuswamy Sathyanarayanan
Hi,
Quoted 28 lines · Tom Lendacky
Quoted 17 lines · Tom Lendacky
Quoted 16 lines · Kuppuswamy Sathyanarayanan
Quoted 13 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 | 14 ++++++++++----include/linux/cc_platform.h| 8 ++++++++3 files changed, 22 insertions(+), 4 deletions(-)Quoted 7 lines
Quoted 4 lines
Any comment about the following query? I think introducing a CC flag for this use case is over kill.
If you don't think TDX will be able to make use of the SVSM attribute I can look at adding a callback. But I was waiting to see if anyone else had comments, for or against, before re-doing it all.
What about something like this (applied on top of patch 13):
Quoted 13 lines
Quoted 10 lines
include/linux/tsm.h +0
-0@@ -74,7 +74,20 @@ extern const struct config_item_type tsm_report_default_type; /* publish @privlevel, @privlevel_floor, and @auxblob attributes */ extern const struct config_item_type tsm_report_extra_type;+/*
+ * Used to indicate the attribute group type to the visibility callback to
+ * avoid the callback having to examine the attribute name.Checking the attribute name will give more flexibility, right? Since it is one time check, it should not be costly, right?
Quoted 1 line
I thought about checking the name(s), but what if in the future another attribute is added, then you have to remember to update multiple places. This way you have an enum that represents the related attributes. Is there a
I think it depends on how you implement the visibility function. If the vendor driver allows all attributes by default and denies few selected ones, you don't have to update the vendor driver for all new attributes. Letting the vendor driver decide whether to support any new attributes makes sense to me.
Quoted 3 lines
scenario where you would want to not hide all attributes that are related? String comparisons just seem awkward to me.
I suppose the
config_itemandconfigfs_attrcould also be supplied on the callback if that's a requirement.
I am ok with enum based checks. But lets see what others think. Personally I think checking config attr name is more flexible.
Quoted 30 lines
Quoted 11 lines
Quoted 11 lines
include/linux/tsm.h +8
-0+enum tsm_type { + TSM_TYPE_SERVICE_PROVIDER, + + TSM_TYPE_MAX +}; + +typedef bool (*tsm_visibility_t )(enum tsm_type type); +int tsm_register(const struct
tsm_ops*ops, void *priv,Quoted 8 lines
Quoted 6 lines
- const struct
config_item_type*type);
+ const structconfig_item_type*type,
+tsm_visibility_tvisibility);
inttsm_unregister(const struct tsm_ops *ops);
#endif /*__TSM_H*/Why not add a callback in
tsm_ops?That's an option, too. Either way works for me.
Thanks,
TomQuoted 4 lines
Quoted 4 lines
Quoted 4 lines
Thanks,
Tom
Signature · 2 lines
Sathyanarayanan Kuppuswamy Linux Kernel Developer
Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
Quoted 51 lines · Kuppuswamy Sathyanarayanan
Quoted 47 lines · Tom Lendacky
Quoted 32 lines · Kuppuswamy Sathyanarayanan
Hi,
Quoted 28 lines · Tom Lendacky
Quoted 17 lines · Tom Lendacky
Quoted 16 lines · Kuppuswamy Sathyanarayanan
Quoted 13 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 | 14 ++++++++++---- include/linux/cc_platform.h | 8 ++++++++ 3 files changed, 22 insertions(+), 4 deletions(-)Quoted 7 lines
Quoted 4 lines
Any comment about the following query? I think introducing a CC flag for this use case is over kill.
If you don't think TDX will be able to make use of the SVSM attribute I can look at adding a callback. But I was waiting to see if anyone else had comments, for or against, before re-doing it all.
What about something like this (applied on top of patch 13):
Quoted 13 lines
include/linux/tsm.h extern const struct config_item_type tsm_report_default_type; · line 78
Quoted 10 lines
include/linux/tsm.h +2
-0@@ -74,7 +74,20 @@ extern const struct config_item_type tsm_report_default_type; /* publish @privlevel, @privlevel_floor, and @auxblob attributes */ extern const struct config_item_type tsm_report_extra_type; +/* +* Used to indicate the attribute group type to the visibility callback to +* avoid the callback having to examine the attribute name. Checking the attribute name will give more flexibility, right? Since it is one time check, it should not be costly, right?
Quoted 1 line
I thought about checking the name(s), but what if in the future another attribute is added, then you have to remember to update multiple places. This way you have an enum that represents the related attributes. Is there a
Quoted 8 lines
I think it depends on how you implement the visibility function. If the vendor driver allows all attributes by default and denies few selected ones, you don't have to update the vendor driver for all new attributes. Letting the vendor driver decide whether to support any new attributes makes sense to me.
Quoted 3 lines
scenario where you would want to not hide all attributes that are related? String comparisons just seem awkward to me.
I suppose the
config_itemandconfigfs_attrcould also be supplied on the callback if that's a requirement.I am ok with enum based checks. But lets see what others think. Personally I think checking config attr name is more flexible.
I think we can do both. Supply the enum, config_item and configfs_attr and then the callback can decide using the enum and/or the attribute name.
It could be extended to the current extra attributes, too. The enum could have a TSM_TYPE_EXTRA (for the privlevel, privlevel_floor and auxblob) and allow those to be hidden as appropriate, too.
Thanks,
Tom
Quoted 32 lines
Quoted 32 lines
Quoted 13 lines
Quoted 13 lines
include/linux/tsm.h +8
-0+enum tsm_type { + TSM_TYPE_SERVICE_PROVIDER, + + TSM_TYPE_MAX +}; + +typedef bool (*tsm_visibility_t )(enum tsm_type type); + int tsm_register(const struct tsm_ops *ops, void *priv,Quoted 8 lines
include/linux/tsm.h extern const struct config_item_type tsm_report_default_type; · line 93
Quoted 6 lines
include/linux/tsm.h +2
-1- const struct config_item_type *type); + const struct config_item_type *type, + tsm_visibility_t visibility); int tsm_unregister(const struct tsm_ops *ops); #endif /* __TSM_H */Why not add a callback in
tsm_ops?That's an option, too. Either way works for me.
Thanks,
TomQuoted 4 lines
Quoted 4 lines
Quoted 4 lines
Thanks,
Tom
Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
Quoted 59 lines · Tom Lendacky
Quoted 58 lines · Kuppuswamy Sathyanarayanan
Quoted 47 lines · Tom Lendacky
Quoted 32 lines · Kuppuswamy Sathyanarayanan
Hi,
Quoted 28 lines · Tom Lendacky
Quoted 17 lines · Tom Lendacky
Quoted 16 lines · Kuppuswamy Sathyanarayanan
Quoted 13 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 | 14 ++++++++++---- include/linux/cc_platform.h | 8 ++++++++ 3 files changed, 22 insertions(+), 4 deletions(-)Quoted 7 lines
Quoted 4 lines
Any comment about the following query? I think introducing a CC flag for this use case is over kill.
If you don't think TDX will be able to make use of the SVSM attribute I can look at adding a callback. But I was waiting to see if anyone else had comments, for or against, before re-doing it all.
What about something like this (applied on top of patch 13):
Quoted 13 lines
include/linux/tsm.h extern const struct config_item_type tsm_report_default_type; · line 78
Quoted 10 lines
include/linux/tsm.h +2
-0@@ -74,7 +74,20 @@ extern const struct config_item_type tsm_report_default_type; /* publish @privlevel, @privlevel_floor, and @auxblob attributes */ extern const struct config_item_type tsm_report_extra_type; +/* +* Used to indicate the attribute group type to the visibility callback to +* avoid the callback having to examine the attribute name. Checking the attribute name will give more flexibility, right? Since it is one time check, it should not be costly, right?
Quoted 1 line
I thought about checking the name(s), but what if in the future another attribute is added, then you have to remember to update multiple places. This way you have an enum that represents the related attributes. Is there a
I think it depends on how you implement the visibility function. If the vendor driver allows all attributes by default and denies few selected ones, you don't have to update the vendor driver for all new attributes. Letting the vendor driver decide whether to support any new attributes makes sense to me.
Quoted 3 lines
scenario where you would want to not hide all attributes that are related? String comparisons just seem awkward to me.
I suppose the
config_itemandconfigfs_attrcould also be supplied on the callback if that's a requirement.
Quoted 9 lines
Quoted 1 line
I am ok with enum based checks. But lets see what others think. Personally I think checking config attr name is more flexible.
I think we can do both. Supply the enum,
config_itemandconfigfs_attrand then the callback can decide using the enum and/or the attribute name.It could be extended to the current extra attributes, too. The enum could have a
TSM_TYPE_EXTRA(for the privlevel,privlevel_floorand auxblob) and allow those to be hidden as appropriate, too.
I guess I should have read all feedback before supplying my own, but looks like you arrived at the same result.
Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
In reply to Tom LendackyQuoted 48 lines · Tom Lendacky
Quoted 40 lines · Kuppuswamy Sathyanarayanan
Hi,
Quoted 37 lines · Tom Lendacky
Quoted 17 lines · Tom Lendacky
Quoted 16 lines · Kuppuswamy Sathyanarayanan
Quoted 13 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 | 14 ++++++++++---- include/linux/cc_platform.h | 8 ++++++++ 3 files changed, 22 insertions(+), 4 deletions(-)Quoted 7 lines
Quoted 4 lines
Any comment about the following query? I think introducing a CC flag for this use case is over kill.
If you don't think TDX will be able to make use of the SVSM attribute I can look at adding a callback. But I was waiting to see if anyone else had comments, for or against, before re-doing it all.
What about something like this (applied on top of patch 13):
include/linux/tsm.h +0
-0@@ -74,7 +74,20 @@ extern const struct config_item_type tsm_report_default_type; /* publish @privlevel, @privlevel_floor, and @auxblob attributes */ extern const struct config_item_type tsm_report_extra_type;Quoted 6 lines
include/linux/tsm.h extern const struct config_item_type tsm_report_default_type; · line 79
Quoted 3 lines
include/linux/tsm.h +3
-0+/* +* Used to indicate the attribute group type to the visibility callback to +* avoid the callback having to examine the attribute name. Checking the attribute name will give more flexibility, right? Since it is one time check, it should not be costly, right?
Quoted 5 lines
I thought about checking the name(s), but what if in the future another attribute is added, then you have to remember to update multiple places. This way you have an enum that represents the related attributes. Is there a scenario where you would want to not hide all attributes that are related? String comparisons just seem awkward to me.
An enum that matches an attribute index matches what sysfs offers. I.e. sysfs is_visible callbacks either do pointer comparisons, or attribute index number, but not names. So I agree with you about not using an attribute name as the key.
Using the index however does mean that providers need to assume that all attributes are in one array (and one bin_attribute array), but I think that's ok.
Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
In reply to Tom LendackyQuoted 77 lines · Tom Lendacky
Quoted 22 lines · Tom Lendacky
Quoted 21 lines · Kuppuswamy Sathyanarayanan
Quoted 5 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.Quoted 9 lines
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 | 14 ++++++++++---- include/linux/cc_platform.h | 8 ++++++++ 3 files changed, 22 insertions(+), 4 deletions(-)Any comment about the following query? I think introducing a CC flag for this use
case is over kill.Quoted 6 lines
Quoted 1 line
If you don't think TDX will be able to make use of the SVSM attribute I can look at adding a callback. But I was waiting to see if anyone else had comments, for or against, before re-doing it all.
What about something like this (applied on top of patch 13):
arch/x86/coco/core.c +0
-4@@ -12,7 +12,6 @@#include <asm/coco.h> #include <asm/processor.h> -#include <asm/sev.h> enum cc_vendor cc_vendor__ro_after_init =CC_VENDOR_NONE ;u64 cc_mask__ro_after_init ;@@ -79,9 +78,6 @@ static bool noinstr amd_cc_platform_has(enum cc_attr attr)case CC_ATTR_GUEST_STATE_ENCRYPT :return sev_status &MSR_AMD64_SEV_ES_ENABLED ; -case CC_ATTR_GUEST_SVSM_PRESENT : -return snp_get_vmpl (); -/* * With SEV, the rep string I/O instructions need to be unrolled * but SEV-ES supports them through the #VC handler. drivers/virt/coco/sev-guest/sev-guest.c +11
-0@@ -1036,6 +1036,17 @@ static int sev_report_new(struct tsm_report *report, void *data)return 0 ; } +static bool sev_tsm_visibility (enum tsm_type type) +{ +/* Check for SVSM-related attributes */ +switch (type) { +case TSM_TYPE_SERVICE_PROVIDER : +return snp_get_vmpl (); +default : +return false; + } +} +static struct tsm_ops sev_tsm_ops = { .name =KBUILD_MODNAME , .report_new = sev_report_new,
drivers/virt/coco/sev-guest/sev-guest.c static int __init sev_guest_probe(struct platform_device *pdev) · line 1141
Quoted 6 lines
drivers/virt/coco/sev-guest/sev-guest.c +2
-1@@ -1126,7 +1137,8 @@ static int __init sev_guest_probe(struct platform_device *pdev)/* Set the privlevel_floor attribute based on the current VMPL */ sev_tsm_ops.privlevel_floor =snp_get_vmpl (); - ret =tsm_register (&sev_tsm_ops, snp_dev, &tsm_report_extra_type); + ret =tsm_register (&sev_tsm_ops, snp_dev, &tsm_report_extra_type, + sev_tsm_visibility);
I would have expected this in tsm_ops, but yes I think a callback lets this fixup the ugly "extra" attributes situation as well.
Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
In reply to Tom LendackyQuoted 80 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 | 14 ++++++++++---- include/linux/cc_platform.h | 8 ++++++++ 3 files changed, 22 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
-3@@ -64,6 +64,12 @@ static struct tsm_report_state *to_state(struct tsm_report *report) return container_of(report, struct tsm_report_state, report); } +static bool provider_visibility (const struct config_item *item, +const struct configfs_attribute *attr) +{ +return cc_platform_has (CC_ATTR_GUEST_SVSM_PRESENT ); +} +static int try_advance_write_generation (struct tsm_report *report) {struct tsm_report_state *state =to_state (report);@@ -144,7 +150,7 @@ static ssize_t tsm_report_service_provider_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_WO (tsm_report_, service_provider); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_provider, provider_visibility);static ssize_t tsm_report_service_guid_store (struct config_item *cfg,const char *buf,size_t len)@@ -165,7 +171,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_WO (tsm_report_, service_guid); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_guid, provider_visibility);static ssize_t tsm_report_service_manifest_version_store (struct config_item *cfg,const char *buf,size_t len)@@ -186,7 +192,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfgreturn len; } -CONFIGFS_ATTR_WO (tsm_report_, service_manifest_version); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_manifest_version, provider_visibility);static ssize_t tsm_report_inblob_write (struct config_item *cfg,const void *buf,size_t count)
drivers/virt/coco/tsm.c static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf, · line 342
Quoted 5 lines
drivers/virt/coco/tsm.c +1
-1@@ -333,7 +339,7 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,return tsm_report_read (report, buf, count,TSM_MANIFEST ); } -CONFIGFS_BIN_ATTR_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX ); +CONFIGFS_BIN_ATTR_VISIBLE_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX , provider_visibility);
Yeah the same callback specified multiple times feels like something that should only happen once at the group level.
Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
Quoted 82 lines · Dan Williams
Quoted 81 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 | 14 ++++++++++---- include/linux/cc_platform.h | 8 ++++++++ 3 files changed, 22 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
-3@@ -64,6 +64,12 @@ static struct tsm_report_state *to_state(struct tsm_report *report) return container_of(report, struct tsm_report_state, report); } +static bool provider_visibility (const struct config_item *item, +const struct configfs_attribute *attr) +{ +return cc_platform_has (CC_ATTR_GUEST_SVSM_PRESENT ); +} +static int try_advance_write_generation (struct tsm_report *report) {struct tsm_report_state *state =to_state (report);@@ -144,7 +150,7 @@ static ssize_t tsm_report_service_provider_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_WO (tsm_report_, service_provider); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_provider, provider_visibility);static ssize_t tsm_report_service_guid_store (struct config_item *cfg,const char *buf,size_t len)@@ -165,7 +171,7 @@ static ssize_t tsm_report_service_guid_store(struct config_item *cfg,return len; } -CONFIGFS_ATTR_WO (tsm_report_, service_guid); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_guid, provider_visibility);static ssize_t tsm_report_service_manifest_version_store (struct config_item *cfg,const char *buf,size_t len)@@ -186,7 +192,7 @@ static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfgreturn len; } -CONFIGFS_ATTR_WO (tsm_report_, service_manifest_version); +CONFIGFS_ATTR_VISIBLE_WO (tsm_report_, service_manifest_version, provider_visibility);static ssize_t tsm_report_inblob_write (struct config_item *cfg,const void *buf,size_t count)@@ -333,7 +339,7 @@ static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,
Quoted 7 lines
drivers/virt/coco/tsm.c static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf, · line 342
Quoted 4 lines
drivers/virt/coco/tsm.c +1
-1return tsm_report_read (report, buf, count,TSM_MANIFEST ); } -CONFIGFS_BIN_ATTR_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX ); +CONFIGFS_BIN_ATTR_VISIBLE_RO (tsm_report_, manifestblob,NULL ,TSM_OUTBLOB_MAX , provider_visibility);Yeah the same callback specified multiple times feels like something that should only happen once at the group level.
I went with this to keep compatibility of all the attributes existing at the same level in the report sub-directory. Moving the existing extra attributes will break backwards compatibility if we want to apply visibility to them.
If we don't want to apply visibility to the existing extra attributes, then, yes, the the visibility support can be done at the group level instead of the file/attribute level.
Thoughts?
Thanks,
Tom
Quoted 1 line
Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
In reply to Tom LendackyQuoted 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 | 14 ++++++++++---- include/linux/cc_platform.h | 8 ++++++++ 3 files changed, 22 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,12 @@ static struct tsm_report_state *to_state(struct tsm_report *report) return container_of(report, struct tsm_report_state, report); } +static bool provider_visibility (const struct config_item *item, +const struct configfs_attribute *attr) +{ +return cc_platform_has (CC_ATTR_GUEST_SVSM_PRESENT ); +}
I expect this needs to be a callback into the provider ops because one of the other use cases for this visibility check is to get rid of the "extra" attributes and handle that visibility with the same mechanism.
Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
Quoted 44 lines · Dan Williams
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 | 14 ++++++++++---- include/linux/cc_platform.h | 8 ++++++++ 3 files changed, 22 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,12 @@ static struct tsm_report_state *to_state(struct tsm_report *report) return container_of(report, struct tsm_report_state, report); }
Quoted 9 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 bool provider_visibility (const struct config_item *item, +const struct configfs_attribute *attr) +{ +return cc_platform_has (CC_ATTR_GUEST_SVSM_PRESENT ); +}I expect this needs to be a callback into the provider ops because one of the other use cases for this visibility check is to get rid of the "extra" attributes and handle that visibility with the same mechanism.
Yes, worked through on the other thread.
But the "extra" attributes are likely to remain visible if we go in the group visibility direction, to provide compatibility.
Thanks,
Tom
PATCH v3 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
@@ -2366,22 +2366,36 @@ static void dump_cpuid_table(void)* sort of indicator, and there's not really any other good place to do it, * so do it here. */ -static int __init report_cpuid_table (void ) +static void __init report_cpuid_table (void ) {const struct snp_cpuid_table *cpuid_table =snp_cpuid_get_table ();if (!cpuid_table->count) -return 0 ; +return ;pr_info ("Using SNP CPUID table, %d entries present.\n" , cpuid_table->count);if (sev_cfg.debug)dump_cpuid_table (); +} + +static void __init report_vmpl_level (void ) +{ +if (!cc_platform_has (CC_ATTR_GUEST_SEV_SNP )) +return ; + +pr_info ("SNP running at VMPL%u.\n" , vmpl); +} + +static int __init report_snp_info (void ) +{ +report_vmpl_level (); +report_cpuid_table ();return 0 ; } -arch_initcall (report_cpuid_table); +arch_initcall (report_snp_info);static int __init init_sev_config (char *str) {
Signature · 1 line
2.43.2