kernel/linux.git/drivers/crypto/ccp, branch v6.12.107

crypto: ccp: Add external API interface for PSP module initialization

2026-08-23T12:22:35+00:00

[ Upstream commit 435b344a7042e91fb4719d589f18310e8919e39f ] KVM is dependent on the PSP SEV driver and PSP SEV driver needs to be loaded before KVM module. In case of module loading any dependent modules are automatically loaded but in case of built-in modules there is no inherent mechanism available to specify dependencies between modules and ensure that any dependent modules are loaded implicitly. Add a new external API interface for PSP module initialization which allows PSP SEV driver to be loaded explicitly if KVM is built-in. Signed-off-by: Sean Christopherson Co-developed-by: Ashish Kalra Signed-off-by: Ashish Kalra Reviewed-by: Tom Lendacky Message-ID: <15279ca0cad56a07cf12834ec544310f85ff5edc.1739226950.git.ashish.kalra@amd.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin

crypto: ccp - Abort doing SEV INIT if SNP INIT fails

2026-08-19T16:14:21+00:00

commit 6131e119f5799bec55535530fa2fc44f5c7be1f1 upstream. If SNP host support (SYSCFG.SNPEn) is set, then the RMP table must be initialized before calling SEV INIT. In other words, if SNP_INIT(_EX) is not issued or fails then SEV INIT will fail if SNP host support (SYSCFG.SNPEn) is enabled. Signed-off-by: Ashish Kalra Signed-off-by: Herbert Xu Signed-off-by: Jack Wang Signed-off-by: Sasha Levin

crypto: ccp - Fix checks for SNP_VLEK_LOAD input buffer length

2026-08-19T16:14:21+00:00

commit ed53a5050f42a3243a7ed8dfa49030e54034b952 upstream. The SNP_VLEK_LOAD IOCTL currently fails due to sev_cmd_buffer_len() returning the default expected buffer length of 0 instead of the correct value, which would be sizeof(struct sev_user_data_snp_vlek_load). Add specific handling for SNP_VLEK_LOAD so the correct expected size is returned. Reported-by: Diego GonzalezVillalobos Cc: Diego GonzalezVillalobos Fixes: 332d2c1d713e ("crypto: ccp: Add the SNP_VLEK_LOAD command") Signed-off-by: Michael Roth Signed-off-by: Herbert Xu [Jack: sev_cmd_buffer_len() in queue/6.12 does not yet have the SEV_CMD_SNP_FEATURE_INFO case the upstream context line matched against (it lands in a later, unrelated commit not queued here), so the new SEV_CMD_SNP_VLEK_LOAD case was placed directly after SEV_CMD_SNP_COMMIT instead. No functional difference from upstream.] Signed-off-by: Jack Wang Signed-off-by: Sasha Levin

crypto: ccp - Add new SEV/SNP platform shutdown API

2026-08-19T16:14:21+00:00

commit f7b86e0e75bc234751cb7a82d888083a57ef28b2 upstream. Add new API interface to do SEV/SNP platform shutdown when KVM module is unloaded. Reviewed-by: Dionna Glaze Reviewed-by: Tom Lendacky Signed-off-by: Ashish Kalra Signed-off-by: Herbert Xu Signed-off-by: Jack Wang Signed-off-by: Sasha Levin

crypto: ccp - Fix leaking the same page twice

2026-07-24T14:11:56+00:00

commit 5c52607c43c397b79a9852ce33fc61de58c3645c upstream. Commit 551120148b67 ("crypto: ccp - Fix a case where SNP_SHUTDOWN is missed") fixed a case where SNP is left in INIT state if page reclaim fails. It removes the transition to the INIT state for this command and adjusts the page state management. While doing this, it added a call to snp_leak_pages() after a call to snp_reclaim_pages() failed. Since snp_reclaim_pages() already calls snp_leak_pages() internally on the pages it fails to reclaim, calling it again leaks the exact same page twice. Fix by removing the extra call to snp_leak_pages(). The problem was found by an experimental code review agent based on gemini-3.1-pro while reviewing backports into v6.18.y. Assisted-by: Gemini:gemini-3.1-pro Fixes: 551120148b67 ("crypto: ccp - Fix a case where SNP_SHUTDOWN is missed") Cc: Tycho Andersen (AMD) Cc: Tom Lendacky Signed-off-by: Guenter Roeck Reviewed-by: Tom Lendacky Reviewed-by: Tycho Andersen (AMD) Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccp - Always pass in an error pointer to __sev_platform_shutdown_locked()

2026-07-24T14:11:56+00:00

commit 46834d90a9a13549264b9581067d8f746b4b36cc upstream. When 9770b428b1a2 ("crypto: ccp - Move dev_info/err messages for SEV/SNP init and shutdown") moved the error messages dumping so that they don't need to be issued by the callers, it missed the case where __sev_firmware_shutdown() calls __sev_platform_shutdown_locked() with a NULL argument which leads to a NULL ptr deref on the shutdown path, during suspend to disk: #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 983 Comm: hib.sh Not tainted 6.17.0-rc4+ #1 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-i, BIOS 2.5 09/08/2022 RIP: 0010:__sev_platform_shutdown_locked.cold+0x0/0x21 [ccp] That rIP is: 00000000000006fd <__sev_platform_shutdown_locked.cold>: 6fd: 8b 13 mov (%rbx),%edx 6ff: 48 8b 7d 00 mov 0x0(%rbp),%rdi 703: 89 c1 mov %eax,%ecx Code: 74 05 31 ff 41 89 3f 49 8b 3e 89 ea 48 c7 c6 a0 8e 54 a0 41 bf 92 ff ff ff e8 e5 2e 09 e1 c6 05 2a d4 38 00 01 e9 26 af ff ff <8b> 13 48 8b 7d 00 89 c1 48 c7 c6 18 90 54 a0 89 44 24 04 e8 c1 2e RSP: 0018:ffffc90005467d00 EFLAGS: 00010282 RAX: 00000000ffffff92 RBX: 0000000000000000 RCX: 0000000000000000 ^^^^^^^^^^^^^^^^ and %rbx is nice and clean. Call Trace: __sev_firmware_shutdown.isra.0 sev_dev_destroy psp_dev_destroy sp_destroy pci_device_shutdown device_shutdown kernel_power_off hibernate.cold state_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframe Pass in a pointer to the function-local error var in the caller. With that addressed, suspending the ccp shows the error properly at least: ccp 0000:47:00.1: sev command 0x2 timed out, disabling PSP ccp 0000:47:00.1: SEV: failed to SHUTDOWN error 0x0, rc -110 SEV-SNP: Leaking PFN range 0x146800-0x146a00 SEV-SNP: PFN 0x146800 unassigned, dumping non-zero entries in 2M PFN region: [0x146800 - 0x146a00] ... ccp 0000:47:00.1: SEV-SNP firmware shutdown failed, rc -16, error 0x0 ACPI: PM: Preparing to enter system sleep state S5 kvm: exiting hardware virtualization reboot: Power down Btw, this driver is crying to be cleaned up to pass in a proper I/O struct which can be used to store information between the different functions, otherwise stuff like that will happen in the future again. Fixes: 9770b428b1a2 ("crypto: ccp - Move dev_info/err messages for SEV/SNP init and shutdown") Signed-off-by: Borislav Petkov (AMD) Cc: Reviewed-by: Ashish Kalra Acked-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccp - Fix SNP panic notifier unregistration

2026-07-24T14:11:56+00:00

commit ab8b9fd39c45b7760093528cbef93e7353359d82 upstream. Panic notifiers are invoked with RCU read lock held and when the SNP panic notifier tries to unregister itself from the panic notifier callback itself it causes a deadlock as notifier unregistration does RCU synchronization. Code flow for SNP panic notifier: snp_shutdown_on_panic() -> __sev_firmware_shutdown() -> __sev_snp_shutdown_locked() -> atomic_notifier_chain_unregister(.., &snp_panic_notifier) Fix SNP panic notifier to unregister itself during SNP shutdown only if panic is not in progress. Reviewed-by: Tom Lendacky Cc: stable@vger.kernel.org Fixes: 19860c3274fb ("crypto: ccp - Register SNP panic notifier only if SNP is enabled") Signed-off-by: Ashish Kalra Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccp - Fix dereferencing uninitialized error pointer

2026-07-24T14:11:56+00:00

commit 0fa766726c091ff0ec7d26874f6e4724d23ecb0e upstream. Fix below smatch warnings: drivers/crypto/ccp/sev-dev.c:1312 __sev_platform_init_locked() error: we previously assumed 'error' could be null Fixes: 9770b428b1a2 ("crypto: ccp - Move dev_info/err messages for SEV/SNP init and shutdown") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202505071746.eWOx5QgC-lkp@intel.com/ Signed-off-by: Ashish Kalra Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccp - Fix __sev_snp_shutdown_locked

2026-07-24T14:11:55+00:00

commit 9af6339a65426b0b4850b07ff3b6959497bfcac5 upstream. Fix smatch warning: drivers/crypto/ccp/sev-dev.c:1755 __sev_snp_shutdown_locked() error: uninitialized symbol 'dfflush_error'. Fixes: 9770b428b1a2 ("crypto: ccp - Move dev_info/err messages for SEV/SNP init and shutdown") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-crypto/d9c2e79c-e26e-47b7-8243-ff6e7b101ec3@stanley.mountain/ Signed-off-by: Ashish Kalra Acked-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccp - Do not initialize SNP for ioctl(SNP_CONFIG)

2026-07-24T14:11:53+00:00

[ Upstream commit 08f0e65e784c4b20e6e620dd4f68d8636073a3d2 ] Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code path via /dev/sev ioctls (e.g., > SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN > execution for an active VM trigger a general protection fault and crash the > host? Refuse to re-try initialization if SNP is not already initialized for SNP_CONFIG. This is technically an ABI break: before if SNP initialization failed it could be transparently retriggered by this ioctl, and if no VMs were running, everything worked fine. Hopefully this is enough of a corner case that nobody will notice, but someone does, there are a few options: * do something like symbol_get() for kvm and refuse to initialize if KVM is loaded * check each cpu's HSAVE_PA for non-zero data before re-initializing * once initialization has failed, continue to refuse to initialize until the ccp module is unloaded Fixes: ceac7fb89e8d ("crypto: ccp - Ensure implicit SEV/SNP init and shutdown in ioctls") Reported-by: Sashiko Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kernel.org CC: Signed-off-by: Tycho Andersen (AMD) Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman