arch/x86/kvm/svm/sev.c | 5 +++++ arch/x86/kvm/svm/svm.c | 43 +++++++++++++++++++++++++++++++++++++++--- arch/x86/kvm/svm/svm.h | 1 + 3 files changed, 46 insertions(+), 3 deletions(-)
AMD Zen3 and newer processors support shadow stack, a feature designed
to protect against ROP (return-oriented programming) attacks in which an
attacker manipulates return addresses on the call stack in order to
execute arbitrary code. To prevent this, shadow stacks can be allocated
that are only used by control transfer and return instructions. When a
CALL instruction is issued, it writes the return address to both the
program stack and the shadow stack. When the subsequent RET instruction
is issued, it pops the return address from both stacks and compares
them. If the addresses don't match, a control-protection exception is
raised.
Shadow stack and a related feature, Indirect Branch Tracking (IBT), are
collectively referred to as Control-flow Enforcement Technology (CET).
However, current AMD processors only support shadow stack and not IBT.
This series adds support for shadow stack in SVM guests and builds upon
the support added in the CET guest support patch series [1]. Additional
patches are required to support shadow stack enabled guests in qemu [2].
[1]: CET guest support patches (v13)
https://lore.kernel.org/all/20250821133132.72322-1-chao.gao@intel.com/
[2]: CET qemu patches
https://lore.kernel.org/all/20230720111445.99509-1-weijiang.yang@intel.com/
[3]: Previous SVM support patches (v3)
https://lore.kernel.org/all/20250806204510.59083-1-john.allen@amd.com/
---
RFC v2:
- Rebased on v3 of the Intel CET virtualization series, dropping the
patch that moved cet_is_msr_accessible to common code as that has
been pulled into the Intel series.
- Minor change removing curly brackets around if statement introduced
in patch 6/6.
RFC v3:
- Rebased on v5 of the Intel CET virtualization series.
- Add patch changing the name of vmplX_ssp SEV-ES save area fields to
plX_ssp.
- Merge this series intended for KVM with the separate guest kernel
patch (now patch 7/8).
- Update MSR passthrough code to conditionally pass through shadow
stack MSRS based on both host and guest support.
- Don't save PL0_SSP, PL1_SSP, and PL2_SSP MSRs on SEV-ES VMRUN as
these are currently unused.
v1:
- Remove RFC tag from series
- Rebase on v6 of the Intel CET virtualization series
- Use KVM-governed feature to track SHSTK for SVM
v2:
- Add new patch renaming boot_*msr to raw_*msr. Utilize raw_rdmsr when
reading XSS on SEV-ES cpuid instructions.
- Omit unnecessary patch for saving shadow stack msrs on SEV-ES VMRUN
- Omit passing through of XSS for SEV-ES as support has already been
properly implemented in a26b7cd22546 ("KVM: SEV: Do not intercept
accesses to MSR_IA32_XSS for SEV-ES guests")
v3:
- Rebased on v11 of the Intel CET Virtualization series.
- Split guest kernel patches into a separate series as these are
independent of this series and are needed to support non-KVM
hypervisors.
v4:
- Rebased on v13 of the Intel CET Virtualization series.
- Add SEV-ES save area fields to dump_vmcb.
- Don't pass through MSR_IA32_INT_SSP_TAB.
- Don't remove clearing of IBT capability.
John Allen (5):
KVM: x86: SVM: Emulate reads and writes to shadow stack MSRs
KVM: x86: SVM: Update dump_vmcb with shadow stack save area additions
KVM: x86: SVM: Pass through shadow stack MSRs
KVM: SVM: Add MSR_IA32_XSS to the GHCB for hypervisor kernel
KVM: SVM: Enable shadow stack virtualization for SVM
arch/x86/kvm/svm/sev.c | 5 +++++
arch/x86/kvm/svm/svm.c | 43 +++++++++++++++++++++++++++++++++++++++---
arch/x86/kvm/svm/svm.h | 1 +
3 files changed, 46 insertions(+), 3 deletions(-)
--
2.47.3
On Mon, Sep 08, 2025, John Allen wrote:
> This series adds support for shadow stack in SVM guests
^
|
some
I mean, who cares about nested, right?
Sorry for being snippy, but I am more than a bit peeved that we're effectively
on revision 6 of this series, and apparently no one has thought to do even basic
tested of nested SVM. And I'm even more grumpy that writing tests continues to
be low priority in general, which is especially concerning for such a large,
complex feature.
Adding support for nested was easy enough (famous last words), but I really wish
I could get back the ~hour I spent figuring out what was missing...
On Fri, Sep 12, 2025 at 03:54:31PM -0700, Sean Christopherson wrote: > On Mon, Sep 08, 2025, John Allen wrote: > > This series adds support for shadow stack in SVM guests > ^ > | > some > > I mean, who cares about nested, right? > > Sorry for being snippy, but I am more than a bit peeved that we're effectively > on revision 6 of this series, and apparently no one has thought to do even basic > tested of nested SVM. Hi Sean, I have been testing nested with this feature (or so I thought). Can you explain what you did to test and what wasn't working? Apologies, and thanks for taking the time to look into the problem. Thanks, John
On Mon, Sep 15, 2025, John Allen wrote: > On Fri, Sep 12, 2025 at 03:54:31PM -0700, Sean Christopherson wrote: > > On Mon, Sep 08, 2025, John Allen wrote: > > > This series adds support for shadow stack in SVM guests > > ^ > > | > > some > > > > I mean, who cares about nested, right? > > > > Sorry for being snippy, but I am more than a bit peeved that we're effectively > > on revision 6 of this series, and apparently no one has thought to do even basic > > tested of nested SVM. > > Hi Sean, > > I have been testing nested with this feature (or so I thought). The issue here is that Linux only supports shadow stacks at CPL3, i.e. only exercises MSR_IA32_U_CET, and for whatever reason the KVM-Unit-Test only tests MSR_IA32_U_CET too (and is stupidly not compatible with AMD due to requiring SHSTK *and* IBT). So just running those in nested won't provide any coverage for S_CET. > Can you explain what you did to test and what wasn't working? Read/write MSR_IA32_S_CET to a non-zero value from L2 by running the proposed selftest[*] in L1. Because KVM doesn't propagate S_CET to/from vmcb12, the writes from L2 are effectively lost. An ever better way to cover this would be a selftest or KUT test to explicitly read/write MSRs in L2, and/or fill vmcs12/vmcb12 from L1 and verify L2 sees the desired value. https://lore.kernel.org/all/20250912232319.429659-37-seanjc@google.com > Apologies, and thanks for taking the time to look into the problem. No worries, I didn't intend to single you out, I was essentially just yelling at everyone involved :-)
© 2016 - 2026 Red Hat, Inc.