kernel/drivers/virt/coco/sev-guest, branch linux-rolling-stable

virt: sev-guest: Satisfy linear mapping requirement in get_derived_key()

2025-08-15T15:05:39Z

Commit 7ffeb2fc2670 ("x86/sev: Document requirement for linear mapping of guest request buffers") added a check that requires the guest request buffers to be in the linear mapping. The get_derived_key() function was passing a buffer that was allocated on the stack, resulting in the call to snp_send_guest_request() returning an error. Update the get_derived_key() function to use an allocated buffer instead of a stack buffer. Fixes: 7ffeb2fc2670 ("x86/sev: Document requirement for linear mapping of guest request buffers") Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov (AMD) Cc: Link: https://lore.kernel.org/9b764ca9fc79199a091aac684c4926e2080ca7a8.1752698495.git.thomas.lendacky@amd.com

virt: sev-guest: Contain snp_guest_request_ioctl in sev-guest

2025-06-18T20:55:30Z

SNP Guest Request uses only exitinfo2 which is a return value from GHCB, has meaning beyond ioctl and therefore belongs to struct snp_guest_req. Move exitinfo2 there and remove snp_guest_request_ioctl from the SEV platform code. No functional change intended. Signed-off-by: Alexey Kardashevskiy Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tom Lendacky Reviewed-by: Dionna Glaze Link: https://lore.kernel.org/20250611040842.2667262-2-aik@amd.com

configfs-tsm: Namespace TSM report symbols

2025-05-02T19:52:16Z

In preparation for new + common TSM (TEE Security Manager) infrastructure, namespace the TSM report symbols in tsm.h with an _REPORT suffix to differentiate them from other incoming tsm work. Cc: Yilun Xu Cc: Samuel Ortiz Cc: Tom Lendacky Cc: Sami Mujawar Cc: Steven Price Reviewed-by: Alexey Kardashevskiy Reviewed-by: Suzuki K Poulose Reviewed-by: Kai Huang Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Steven Price Link: https://patch.msgid.link/174107246021.1288555.7203769833791489618.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Dan Williams

Merge tag 'v6.14-rc7' into x86/core, to pick up fixes

2025-03-19T10:03:06Z

Signed-off-by: Ingo Molnar

virt: sev-guest: Move SNP Guest Request data pages handling under snp_cmd_mutex

2025-03-07T13:09:33Z

Compared to the SNP Guest Request, the "Extended" version adds data pages for receiving certificates. If not enough pages provided, the HV can report to the VM how much is needed so the VM can reallocate and repeat. Commit ae596615d93d ("virt: sev-guest: Reduce the scope of SNP command mutex") moved handling of the allocated/desired pages number out of scope of said mutex and create a possibility for a race (multiple instances trying to trigger Extended request in a VM) as there is just one instance of snp_msg_desc per /dev/sev-guest and no locking other than snp_cmd_mutex. Fix the issue by moving the data blob/size and the GHCB input struct (snp_req_data) into snp_guest_req which is allocated on stack now and accessed by the GHCB caller under that mutex. Stop allocating SEV_FW_BLOB_MAX_SIZE in snp_msg_alloc() as only one of four callers needs it. Free the received blob in get_ext_report() right after it is copied to the userspace. Possible future users of snp_send_guest_request() are likely to have different ideas about the buffer size anyways. Fixes: ae596615d93d ("virt: sev-guest: Reduce the scope of SNP command mutex") Signed-off-by: Alexey Kardashevskiy Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Nikunj A Dadhania Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250307013700.437505-3-aik@amd.com

virt: sev-guest: Allocate request data dynamically

2025-03-07T12:34:25Z

Commit ae596615d93d ("virt: sev-guest: Reduce the scope of SNP command mutex") narrowed the command mutex scope to snp_send_guest_request(). However, GET_REPORT, GET_DERIVED_KEY, and GET_EXT_REPORT share the req structure in snp_guest_dev. Without the mutex protection, concurrent requests can overwrite each other's data. Fix it by dynamically allocating the request structure. Fixes: ae596615d93d ("virt: sev-guest: Reduce the scope of SNP command mutex") Closes: https://github.com/AMDESE/AMDSEV/issues/265 Reported-by: andreas.stuehrk@yaxi.tech Signed-off-by: Nikunj A Dadhania Signed-off-by: Alexey Kardashevskiy Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250307013700.437505-2-aik@amd.com

x86/mm: Reduce header dependencies in

2025-02-28T16:35:22Z

Commit: 03b122da74b2 ("x86/sgx: Hook arch_memory_failure() into mainline code") ... added to to provide some helpers. However the following commit: b3fdf9398a16 ("x86/mce: relocate set{clear}_mce_nospec() functions") ... moved the inline definitions someplace else, and now just declares a bunch of mostly self-contained functions. No need for the whole inclusion to declare functions; just remove that include. This helps avoid circular dependency headaches (e.g. if ends up including ). This change requires a couple of include fixups not to break the build: * : including directly relies on having already been included, because the former needs the BAD_STACK/NOT_STACK constants defined in the latter. This is no longer the case when is included from some driver file - just include to stay out of trouble. * sev-guest.c relies on including , so we just need to make that include explicit. [ mingo: Cleaned up the changelog ] Signed-off-by: Kevin Brodsky Signed-off-by: Ingo Molnar Acked-by: David Hildenbrand Link: https://lore.kernel.org/r/20241212080904.2089632-3-kevin.brodsky@arm.com

x86/sev: Relocate SNP guest messaging routines to common code

2025-01-07T10:16:46Z

At present, the SEV guest driver exclusively handles SNP guest messaging. All routines for sending guest messages are embedded within it. To support Secure TSC, SEV-SNP guests must communicate with the AMD Security Processor during early boot. However, these guest messaging functions are not accessible during early boot since they are currently part of the guest driver. Hence, relocate the core SNP guest messaging functions to SEV common code and provide an API for sending SNP guest messages. No functional change, but just an export symbol added for snp_send_guest_request() and dropped the export symbol on snp_issue_guest_request() and made it static. Signed-off-by: Nikunj A Dadhania Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tom Lendacky Link: https://lore.kernel.org/r/20250106124633.1418972-5-nikunj@amd.com

x86/sev: Carve out and export SNP guest messaging init routines

2025-01-07T09:33:20Z

Currently, the sev-guest driver is the only user of SNP guest messaging. All routines for initializing SNP guest messaging are implemented within the sev-guest driver and are not available during early boot. In preparation for adding Secure TSC guest support, carve out APIs to allocate and initialize the guest messaging descriptor context and make it part of coco/sev/core.c. As there is no user of sev_guest_platform_data anymore, remove the structure. Signed-off-by: Nikunj A Dadhania Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tom Lendacky Link: https://lore.kernel.org/r/20250106124633.1418972-4-nikunj@amd.com

virt: sev-guest: Replace GFP_KERNEL_ACCOUNT with GFP_KERNEL

2025-01-07T09:26:20Z

Replace GFP_KERNEL_ACCOUNT with GFP_KERNEL in the sev-guest driver code. GFP_KERNEL_ACCOUNT is typically used for accounting untrusted userspace allocations. After auditing the sev-guest code, the following changes are necessary: * snp_init_crypto(): Use GFP_KERNEL as this is a trusted device probe path. Retain GFP_KERNEL_ACCOUNT in the following cases for robustness and specific path requirements: * alloc_shared_pages(): Although all allocations are limited, retain GFP_KERNEL_ACCOUNT for future robustness. * get_report() and get_ext_report(): These functions are on the unlocked ioctl path and should continue using GFP_KERNEL_ACCOUNT. Suggested-by: Borislav Petkov Signed-off-by: Nikunj A Dadhania Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20250106124633.1418972-3-nikunj@amd.com