diff options
| author | Tycho Andersen <tycho@kernel.org> | 2026-04-16 16:23:28 -0700 |
|---|---|---|
| committer | Sean Christopherson <seanjc@google.com> | 2026-05-13 09:55:54 -0700 |
| commit | d8355a92df1f016bcb2fdb0cc9fc7bd13b6588dc (patch) | |
| tree | 4863d5dc07920087a88eb4a308104bcfc1231f84 /include/linux/stackprotector.h | |
| parent | 93d1a486e1d4f05db65b36db5fe2bca3d0257bb0 (diff) | |
KVM: SEV: Don't advertise VM types that are disabled by firmware
As called out in a footnote for a recent SNP vulnerability[1], it is
possible for a specific flavor of SEV+ to be disabled by the firmware even
when the flavor is fully supported by the CPU and platform:
Applying mitigation CVE-2025-48514 will result in disabling SEV-ES when
SEV-SNP is enabled.
Restrict KVM's set of supported VM types based on the VM types that are
fully supported by firmware to avoid over-reporting what KVM can actually
support. Like KVM's handling of ASID space exhaustion, don't modify KVM's
CPUID capabilities, as the CPU/platform still supports the underlying
technology and clearing e.g. SEV_ES while advertising SEV_SNP would confuse
KVM and userspace.
Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3023.html [1]
Link: https://lore.kernel.org/all/aZyLIWtffvEnmtYh@google.com
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
[sean: rewrite changelog to provide details on why/how this can happen]
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Tested-by: Tycho Andersen (AMD) <tycho@kernel.org>
Link: https://patch.msgid.link/20260416232329.3408497-7-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'include/linux/stackprotector.h')
0 files changed, 0 insertions, 0 deletions
