[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH v9 00/11] x86: Mitigations for SP2/CVE-2017-5715/Branch Target Injection
This series is availabe in git form from: http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/sp2-mitigations-v9 A copy of Intel's spec for IBRS/IBPB can be found here: https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf In addition to this software series, you will need the following: 1) A compiler which understands -mindirect-branch=thunk-external and -mindirect-branch-register. A GCC patch series implementing this should be available imminently. In the meantime, a development branch can be obtained from: https://github.com/hjl-tools/gcc/commits/hjl/indirect/gcc-7-branch/master 2) New microcode from Intel and AMD. These provide new MSRs for Xen to use, and virtualise for guest kernels to use. There are some limitations, even with the work presented here. 1) vCPU-to-vCPU SP2 attacks can only be mitigated at the hypervisor level with IBPB support, which for internal pipeline reasons, we do not expect to be made available on older processors. For now, I will leave these details to the hardware vendors. 2) Hardware lacking SMEP is in a worse position than hardware with SMEP. If you have SMEP (Intel IvyBridge and later, Some AMD Fam16h and all Fam17h and later), make absolutely sure it is enabled in the BIOS and working. 3) On hardware lacking SMEP support, it is still an open question how to protect against RSB-to-SMM speculation. Native operating systems can fix this by prohibiting userspace from mmap()'ing addresses which alias the SMM range, but Xen has no feasible way of enforcing this restriction on PV guests, even if we could tolerate the ABI breakage. (However, see the forthcoming SP3 mitigation series for alternatives for un trusted PV guests). ~Andrew Changes from v8: * Large rework of STIBP handling following Intel publishing a new spec * Rebase over the XPTI patches Andrew Cooper (11): x86/thunk: Fix GEN_INDIRECT_THUNK comment x86/cpuid: Handling of IBRS/IBPB, STIBP and IBRS for guests x86/msr: Emulation of MSR_{SPEC_CTRL,PRED_CMD} for guests x86/migrate: Move MSR_SPEC_CTRL on migrate x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL,PRED_CMD} x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point x86/boot: Calculate the most appropriate BTI mitigation to use x86/entry: Clobber the Return Stack Buffer/Return Address Stack on entry to Xen x86/ctxt: Issue a speculation barrier between vcpu contexts x86/cpuid: Offer Indirect Branch Controls to guests x86/idle: Clear SPEC_CTRL while idle docs/misc/xen-command-line.markdown | 13 +- tools/libxc/xc_cpuid_x86.c | 4 +- xen/arch/x86/acpi/cpu_idle.c | 21 +++ xen/arch/x86/cpu/mwait-idle.c | 7 + xen/arch/x86/cpuid.c | 28 +++ xen/arch/x86/domain.c | 31 ++++ xen/arch/x86/domctl.c | 21 +++ xen/arch/x86/hvm/hvm.c | 2 + xen/arch/x86/hvm/svm/entry.S | 8 +- xen/arch/x86/hvm/svm/svm.c | 5 + xen/arch/x86/hvm/vmx/entry.S | 11 ++ xen/arch/x86/hvm/vmx/vmx.c | 17 ++ xen/arch/x86/indirect-thunk.S | 2 +- xen/arch/x86/msr.c | 45 +++++ xen/arch/x86/setup.c | 1 + xen/arch/x86/smpboot.c | 2 + xen/arch/x86/spec_ctrl.c | 142 ++++++++++++++- xen/arch/x86/x86_64/asm-offsets.c | 6 + xen/arch/x86/x86_64/compat/entry.S | 14 ++ xen/arch/x86/x86_64/entry.S | 34 ++++ xen/include/asm-x86/asm_defns.h | 3 + xen/include/asm-x86/cpufeatures.h | 2 + xen/include/asm-x86/current.h | 6 + xen/include/asm-x86/msr-index.h | 2 + xen/include/asm-x86/msr.h | 10 ++ xen/include/asm-x86/nops.h | 7 + xen/include/asm-x86/spec_ctrl.h | 45 +++++ xen/include/asm-x86/spec_ctrl_asm.h | 267 ++++++++++++++++++++++++++++ xen/include/public/arch-x86/cpufeatureset.h | 6 +- 29 files changed, 751 insertions(+), 11 deletions(-) create mode 100644 xen/include/asm-x86/spec_ctrl_asm.h -- 2.1.4 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |