* [PATCH] KVM: nSVM: Add missing CET VMRUN consistency checks
@ 2026-11-10 0:40 Jim Mattson
2026-11-10 17:56 ` Yosry Ahmed
0 siblings, 1 reply; 5+ messages in thread
From: Jim Mattson @ 2026-11-10 0:40 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini
Cc: John Allen, Chao Gao, Yosry Ahmed, kvm, linux-kernel, Jim Mattson
Per the APM, "Canonicalization and Consistency Checks,"
[t]he following conditions are considered illegal state combinations:
- CR4.CET=1 when CR0.WP=0
- Any reserved bit set in S_CET
- CR4.CET=1 and U_CET.SS=1 when EFLAGS.VM=1
Check these conditions in software before trying to VMRUN vmcb02, so that
the illegal states result in a #VMEXIT to L1 rather than an exit to
userspace with KVM_EXIT_FAIL_ENTRY.
Fixes: c5ba49458513 ("KVM: nSVM: Save/load CET Shadow Stack state to/from vmcb12/vmcb02")
Signed-off-by: Jim Mattson <jmattson@google.com>
---
arch/x86/kvm/svm/nested.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
index af0ef678433d..20ede403b62d 100644
--- a/arch/x86/kvm/svm/nested.c
+++ b/arch/x86/kvm/svm/nested.c
@@ -469,6 +469,21 @@ static bool nested_vmcb_check_save(struct kvm_vcpu *vcpu,
if (CC(!__kvm_is_valid_cr4(vcpu, save->cr4)))
return false;
+ if (CC((save->cr4 & X86_CR4_CET) && !(save->cr0 & X86_CR0_WP)))
+ return false;
+
+ if (guest_cpu_cap_has(vcpu, X86_FEATURE_SHSTK) &&
+ CC(!kvm_is_valid_u_s_cet(vcpu, save->s_cet)))
+ return false;
+
+ if ((save->cr4 & X86_CR4_CET) && (save->rflags & X86_EFLAGS_VM)) {
+ u64 u_cet = 0;
+
+ if (!__kvm_emulate_msr_read(vcpu, MSR_IA32_U_CET, &u_cet) &&
+ CC(u_cet & CET_SHSTK_EN))
+ return false;
+ }
+
if (CC(!kvm_valid_efer(vcpu, save->efer)))
return false;
--
2.56.0.506.g506a7eabc5-goog
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] KVM: nSVM: Add missing CET VMRUN consistency checks 2026-11-10 0:40 [PATCH] KVM: nSVM: Add missing CET VMRUN consistency checks Jim Mattson @ 2026-11-10 17:56 ` Yosry Ahmed 2026-11-10 19:18 ` Jim Mattson 0 siblings, 1 reply; 5+ messages in thread From: Yosry Ahmed @ 2026-11-10 17:56 UTC (permalink / raw) To: Jim Mattson Cc: Sean Christopherson, Paolo Bonzini, John Allen, Chao Gao, kvm, linux-kernel On Mon, Nov 09, 2026 at 04:40:37PM -0800, Jim Mattson wrote: > Per the APM, "Canonicalization and Consistency Checks," > > [t]he following conditions are considered illegal state combinations: > > - CR4.CET=1 when CR0.WP=0 > - Any reserved bit set in S_CET > - CR4.CET=1 and U_CET.SS=1 when EFLAGS.VM=1 > > Check these conditions in software before trying to VMRUN vmcb02, so that > the illegal states result in a #VMEXIT to L1 rather than an exit to > userspace with KVM_EXIT_FAIL_ENTRY. > > Fixes: c5ba49458513 ("KVM: nSVM: Save/load CET Shadow Stack state to/from vmcb12/vmcb02") > Signed-off-by: Jim Mattson <jmattson@google.com> > --- > arch/x86/kvm/svm/nested.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c > index af0ef678433d..20ede403b62d 100644 > --- a/arch/x86/kvm/svm/nested.c > +++ b/arch/x86/kvm/svm/nested.c > @@ -469,6 +469,21 @@ static bool nested_vmcb_check_save(struct kvm_vcpu *vcpu, > if (CC(!__kvm_is_valid_cr4(vcpu, save->cr4))) > return false; > > + if (CC((save->cr4 & X86_CR4_CET) && !(save->cr0 & X86_CR0_WP))) > + return false; Why aren't we checking X86_FEATURE_SHSTK here as well? Do we know if older CPUs that didn't support CET had the consistency check? > + > + if (guest_cpu_cap_has(vcpu, X86_FEATURE_SHSTK) && > + CC(!kvm_is_valid_u_s_cet(vcpu, save->s_cet))) > + return false; > + > + if ((save->cr4 & X86_CR4_CET) && (save->rflags & X86_EFLAGS_VM)) { > + u64 u_cet = 0; > + > + if (!__kvm_emulate_msr_read(vcpu, MSR_IA32_U_CET, &u_cet) && If X86_FEATURE_SHSTK is not enumerated by the vCPU, then whether or not the consistency check is done depends on ignore_msr. If ignore_msr=0, the MSR read will fail and we won't do the consistency check, but if ignore_msr=1 the MSR read will silently return 0, so the consistency check will be done but will always succeed. Instead of this implicit dependency, should we check for X86_FEATURE_SHSTK explicitly? Also, if X86_FEATURE_SHSTK is enumberated by the vCPU, and the MSR read fails, the consistency check will silently be skipped. But I don't think this can/should happen. Maybe we should WARN in this case. One last question, in the restore path, the MSR may have not been restored yet, right? Can the consistency check mistakenly fail in this case? > + CC(u_cet & CET_SHSTK_EN)) > + return false; > + } > + > if (CC(!kvm_valid_efer(vcpu, save->efer))) > return false; > > -- > 2.56.0.506.g506a7eabc5-goog > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] KVM: nSVM: Add missing CET VMRUN consistency checks 2026-11-10 17:56 ` Yosry Ahmed @ 2026-11-10 19:18 ` Jim Mattson 2026-11-10 19:29 ` Yosry Ahmed 0 siblings, 1 reply; 5+ messages in thread From: Jim Mattson @ 2026-11-10 19:18 UTC (permalink / raw) To: Yosry Ahmed Cc: Sean Christopherson, Paolo Bonzini, John Allen, Chao Gao, kvm, linux-kernel On Tue, Nov 10, 2026 at 9:56 AM Yosry Ahmed <yosry@kernel.org> wrote: > > On Mon, Nov 09, 2026 at 04:40:37PM -0800, Jim Mattson wrote: > > Per the APM, "Canonicalization and Consistency Checks," > > > > [t]he following conditions are considered illegal state combinations: > > > > - CR4.CET=1 when CR0.WP=0 > > - Any reserved bit set in S_CET > > - CR4.CET=1 and U_CET.SS=1 when EFLAGS.VM=1 > > > > Check these conditions in software before trying to VMRUN vmcb02, so that > > the illegal states result in a #VMEXIT to L1 rather than an exit to > > userspace with KVM_EXIT_FAIL_ENTRY. > > > > Fixes: c5ba49458513 ("KVM: nSVM: Save/load CET Shadow Stack state to/from vmcb12/vmcb02") > > Signed-off-by: Jim Mattson <jmattson@google.com> > > --- > > arch/x86/kvm/svm/nested.c | 15 +++++++++++++++ > > 1 file changed, 15 insertions(+) > > > > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c > > index af0ef678433d..20ede403b62d 100644 > > --- a/arch/x86/kvm/svm/nested.c > > +++ b/arch/x86/kvm/svm/nested.c > > @@ -469,6 +469,21 @@ static bool nested_vmcb_check_save(struct kvm_vcpu *vcpu, > > if (CC(!__kvm_is_valid_cr4(vcpu, save->cr4))) > > return false; > > > > + if (CC((save->cr4 & X86_CR4_CET) && !(save->cr0 & X86_CR0_WP))) > > + return false; > > Why aren't we checking X86_FEATURE_SHSTK here as well? Do we know if > older CPUs that didn't support CET had the consistency check? CR4.CET is reserved if an AMD CPU doesn't have X86_FEATURE_SHSTK. Hence, older CPUs without CET support cannot fail the consistency check. > > + > > + if (guest_cpu_cap_has(vcpu, X86_FEATURE_SHSTK) && > > + CC(!kvm_is_valid_u_s_cet(vcpu, save->s_cet))) > > + return false; > > + > > + if ((save->cr4 & X86_CR4_CET) && (save->rflags & X86_EFLAGS_VM)) { > > + u64 u_cet = 0; > > + > > + if (!__kvm_emulate_msr_read(vcpu, MSR_IA32_U_CET, &u_cet) && > > If X86_FEATURE_SHSTK is not enumerated by the vCPU, then whether or not > the consistency check is done depends on ignore_msr. If ignore_msr=0, > the MSR read will fail and we won't do the consistency check, but if > ignore_msr=1 the MSR read will silently return 0, so the consistency > check will be done but will always succeed. If X86_FEATURE_SHSTK is not enumerated by the vCPU, then CR4.CET == 0 and this entire block is skipped. > Instead of this implicit dependency, should we check for > X86_FEATURE_SHSTK explicitly? That seems superfluous. > Also, if X86_FEATURE_SHSTK is enumberated by the vCPU, and the MSR read > fails, the consistency check will silently be skipped. But I don't think > this can/should happen. Maybe we should WARN in this case. You're right; failure to read the MSR should result in a failed VMRUN, and a warning would help triage the failure. > One last question, in the restore path, the MSR may have not been > restored yet, right? Can the consistency check mistakenly fail in this > case? Not with a legal snapshot. Note that on the restore path, the 'save' area holds L1 state. Hence, RFLAGS.VM must be clear, because VMRUN raises #UD in V8086 mode. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] KVM: nSVM: Add missing CET VMRUN consistency checks 2026-11-10 19:18 ` Jim Mattson @ 2026-11-10 19:29 ` Yosry Ahmed 2026-11-10 19:43 ` Jim Mattson 0 siblings, 1 reply; 5+ messages in thread From: Yosry Ahmed @ 2026-11-10 19:29 UTC (permalink / raw) To: Jim Mattson Cc: Sean Christopherson, Paolo Bonzini, John Allen, Chao Gao, kvm, linux-kernel On Tue, Nov 10, 2026 at 11:18 AM Jim Mattson <jmattson@google.com> wrote: > > On Tue, Nov 10, 2026 at 9:56 AM Yosry Ahmed <yosry@kernel.org> wrote: > > > > On Mon, Nov 09, 2026 at 04:40:37PM -0800, Jim Mattson wrote: > > > Per the APM, "Canonicalization and Consistency Checks," > > > > > > [t]he following conditions are considered illegal state combinations: > > > > > > - CR4.CET=1 when CR0.WP=0 > > > - Any reserved bit set in S_CET > > > - CR4.CET=1 and U_CET.SS=1 when EFLAGS.VM=1 > > > > > > Check these conditions in software before trying to VMRUN vmcb02, so that > > > the illegal states result in a #VMEXIT to L1 rather than an exit to > > > userspace with KVM_EXIT_FAIL_ENTRY. > > > > > > Fixes: c5ba49458513 ("KVM: nSVM: Save/load CET Shadow Stack state to/from vmcb12/vmcb02") > > > Signed-off-by: Jim Mattson <jmattson@google.com> > > > --- > > > arch/x86/kvm/svm/nested.c | 15 +++++++++++++++ > > > 1 file changed, 15 insertions(+) > > > > > > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c > > > index af0ef678433d..20ede403b62d 100644 > > > --- a/arch/x86/kvm/svm/nested.c > > > +++ b/arch/x86/kvm/svm/nested.c > > > @@ -469,6 +469,21 @@ static bool nested_vmcb_check_save(struct kvm_vcpu *vcpu, > > > if (CC(!__kvm_is_valid_cr4(vcpu, save->cr4))) > > > return false; > > > > > > + if (CC((save->cr4 & X86_CR4_CET) && !(save->cr0 & X86_CR0_WP))) > > > + return false; > > > > Why aren't we checking X86_FEATURE_SHSTK here as well? Do we know if > > older CPUs that didn't support CET had the consistency check? > > CR4.CET is reserved if an AMD CPU doesn't have X86_FEATURE_SHSTK. > Hence, older CPUs without CET support cannot fail the consistency > check. Oh I missed this, thanks. > > > > + > > > + if (guest_cpu_cap_has(vcpu, X86_FEATURE_SHSTK) && > > > + CC(!kvm_is_valid_u_s_cet(vcpu, save->s_cet))) > > > + return false; I wonder if we should clear the cached s_cet based on X86_FEATURE_SHSTK, similar to how we sanitize some cached control fields in __nested_copy_vmcb_control_to_cache(). Mostly orthogonal to this patch tho. > > > + > > > + if ((save->cr4 & X86_CR4_CET) && (save->rflags & X86_EFLAGS_VM)) { > > > + u64 u_cet = 0; > > > + > > > + if (!__kvm_emulate_msr_read(vcpu, MSR_IA32_U_CET, &u_cet) && > > > > If X86_FEATURE_SHSTK is not enumerated by the vCPU, then whether or not > > the consistency check is done depends on ignore_msr. If ignore_msr=0, > > the MSR read will fail and we won't do the consistency check, but if > > ignore_msr=1 the MSR read will silently return 0, so the consistency > > check will be done but will always succeed. > > If X86_FEATURE_SHSTK is not enumerated by the vCPU, then CR4.CET == 0 > and this entire block is skipped. Ack. > > Instead of this implicit dependency, should we check for > > X86_FEATURE_SHSTK explicitly? > > That seems superfluous. Given the above, yes. > > > Also, if X86_FEATURE_SHSTK is enumberated by the vCPU, and the MSR read > > fails, the consistency check will silently be skipped. But I don't think > > this can/should happen. Maybe we should WARN in this case. > > You're right; failure to read the MSR should result in a failed VMRUN, > and a warning would help triage the failure. > > > One last question, in the restore path, the MSR may have not been > > restored yet, right? Can the consistency check mistakenly fail in this > > case? > > Not with a legal snapshot. Note that on the restore path, the 'save' > area holds L1 state. Hence, RFLAGS.VM must be clear, because VMRUN > raises #UD in V8086 mode. Oh that's subtle, but yes, makes sense. I was going to suggest a comment, but I can't find a good place for it :) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] KVM: nSVM: Add missing CET VMRUN consistency checks 2026-11-10 19:29 ` Yosry Ahmed @ 2026-11-10 19:43 ` Jim Mattson 0 siblings, 0 replies; 5+ messages in thread From: Jim Mattson @ 2026-11-10 19:43 UTC (permalink / raw) To: Yosry Ahmed Cc: Sean Christopherson, Paolo Bonzini, John Allen, Chao Gao, kvm, linux-kernel On Tue, Nov 10, 2026 at 11:30 AM Yosry Ahmed <yosry@kernel.org> wrote: > > On Tue, Nov 10, 2026 at 11:18 AM Jim Mattson <jmattson@google.com> wrote: > > > > On Tue, Nov 10, 2026 at 9:56 AM Yosry Ahmed <yosry@kernel.org> wrote: > > > [ ... ] > > > One last question, in the restore path, the MSR may have not been > > > restored yet, right? Can the consistency check mistakenly fail in this > > > case? > > > > Not with a legal snapshot. Note that on the restore path, the 'save' > > area holds L1 state. Hence, RFLAGS.VM must be clear, because VMRUN > > raises #UD in V8086 mode. > > Oh that's subtle, but yes, makes sense. I was going to suggest a > comment, but I can't find a good place for it :) Saved by subtlety! ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-11-10 19:43 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-11-10 0:40 [PATCH] KVM: nSVM: Add missing CET VMRUN consistency checks Jim Mattson 2026-11-10 17:56 ` Yosry Ahmed 2026-11-10 19:18 ` Jim Mattson 2026-11-10 19:29 ` Yosry Ahmed 2026-11-10 19:43 ` Jim Mattson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®