[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8dba55b2-9ae8-4199-b93c-024795777032@zytor.com>
Date: Mon, 18 Aug 2025 15:25:21 -0700
From: Xin Li <xin@...or.com>
To: Chao Gao <chao.gao@...el.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Cc: mlevitsk@...hat.com, rick.p.edgecombe@...el.com, weijiang.yang@...el.com,
Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Sean Christopherson
<seanjc@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org
Subject: Re: [PATCH v12 00/24] Enable CET Virtualization
On 8/11/2025 7:55 PM, Chao Gao wrote:
> The FPU support for CET virtualization has already been merged into 6.17-rc1.
> Building on that, this series introduces Intel CET virtualization support for
> KVM.
>
> Changes in v12:
> 1. collect Tested-by tags from John and Mathias.
> 2. use less verbose names for KVM rdmsr/wrmsr emulation APIs in patch 1/2
> (Sean/Xin)
> 3. refer to s_cet, ssp, and ssp_table in a consistent order in patch 22
> (Xin)
>
> Please note that I didn't include Mathias' patch, which makes CR4.CET
> guest-owned. I expect that patch to be posted separately.
>
> ---
> Control-flow Enforcement Technology (CET) is a kind of CPU feature used
> to prevent Return/CALL/Jump-Oriented Programming (ROP/COP/JOP) attacks.
> It provides two sub-features(SHSTK,IBT) to defend against ROP/COP/JOP
> style control-flow subversion attacks.
>
> Shadow Stack (SHSTK):
> A shadow stack is a second stack used exclusively for control transfer
> operations. The shadow stack is separate from the data/normal stack and
> can be enabled individually in user and kernel mode. When shadow stack
> is enabled, CALL pushes the return address on both the data and shadow
> stack. RET pops the return address from both stacks and compares them.
> If the return addresses from the two stacks do not match, the processor
> generates a #CP.
>
> Indirect Branch Tracking (IBT):
> IBT introduces new instruction(ENDBRANCH)to mark valid target addresses
> of indirect branches (CALL, JMP etc...). If an indirect branch is
> executed and the next instruction is _not_ an ENDBRANCH, the processor
> generates a #CP. These instruction behaves as a NOP on platforms that
> doesn't support CET.
>
> CET states management
> =====================
> KVM cooperates with host kernel FPU framework to manage guest CET registers.
> With CET supervisor mode state support in this series, KVM can save/restore
> full guest CET xsave-managed states.
>
> CET user mode and supervisor mode xstates, i.e., MSR_IA32_{U_CET,PL3_SSP}
> and MSR_IA32_PL{0,1,2}, depend on host FPU framework to swap guest and host
> xstates. On VM-Exit, guest CET xstates are saved to guest fpu area and host
> CET xstates are loaded from task/thread context before vCPU returns to
> userspace, vice-versa on VM-Entry. See details in kvm_{load,put}_guest_fpu().
>
> CET supervisor mode states are grouped into two categories : XSAVE-managed
> and non-XSAVE-managed, the former includes MSR_IA32_PL{0,1,2}_SSP and are
> controlled by CET supervisor mode bit(S_CET bit) in XSS, the later consists
> of MSR_IA32_S_CET and MSR_IA32_INTR_SSP_TBL.
>
> VMX introduces new VMCS fields, {GUEST|HOST}_{S_CET,SSP,INTR_SSP_TABL}, to
> facilitate guest/host non-XSAVES-managed states. When VMX CET entry/exit load
> bits are set, guest/host MSR_IA32_{S_CET,INTR_SSP_TBL,SSP} are loaded from
> equivalent fields at VM-Exit/Entry. With these new fields, such supervisor
> states require no addtional KVM save/reload actions.
>
> Tests
> ======
> This series has successfully passed the basic CET user shadow stack test
> and kernel IBT test in both L1 and L2 guests. The newly added
> KVM-unit-tests [2] also passed, and its v11 has been tested with the AMD
> CET series by John [3].
>
> For your convenience, you can use my WIP QEMU [1] for testing.
>
> [1]: https://github.com/gaochaointel/qemu-dev qemu-cet
> [2]: https://lore.kernel.org/kvm/20250626073459.12990-1-minipli@grsecurity.net/
> [3]: https://lore.kernel.org/kvm/aH6CH+x5mCDrvtoz@AUSJOHALLEN.amd.com/
>
I rebased the KVM FRED patch set on top of this KVM CET patch set, and
will send out soon.
Powered by blists - more mailing lists