summaryrefslogtreecommitdiff
path: root/include/linux
diff options
context:
space:
mode:
authorTycho Andersen (AMD) <tycho@kernel.org>2026-05-04 19:51:45 +0300
committerHerbert Xu <herbert@gondor.apana.org.au>2026-05-15 13:08:37 +0300
commit5a1364da2f04217a36e2fdfa2db4ee025b383a20 (patch)
treea5e4934b74983f77a421e2907d61b51631d6a50b /include/linux
parentfb1758e74b8061aacfbce7bbb7a7cc650537e167 (diff)
downloadlinux-5a1364da2f04217a36e2fdfa2db4ee025b383a20.tar.xz
crypto: ccp - Do not initialize SNP for ioctl(SNP_COMMIT)
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? The SNP_COMMIT command does not require the firmware to be in any particular state. Skip initializing it if it was previously uninitialized. The SEV-SNP firmware specification doc 56860 does not mention SNP_COMMIT in Table 5 as a command that is allowed in the UNINIT state, but it is in fact allowed and a future documentation update will reflect that. 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: <stable@vger.kernel.org> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'include/linux')
0 files changed, 0 insertions, 0 deletions