Message ID | 20201106011637.14289-1-weijiang.yang@intel.com (mailing list archive) |
---|---|
Headers | show |
Series | Introduce support for guest CET feature | expand |
On 06/11/20 02:16, Yang Weijiang wrote: > Control-flow Enforcement Technology (CET) provides protection against > Return/Jump-Oriented Programming (ROP/JOP) attack. There're two CET > sub-features: Shadow Stack (SHSTK) and Indirect Branch Tracking (IBT). > SHSTK is to prevent ROP programming and IBT is to prevent JOP programming. > > Several parts in KVM have been updated to provide VM CET support, including: > CPUID/XSAVES config, MSR pass-through, user space MSR access interface, > vmentry/vmexit config, nested VM etc. These patches have dependency on CET > kernel patches for xsaves support and CET definitions, e.g., MSR and related > feature flags. > > CET kernel patches are here: > SHSTK: https://lkml.kernel.org/r/20201012153850.26996-1-yu-cheng.yu@intel.com/ > IBT: https://lkml.kernel.org/r/20201012154530.28382-1-yu-cheng.yu@intel.com/ > > CET QEMU patch: > https://patchwork.ozlabs.org/project/qemu-devel/patch/20201013051935.6052-2-weijiang.yang@intel.com/ > KVM Unit test: > https://patchwork.kernel.org/project/kvm/patch/20200506082110.25441-12-weijiang.yang@intel.com/ > > v14: > - Sean refactored v13 patchset then came out v14-rc1, this version is > rebased on top of 5.10-rc1 and tested on TGL. > - Fixed a few minor issues found during test, such as nested CET broken, > call-trace and guest reboot failure etc. > - Original v14-rc1 is here: https://github.com/sean-jc/linux/tree/vmx/cet. > > v13: > - Added CET definitions as a separate patch to facilitate KVM test. > - Disabled CET support in KVM if unrestricted_guest is turned off since > in this case CET related instructions/infrastructure cannot be emulated > well. > > v12: > - Fixed a few issues per Sean and Paolo's review feeback. > - Refactored patches to make them properly arranged. > - Removed unnecessary hard-coded CET states for host/guest. > - Added compile-time assertions for vmcs_field_to_offset_table to detect > mismatch of the field type and field encoding number. > - Added a custom MSR MSR_KVM_GUEST_SSP for guest active SSP save/restore. > - Rebased patches to 5.7-rc3. > > v11: > - Fixed a guest vmentry failure issue when guest reboots. > - Used vm_xxx_control_{set, clear}bit() to avoid side effect, it'll > clear cached data instead of pure VMCS field bits. > - Added vcpu->arch.guest_supported_xss dedidated for guest runtime mask, > this avoids supported_xss overwritten issue caused by an old qemu. > - Separated vmentry/vmexit state setting with CR0/CR4 dependency check > to make the patch more clear. > - Added CET VMCS states in dump_vmcs() for debugging purpose. > - Other refactor based on testing. > - This patch serial is built on top of below branch and CET kernel patches > for seeking xsaves support. > > v10: > - Refactored code per Sean's review feedback. > - Added CET support for nested VM. > - Removed fix-patch for CPUID(0xd,N) enumeration as this part is done > by Paolo and Sean. > - This new patchset is based on Paolo's queued cpu_caps branch. > - Modified patch per XSAVES related change. > - Consolidated KVM unit-test patch with KVM patches. > > v9: > - Refactored msr-check functions per Sean's feedback. > - Fixed a few issues per Sean's suggestion. > - Rebased patch to kernel-v5.4. > - Moved CET CPUID feature bits and CR4.CET to last patch. > > v8: > - Addressed Jim and Sean's feedback on: 1) CPUID(0xD,i) enumeration. 2) > sanity check when configure guest CET. 3) function improvement. > - Added more sanity check functions. > - Set host vmexit default status so that guest won't leak CET status to > host when vmexit. > - Added CR0.WP vs. CR4.CET mutual constrains. > > v7: > - Rebased patch to kernel v5.3 > - Sean suggested to change CPUID(0xd, n) enumeration code as alined with > existing one, and I think it's better to make the fix as an independent patch > since XSS MSR are being used widely on X86 platforms. > - Check more host and guest status before configure guest CET > per Sean's feedback. > - Add error-check before guest accesses CET MSRs per Sean's feedback. > - Other minor fixes suggested by Sean. > > v6: > - Rebase patch to kernel v5.2. > - Move CPUID(0xD, n>=1) helper to a seperate patch. > - Merge xsave size fix with other patch. > - Other minor fixes per community feedback. > > v5: > - Rebase patch to kernel v5.1. > - Wrap CPUID(0xD, n>=1) code to a helper function. > - Pass through MSR_IA32_PL1_SSP and MSR_IA32_PL2_SSP to Guest. > - Add Co-developed-by expression in patch description. > - Refine patch description. > > v4: > - Add Sean's patch for loading Guest fpu state before access XSAVES > managed CET MSRs. > - Melt down CET bits setting into CPUID configuration patch. > - Add VMX interface to query Host XSS. > - Check Host and Guest XSS support bits before set Guest XSS. > - Make Guest SHSTK and IBT feature enabling independent. > - Do not report CET support to Guest when Host CET feature is Disabled. > > v3: > - Modified patches to make Guest CET independent to Host enabling. > - Added patch 8 to add user space access for Guest CET MSR access. > - Modified code comments and patch description to reflect changes. > > v2: > - Re-ordered patch sequence, combined one patch. > - Added more description for CET related VMCS fields. > - Added Host CET capability check while enabling Guest CET loading bit. > - Added Host CET capability check while reporting Guest CPUID(EAX=7, EXC=0). > - Modified code in reporting Guest CPUID(EAX=D,ECX>=1), make it clearer. > - Added Host and Guest XSS mask check while setting bits for Guest XSS. > > > Sean Christopherson (2): > KVM: x86: Report XSS as an MSR to be saved if there are supported features > KVM: x86: Load guest fpu state when accessing MSRs managed by XSAVES > > Yang Weijiang (11): > KVM: x86: Refresh CPUID on writes to MSR_IA32_XSS > KVM: x86: Add #CP support in guest exception dispatch > KVM: VMX: Introduce CET VMCS fields and flags > KVM: x86: Add fault checks for CR4.CET > KVM: VMX: Emulate reads and writes to CET MSRs > KVM: VMX: Add a synthetic MSR to allow userspace VMM to access GUEST_SSP > KVM: x86: Report CET MSRs as to-be-saved if CET is supported > KVM: x86: Enable CET virtualization for VMX and advertise CET to userspace > KVM: VMX: Pass through CET MSRs to the guest when supported > KVM: nVMX: Add helper to check the vmcs01 MSR bitmap for MSR pass-through > KVM: nVMX: Enable CET support for nested VMX > > arch/x86/include/asm/kvm_host.h | 4 +- > arch/x86/include/asm/vmx.h | 8 ++ > arch/x86/include/uapi/asm/kvm.h | 1 + > arch/x86/include/uapi/asm/kvm_para.h | 1 + > arch/x86/kvm/cpuid.c | 26 +++- > arch/x86/kvm/vmx/capabilities.h | 5 + > arch/x86/kvm/vmx/nested.c | 57 ++++++-- > arch/x86/kvm/vmx/vmcs12.c | 6 + > arch/x86/kvm/vmx/vmcs12.h | 14 +- > arch/x86/kvm/vmx/vmx.c | 207 ++++++++++++++++++++++++++- > arch/x86/kvm/x86.c | 56 +++++++- > arch/x86/kvm/x86.h | 10 +- > 12 files changed, 370 insertions(+), 25 deletions(-) > I reviewed the patch and it is mostly okay. However, if I understand it correctly, it will not do anything until host support materializes, because otherwise XSS will be 0. If this is the case, I plan to apply locally v15 and hold on it until the host code is committed. Paolo
On Thu, Jan 28, 2021, Paolo Bonzini wrote: > On 06/11/20 02:16, Yang Weijiang wrote: > > Control-flow Enforcement Technology (CET) provides protection against > > Return/Jump-Oriented Programming (ROP/JOP) attack. There're two CET > > sub-features: Shadow Stack (SHSTK) and Indirect Branch Tracking (IBT). > > SHSTK is to prevent ROP programming and IBT is to prevent JOP programming. ... > I reviewed the patch and it is mostly okay. However, if I understand it > correctly, it will not do anything until host support materializes, because > otherwise XSS will be 0. IIRC, it won't even compile due to the X86_FEATURE_SHSTK and X86_FEATURE_IBT dependencies. > If this is the case, I plan to apply locally v15 and hold on it until the > host code is committed. > > Paolo >
On 28/01/21 19:04, Sean Christopherson wrote: > On Thu, Jan 28, 2021, Paolo Bonzini wrote: >> On 06/11/20 02:16, Yang Weijiang wrote: >>> Control-flow Enforcement Technology (CET) provides protection against >>> Return/Jump-Oriented Programming (ROP/JOP) attack. There're two CET >>> sub-features: Shadow Stack (SHSTK) and Indirect Branch Tracking (IBT). >>> SHSTK is to prevent ROP programming and IBT is to prevent JOP programming. > > ... > >> I reviewed the patch and it is mostly okay. However, if I understand it >> correctly, it will not do anything until host support materializes, because >> otherwise XSS will be 0. > > IIRC, it won't even compile due to the X86_FEATURE_SHSTK and X86_FEATURE_IBT > dependencies. Of course, but if that was the only issue I would sort it out with Boris as usual. OTOH if it is dead code I won't push it to Linus. Paolo >> If this is the case, I plan to apply locally v15 and hold on it until the >> host code is committed. >> >> Paolo >> >
On Thu, Jan 28, 2021, Paolo Bonzini wrote: > On 28/01/21 19:04, Sean Christopherson wrote: > > On Thu, Jan 28, 2021, Paolo Bonzini wrote: > > > On 06/11/20 02:16, Yang Weijiang wrote: > > > > Control-flow Enforcement Technology (CET) provides protection against > > > > Return/Jump-Oriented Programming (ROP/JOP) attack. There're two CET > > > > sub-features: Shadow Stack (SHSTK) and Indirect Branch Tracking (IBT). > > > > SHSTK is to prevent ROP programming and IBT is to prevent JOP programming. > > > > ... > > > > > I reviewed the patch and it is mostly okay. However, if I understand it > > > correctly, it will not do anything until host support materializes, because > > > otherwise XSS will be 0. > > > > IIRC, it won't even compile due to the X86_FEATURE_SHSTK and X86_FEATURE_IBT > > dependencies. > > Of course, but if that was the only issue I would sort it out with Boris as > usual. OTOH if it is dead code I won't push it to Linus. Yes, at best it's dead code. At worst, if it somehow became undead, the guest state would bleed into the host and wouldn't be migrated as the kernel wouldn't touch CET state when doing XSAVES/XRSTORS. I floated the idea of pulling in just enough of the kernel bits to enable KVM, but that didn't go anywhere. https://lkml.kernel.org/r/20200723162531.GF21891@linux.intel.com