]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD)
authorTycho Andersen (AMD) <tycho@kernel.org>
Mon, 4 May 2026 16:51:46 +0000 (10:51 -0600)
committerHerbert Xu <herbert@gondor.apana.org.au>
Fri, 15 May 2026 10:08:37 +0000 (18:08 +0800)
commitf91e9dbb5845d1e5abf1028e6df57dcf61583e1b
tree24344e7fa5837c7be624bacc034a41ad7e7788d1
parent5a1364da2f04217a36e2fdfa2db4ee025b383a20
crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD)

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 SEV firmware docs for SNP_VLEK_LOAD note:

> On SNP_SHUTDOWN, the VLEK is deleted.

That is, the initialization/shutdown wrapper here is pointless, because the
firmware immediately throws away the key anyway. Instead, refuse to do
anything if SNP has not been previously initialized.

This is an ABI break: before, this was a no-op and almost certainly a
mistake by userspace, and now it returns -ENODEV. ABI compatibility could be
maintained here by simply returning 0 in the check instead.

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>
drivers/crypto/ccp/sev-dev.c