OVMSA-2018-0272
- ULN >
- Oracle Linux Errata repository >
- OVMSA-2018-0272
OVMSA-2018-0272 - xen security update
| Type: | SECURITY |
| Severity: | IMPORTANT |
| Release Date: | 2018-11-13 |
Description
[4.1.3-25.el5.223.214]
- From 45c551670427f54f48c47ac5430e66ecd4a45e00 Mon Sep 17 00:00:00 2001
From: Jan Beulich
Date: Tue, 16 Oct 2018 07:12:16 +0800
Subject: [PATCH 4/4] x86/spec-ctrl: command line handling adjustments
For one, 'no-xen' should not imply 'no-eager-fpu', as 'eager FPU' mode
is to guard guests, not Xen itself, which is also expressed so by
print_details().
And then opt_ssbd, despite being off by default, should also be cleared
by the 'no' and 'no-xen' sub-options.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
master commit: ac3f9a72141a48d40fabfff561d5a7dc0e1b810d
master date: 2018-07-10 12:22:31 +0200
Cherry-picked from: 2d69b6d00d6ac04bda01e7323bcd006f0f88ceb7
These are followup fixes for Lazy FPU/XSA-267
Signed-off-by: Ross Philipson
Reviewed-by: Boris Ostrovsky
Based on OVM3.4.5 commit 32df6a92ef8065da5ab471f86ab9c67df29fcafa
Conflicts:
xen/arch/x86/spec_ctrl.c
Fixed a wrong placed chunk in l1tf backport related to opt_l1d_flush.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.213]
- From 136de08b33138d72c3bb221bc8dd3c851537b228 Mon Sep 17 00:00:00 2001
From: Jan Beulich
Date: Tue, 16 Oct 2018 07:06:19 +0800
Subject: [PATCH 3/4] x86/HVM: don't cause #NM to be raised in Xen
The changes for XSA-267 did not touch management of CR0.TS for HVM
guests. In fully eager mode this bit should never be set when
respective vCPU-s are active, or else hvmemul_get_fpu() might leave it
wrongly set, leading to #NM in hypervisor context.
{svm,vmx}_enter() and {svm,vmx}_fpu_dirty_intercept() become unreachable
this way. Explicit {svm,vmx}_fpu_leave() invocations need to be guarded
now.
With no CR0.TS management necessary in fully eager mode, there's also no
need anymore to intercept #NM.
Reported-by: Charles Arnold
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Cherry-picked from: 598a375f5230d91ac88e76a9f4b4dde4a62a4c5b
These are followup fixes for Lazy FPU/XSA-267
Signed-off-by: Ross Philipson
Reviewed-by: Boris Ostrovsky
Backported from OVM3.4.5 commit f9f5f0bb3188437559ca74021b24b83fe52947d4
Conflicts:
arch/x86/hvm/vmx/vmx.c
Signed-off-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.212]
- From 2b86542d60564af211219dd37f713bfb3d2c8010 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Mon, 24 Sep 2018 02:51:57 +0800
Subject: [PATCH 2/4] x86/spec-ctrl: Mitigations for LazyFPU
Intel Core processors since at least Nehalem speculate past #NM, which is the
mechanism by which lazy FPU context switching is implemented.
On affected processors, Xen must use fully eager FPU context switching to
prevent guests from being able to read FPU state (SSE/AVX/etc) from previously
scheduled vcpus.
This is part of XSA-267
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Taken from the xsa267-4.6-2.patch posted with the XSA
Conflicts:
include/asm-x86/spec_ctrl.h - context
arch/x86/spec_ctrl.c - context
xen/arch/x86/i387.c - there is no vcpu_init_fpu() in OVM3.2
patching on xsave_alloc_save_area() directly.
No docs/misc/xen-command-line.markdown in OVM3.2, ignored related chunk.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.211]
- From c3d5db5e5e0800cbb07a0d8a6b0e87e1ec2b3133 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Fri, 15 Jun 2018 14:17:14 -0400
Subject: [PATCH 1/4] x86: Support fully eager FPU context switching
This is controlled on a per-vcpu bases for flexibility.
This is part of XSA-267
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Taken from the xsa267-4.6-1.patch posted with the XSA
Conflicts:
xen/include/asm-x86/domain.h - context
xen/arch/x86/domain.c - context
xen/include/xen/sched.h - declare is_pv_domain() and is_pv_vcpu()
xen/include/asm-x86/i387.h - declare vcpu_restore_fpu_eager()
xen/arch/x86/i387.c - define vcpu_restore_fpu_eager(), its
counterpart in upstream is vcpu_restore_fpu_nonlazy().
vcpu_restore_fpu_eager() supports fully eager fpu case but not the nonlazy
extended state, it's a subset of vcpu_restore_fpu_nonlazy().
fpu_xrstor/fpu_fxrstor is used in vcpu_restore_fpu_nonlazy() to restore
FPU context, we don't have same function in OVM3.2, so use setup_fpu()
instead, in fact the logic is same for lazy fpu part though the code is
largely refactored.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.210]
- From b66a5d032e8b31735330e208050c354373ffbc7a Mon Sep 17 00:00:00 2001
From: Julien Grall
Date: Fri, 27 Sep 2013 17:56:34 +0100
Subject: [PATCH OVM3.2.x 8/8] xen: Add macro ROUNDUP
Signed-off-by: Julien Grall
Acked-by: Keir Fraser
CC: Jan Beulich
This is a prerequisite for XSA-273
Signed-off-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.209]
- From 3051fa2d29044c7fdcec51ea9d1096560f7edee0 Mon Sep 17 00:00:00 2001
From: Ross Philipson
Date: Thu, 19 Jul 2018 17:56:03 -0400
Subject: [PATCH OVM3.2.x 7/8] l1tf: Utility to offline/online SMT siblings.
This utility can offline all SMT siblings. It can be used to skip CPUs
dedicated to dom0. For symmetry with other tools, it can also be used
to online SMT siblings.
This is part of XSA-273
Orabug: 28487050
Signed-off-by: Ross Philipson
Reviewed-by: Boris Ostrovsky
Conflicts:
tools/misc/Makefile
Signed-off-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.208]
- From 5582b2ee6f2f2482a37bcc8f28e1e75e3351f70c Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Tue, 29 May 2018 18:44:16 +0100
Subject: [PATCH OVM3.2.x 6/8] x86/spec-ctrl: Introduce an option to control L1D_FLUSH for HVM guests
This mitigation requires up-to-date microcode, and is enabled by default on
affected hardware if available.
The default for SMT/Hyperthreading is far more complicated to reason about,
not least because we don't know if the user is going to want to run any HVM
guests to begin with. If a explicit default isn't given, nag the user to
perform a risk assessment and choose an explicit default, and leave other
configuration to the toolstack.
This is part of XSA-273 / CVE-2018-3620.
Signed-off-by: Andrew Cooper
Orabug: 28487050
This version differs from the upstream version in that it does the
L1D flush from the tail end of vmx_vmenter_helper(). Having the flush
done during the VMCS restore causes a platform hang in our version of
Xen. This issue will be investigated separately. The rest
are just some minor context and offset diffs.
Signed-off-by: Ross Philipson
Reviewed-by: Boris Ostrovsky
Conflicts:
docs/misc/xen-command-line.markdown not exist
xen/arch/x86/cpu/common.c - context
xen/arch/x86/hvm/vmx/vmx.c - context
xen/arch/x86/spec_ctrl.c - context
Signed-off-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.207]
- From a25c8e13df013b8c7af9627fd7597829e869498c Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Fri, 13 Apr 2018 15:34:01 +0000
Subject: [PATCH OVM3.2.x 5/8] x86/msr: Virtualise MSR_FLUSH_CMD for guests
Guests (outside of the nested virt case, which isn't supported yet) don't need
L1D_FLUSH for their L1TF mitigations, but offering/emulating MSR_FLUSH_CMD is
easy and doesn't pose an issue for Xen.
The MSR is offered to HVM guests only. PV guests attempting to use it would
trap for emulation, and the L1D cache would fill long before the return to
guest context. As such, PV guests can't make any use of the L1D_FLUSH
functionality.
This is part of XSA-273 / CVE-2018-3646.
Signed-off-by: Andrew Cooper
Orabug: 28487050
This patch differs a fair amount from the upstream version. The CPUID policy
in this version of Xen is a partial implementation of what is upstream so the
management of it is different. The end result is the same functionality
though.
Signed-off-by: Ross Philipson
Reviewed-by: Boris Ostrovsky
Conflicts:
tools/libxc/xc_cpufeature.h - context
xen/arch/x86/domctl.c - context
xen/arch/x86/hvm/vmx/vmx.c input parameter format difference
Signed-off-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.206]
- From 47a0500460a19ee2396ef1dad5283452e27ab2e6 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 28 Mar 2018 15:21:39 +0100
Subject: [PATCH OVM3.2.x 4/8] x86/spec-ctrl: CPUID/MSR definitions for L1D_FLUSH
This is part of XSA-273 / CVE-2018-3646.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Orabug: 28487050
Mostly the same. The file tools/misc/xen-cpuid.c does not exist
so those changes did not apply. Also the CPUIDs are specified differenly
in this version of Xen. The rest were just context and offset diffs.
Signed-off-by: Ross Philipson
Reviewed-by: Boris Ostrovsky
Conflicts:
xen/include/asm-x86/msr-index.h - context
docs/misc/xen-command-line.markdown not exist
Signed-off-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.205]
- From 9f6240b1b05bc54b1823d6bf34a056899aaa9a70 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 25 Jul 2018 12:10:19 +0000
Subject: [PATCH OVM3.2.x 3/8] x86/spec-ctrl: Calculate safe PTE addresses for L1TF mitigations
Safe PTE addresses for L1TF mitigations are ones which are within the L1D
address width (may be wider than reported in CPUID), and above the highest
cacheable RAM/NVDIMM/BAR/etc.
All logic here is best-effort heuristics, which should in practice be fine for
most hardware. Future work will see about disentangling and feeding SRAT
information into the heuristics, as well as having L0 pass this information
down to lower levels when virtualised.
This is part of XSA-273 / CVE-2018-3620.
Signed-off-by: Andrew Cooper
Orabug: 28487050
Patch mostly the same, some context differences and offset mismatches.
There are some bits of the PV support in this patch also but they were
left there to keep the patch similar to its upstream cousin.
Also we are not picking up original patch's EFI code changes because they
are related to PV only.
Signed-off-by: Ross Philipson
Reviewed-by: Boris Ostrovsky
Conflits:
xen/arch/x86/spec_ctrl.c
No should_use_eager_fpu(), ignore related chunk
Signed-off-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.204]
- From 226222419e04c1b04879b968b44373757c93a7a3 Mon Sep 17 00:00:00 2001
From: Jan Beulich
Date: Thu, 19 Jul 2018 04:32:43 -0600
Subject: [PATCH OVM3.2.x 2/8] x86: command line option to avoid use of secondary hyper-threads
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Shared resources (L1 cache and TLB in particular) present a risk of
information leak via side channels. Provide a means to avoid use of
hyperthreads in such cases.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monn?195?169
Reviewed-by: Andrew Cooper
This is a prerequisite for XSA-273
Orabug: 28487050
(cherry picked from commit d8f974f1a646c0200b97ebcabb808324b288fadb)
Mostly the same. Slight difference in logic in the setup CPU online/offline
code. Also use BAD_APICID instead of INVALID_CUID.
Signed-off-by: Ross Philipson
Reviewed-by: Boris Ostrovsky
Reviewed-by: Joao Martins
Conflicts:
docs/misc/xen-command-line.markdown doesn't exist in OVM3.2
arch/x86/setup.c - use cpu_sibling_map instad of cpu_sibling_mask
arch/x86/sysctl.c - use cpu_sibling_map instad of cpu_sibling_mask
Signed-off-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.203]
- From 0009c9638533cec96bb30ea8451c9c05b39b83dd Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan
Date: Sat, 1 Sep 2018 07:18:43 +0800
Subject: [PATCH OVM3.2.x 1/8] Add bool/true/false declaration from ovm3.3 so that future backport
doesn't have related conflicts.
This is a prerequisite for XSA-273
Signed-off-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.202]
- From 67f6df533ca10184b6fc5d9bb0ed2e54d49a582b Mon Sep 17 00:00:00 2001
From: Boris Ostrovsky
Date: Wed, 29 Aug 2018 03:12:24 +0800
Subject: [PATCH 18/18] x86/spectre: Fix SPEC_CTRL_ENTRY_FROM_INTR_IST macro
SPEC_CTRL_ENTRY_FROM_INTR_IST is trying to follow upstream implementation and
is using STACK_CPUINFO_FIELD macro to access cpuinfo's xen_spec_ctrl field.
Unfortunately, OVM's definition of this field is obsolete, we have not updated
to commit 4f6aea06 ('x86: reduce code size of struct cpu_info member accesses').
We are calculating end of stack as
movq -1, %r14;
orq %rsp, %r14;
which is open-coded implemetation of GET_STACK_END from the above commit and then
using older definition of STACK_CPUINFO_FIELD. This results in %eax getting
garbage, causing #GP when writing MSR 0x48.
Instead of backporting 4f6aea06 we should simply open-code STACK_CPUINFO_FIELD
as defined in that commit, especially since we do it elsewhere in this file.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Bhavesh Davda
Backported from OVM3.4 commit 37c139ca51ded61f1aa064d0718643054cdb852a
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.201]
- From 665bcb407b5d6c6e44103d8ccc25362c3e3fb291 Mon Sep 17 00:00:00 2001
From: Jan Beulich
Date: Tue, 29 May 2018 12:38:52 +0200
Subject: [PATCH 17/18] x86: correct default_xen_spec_ctrl calculation
Even with opt_msr_sc_{pv,hvm} both false we should set up the variable
as usual, to ensure proper one-time setup during boot and CPU bringup.
This then also brings the code in line with the comment immediately
ahead of the printk() being modified saying 'irrespective of guests'.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Release-acked-by: Juergen Gross
(cherry picked from commit d6239f64713df819278bf048446d3187c6ac4734)
Signed-off-by: Boris Ostrovsky
Reviewed-by: Patrick Colp
Reviewed-by: Ross Philipson
Conflict:
xen/arch/x86/spec_ctrl.c
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.200]
- From 8bc4615e37c19e025e938fb3f3cd623f3dac7162 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Fri, 13 Apr 2018 15:42:34 +0000
Subject: [PATCH 16/18] x86/msr: Virtualise MSR_SPEC_CTRL.SSBD for guests to use
Almost all infrastructure is already in place. Update the reserved bits
calculation in guest_wrmsr(), and offer SSBD to guests by default.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
(cherry picked from commit cd53023df952cf0084be9ee3d15a90f8837049c2)
This is XSA-263.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Ross Philipson
Acked-by: Adnan Misherfi
Conflicts:
- no MSR_INTEL_MISC_FEATURES_ENABLES in guest_wrmsr
- no cpufeatureset.h, set X86_FEATURE_SSBD in libxc
tools/libxc/xc_cpufeature.h
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.199]
- From 72d4cabf7b1c17aa197fc7b9d55b56aeb6df1bd1 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 28 Mar 2018 15:21:39 +0100
Subject: [PATCH 15/18] x86/Intel: Mitigations for GPZ SP4 - Speculative Store Bypass
To combat GPZ SP4 'Speculative Store Bypass', Intel have extended their
speculative sidechannel mitigations specification as follows:
* A feature bit to indicate that Speculative Store Bypass Disable is
supported.
* A new bit in MSR_SPEC_CTRL which, when set, disables memory disambiguation
in the pipeline.
* A new bit in MSR_ARCH_CAPABILITIES, which will be set in future hardware,
indicating that the hardware is not susceptible to Speculative Store Bypass
sidechannels.
For contemporary processors, this interface will be implemented via a
microcode update.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
(cherry picked from commit 9df52a25e0e95a0b9971aa2fc26c5c6a5cbdf4ef)
This is XSA-263.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Ross Philipson
Acked-by: Adnan Misherfi
Conflicts:
- No upstream's CPUID framework, we have our own. Implement
proper CPUID support for SSBD, OVM-specific.
xen/arch/x86/domctl.c
xen/include/asm-x86/msr-index.h
Removed __AC() to avoid compiler issue.
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.198]
- From 75c3669e79b88e72dbb658b71df52f6cc36fab53 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Thu, 26 Apr 2018 10:56:28 +0100
Subject: [PATCH 14/18] x86/AMD: Mitigations for GPZ SP4 - Speculative Store Bypass
AMD processors will execute loads and stores with the same base register in
program order, which is typically how a compiler emits code.
Therefore, by default no mitigating actions are taken, despite there being
corner cases which are vulnerable to the issue.
For performance testing, or for users with particularly sensitive workloads,
the command line option is available to force Xen to disable
Memory Disambiguation on applicable hardware.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
(cherry picked from commit 8c0e338086f060eba31d37b83fbdb883928aa085)
This is XSA-263.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Ross Philipson
Acked-by: Adnan Misherfi
Conflicts:
tools/libxl/libxl_cpuid.c
xen/arch/x86/spec_ctrl.c
xen/include/asm-x86/spec_ctrl.h
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.197]
- From 93fdacc4b8932d189faabc5a0ea5de92edf98b75 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Thu, 26 Apr 2018 10:52:55 +0100
Subject: [PATCH 13/18] x86/spec_ctrl: Introduce a new command line argument to replace
In hindsight, the options for aren't as flexible or useful as expected
(including several options which don't appear to behave as intended).
Changing the behaviour of an existing option is problematic for compatibility,
so introduce a new in the hopes that we can do better.
One common way of deploying Xen is with a single PV dom0 and all domUs being
HVM domains. In such a setup, an administrator who has weighed up the risks
may wish to forgo protection against malicious PV domains, to reduce the
overall performance hit. To cater for this usecase, will
disable all speculative protection for PV domains, while leaving all
speculative protection for HVM domains intact.
For coding clarity as much as anything else, the suboptions are grouped by
logical area; those which affect the alternatives blocks, and those which
affect Xen's in-hypervisor settings. See the xen-command-line.markdown for
full details of the new options.
While changing the command line options, take the time to change how the data
is reported to the user. The three DEBUG printks are upgraded to unilateral,
as they are all relevant pieces of information, and the old 'mitigations:'
line is split in the two logical areas described above.
Sample output from booting with looks like:
(XEN) Speculative mitigation facilities:
(XEN) Hardware features: IBRS/IBPB STIBP IBPB
(XEN) Compiled-in support: INDIRECT_THUNK
(XEN) Xen settings: BTI-Thunk RETPOLINE, SPEC_CTRL: IBRS-, Other: IBPB
(XEN) Support for VMs: PV: None, HVM: MSR_SPEC_CTRL RSB
(XEN) XPTI (64-bit PV only): Dom0 enabled, DomU enabled
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
Release-acked-by: Juergen Gross
(cherry picked from commit 3352afc26c497d26ecb70527db3cb29daf7b1422)
This is a prerequisite for XSA-263
Signed-off-by: Boris Ostrovsky
Reviewed-by: Ross Philipson
Acked-by: Adnan Misherfi
Conflicts:
xen/arch/x86/spec_ctrl.c - context conflicts
docs/misc/xen-command-line.markdown - doesn't exist in OVM3.2
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.196]
- From 5726e5cad730fed8872bc5ddd0fc3d4bc38aeabc Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Tue, 1 May 2018 11:59:03 +0100
Subject: [PATCH 12/18] x86/cpuid: Improvements to guest policies for speculative sidechannel features
If Xen isn't virtualising MSR_SPEC_CTRL for guests, IBRSB shouldn't be
advertised. It is not currently possible to express this via the existing
command line options, but such an ability will be introduced.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
Release-acked-by: Juergen Gross
(cherry picked from commit cb06b308ec71b23f37a44f5e2351fe2cae0306e9)
This is a prerequisite for XSA-263
Signed-off-by: Boris Ostrovsky
Reviewed-by: Ross Philipson
Acked-by: Adnan Misherfi
Based on 4.6 patch
Conflicts:
- No changes to xen/arch/x86/traps.c since we don't really
support PV mitigations
- Make changes to update_domain_cpuid_info() to tie X86_FEATURE_SC_MSR_HVM
to cp->feat.ibrsb
Conflicts:
xen/arch/x86/spec_ctrl.c
xen/include/asm-x86/spec_ctrl.h
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.195]
- From acaae4ac2c233deb96d68fb5a397a398e6c41b16 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Mon, 21 May 2018 15:07:13 -0400
Subject: [PATCH 11/18] x86/spec_ctrl: Explicitly set Xen's default MSR_SPEC_CTRL value
With the impending ability to disable MSR_SPEC_CTRL handling on a
per-guest-type basis, the first exit-from-guest may not have the side effect
of loading Xen's choice of value. Explicitly set Xen's default during the BSP
and AP boot paths.
For the BSP however, delay setting a non-zero MSR_SPEC_CTRL default until
after dom0 has been constructed when safe to do so. Oracle report that this
speeds up boots of some hardware by 50s.
'when safe to do so' is based on whether we are virtualised. A native boot
won't have any other code running in a position to mount an attack.
Reported-by: Zhenzhong Duan
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
Release-acked-by: Juergen Gross
From upstream commit cb8c12020307b39a89273d7699e89000451987ab
Mostly the same. Signigicant context differences in __start_xen
and start_secondary. Also had to add cpu_has_hypervisor.
This is a prerequisite for XSA-263
Signed-off-by: Ross Philipson
Reviewed-by: Boris Ostrovsky
Acked-by: Adnan Misherfi
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.194]
- From 7c0b46a7e06d6a46006f98c49c92b7c23cb2aac8 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Mon, 21 May 2018 14:45:14 -0400
Subject: [PATCH 10/18] x86/spec_ctrl: Split X86_FEATURE_SC_MSR into PV and HVM variants
In order to separately control whether MSR_SPEC_CTRL is virtualised for PV and
HVM guests, split the feature used to control runtime alternatives into two.
Xen will use MSR_SPEC_CTRL itself if either of these features are active.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
Release-acked-by: Juergen Gross
From upstream commit fa9eb09d446a1279f5e861e6b84fa8675dabf148
Mostly the same, context differences.
This is a prerequisite for XSA-263
Signed-off-by: Ross Philipson
Reviewed-by: Boris Ostrovsky
Acked-by: Adnan Misherfi
Conflict:
xen/arch/x86/spec_ctrl.c
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.193]
- From e14c6180ae460efaa70d611fd939d2c5e0136525 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Mon, 21 May 2018 14:32:02 -0400
Subject: [PATCH 09/18] x86/spec_ctrl: Elide MSR_SPEC_CTRL handling in idle context when possible
If Xen is virtualising MSR_SPEC_CTRL handling for guests, but using 0 as its
own MSR_SPEC_CTRL value, spec_ctrl_{enter,exit}_idle() need not write to the
MSR.
Requested-by: Jan Beulich
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
Release-acked-by: Juergen Gross
From upstream commit 94df6e8588e35cc2028ccb3fd2921c6e6360605e
Mostly the same, context differences.
This is a prerequisite for XSA-263
Signed-off-by: Ross Philipson
Reviewed-by: Boris Ostrovsky
Acked-by: Adnan Misherfi
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.192]
- From a88a6411ddc267c7c9fa1112e2d92dc9a0a5e605 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Mon, 21 May 2018 13:45:48 -0400
Subject: [PATCH 08/18] x86/spec_ctrl: Rename bits of infrastructure to avoid NATIVE and VMEXIT
In hindsight, using NATIVE and VMEXIT as naming terminology was not clever.
A future change wants to split SPEC_CTRL_EXIT_TO_GUEST into PV and HVM
specific implementations, and using VMEXIT as a term is completely wrong.
Take the opportunity to fix some stale documentation in spec_ctrl_asm.h. The
IST helpers were missing from the large comment block, and since
SPEC_CTRL_ENTRY_FROM_INTR_IST was introduced, we've gained a new piece of
functionality which currently depends on the fine grain control, which exists
in lieu of livepatching. Note this in the comment.
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
Release-acked-by: Juergen Gross
From upstream commit d9822b8a38114e96e4516dc998f4055249364d5d
Mostly the same, context differences. Had to add NOP40 to the new
SPEC_CTRL_EXIT_TO_HVM macro.
This is a prerequisite for XSA-263
Signed-off-by: Ross Philipson
Reviewed-by: Boris Ostrovsky
Acked-by: Adnan Misherfi
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.191]
- From a42a28434470853e4fcf099e5b13dea475682165 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Mon, 21 May 2018 12:46:33 -0400
Subject: [PATCH 07/18] x86/spec_ctrl: Fold the XEN_IBRS_{SET,CLEAR} ALTERNATIVES together
Currently, the SPEC_CTRL_{ENTRY,EXIT}_* macros encode Xen's choice of
MSR_SPEC_CTRL as an immediate constant, and chooses between IBRS or not by
doubling up the entire alternative block.
There is now a variable holding Xen's choice of value, so use that and
simplify the alternatives.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
Release-acked-by: Juergen Gross
From upstream commit af949407eaba7af71067f23d5866cd0bf1f1144d
Backport is mostly the same. The assembly in DO_SPEC_CTRL_ENTRY had to be done
differently to accomodate the code flow in our version. Also had to
add NOP40 to a number of the SPEC_CTRL_* macros.
This is a prerequisite for XSA-263
Signed-off-by: Ross Philipson
Reviewed-by: Boris Ostrovsky
Acked-by: Adnan Misherfi
Conflicts:
xen/include/asm-x86/current.h
xen/include/asm-x86/spec_ctrl.h
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.190]
- From 87cb80a1cb77bfb001beefc0b9667fc3f350ec4c Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Mon, 21 May 2018 11:53:26 -0400
Subject: [PATCH 06/18] x86/spec_ctrl: Merge bti_ist_info and use_shadow_spec_ctrl into spec_ctrl_flags
All 3 bits of information here are control flags for the entry/exit code
behaviour. Treat them as such, rather than having two different variables.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
Release-acked-by: Juergen Gross
From upstream commit 5262ba2e7799001402dfe139ff944e035dfff928
Most of the backport is the same. There were some trickly differences in
logic in spec_ctrl_asm.h that had to be handled carefully. The changes
in acpi/power.c were not use.
This is a prerequisite for XSA-263
Signed-off-by: Ross Philipson
Reviewed-by: Boris Ostrovsky
Acked-by: Adnan Misherfi
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.189]
- From c4c6a62d0f74a89b3a029fdfac2a2cbaf2015184 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Mon, 21 May 2018 11:52:30 -0400
Subject: [PATCH 05/18] x86/spec_ctrl: Express Xen's choice of MSR_SPEC_CTRL value as a variable
At the moment, we have two different encodings of Xen's MSR_SPEC_CTRL value,
which is a side effect of how the Spectre series developed. One encoding is
via an alias with the bottom bit of bti_ist_info, and can encode IBRS or not,
but not other configurations such as STIBP.
Break Xen's value out into a separate variable (in the top of stack block for
XPTI reasons) and use this instead of bti_ist_info in the IST path.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
Release-acked-by: Juergen Gross
From upstream commit 66dfae0f32bfbc899c2f3446d5ee57068cb7f957
No differences from original.
This is a prerequisite for XSA-263
Signed-off-by: Ross Philipson
Reviewed-by: Boris Ostrovsky
Conflicts:
xen/arch/x86/spec_ctrl.c
xen/include/asm-x86/current.h
xen/include/asm-x86/spec_ctrl.h
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.188]
- From 0258ecec372bac1461cd1c733897db1f36ed7937 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Mon, 21 May 2018 11:51:56 -0400
Subject: [PATCH 04/18] x86/spec_ctrl: Read MSR_ARCH_CAPABILITIES only once
Make it available from the beginning of init_speculation_mitigations(), and
pass it into appropriate functions. Fix an RSBA typo while moving the
affected comment.
Signed-off-by: Andrew Cooper
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
Release-acked-by: Juergen Gross
From upstream commit d6c65187252a6c1810fd24c4d46f812840de8d3c
No differences from original.
This is a prerequisite for XSA-263
Signed-off-by: Ross Philipson
Reviewed-by: Boris Ostrovsky
Acked-by: Adnan Misherfi
Conflict:
xen/arch/x86/spec_ctrl.c
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.187]
- From a365eb8e723691c71b2374a1c39b7262a29b3373 Mon Sep 17 00:00:00 2001
From: Boris Ostrovsky
Date: Mon, 21 May 2018 11:27:50 -0400
Subject: [PATCH 03/18] x86/spec_ctrl: Assume that STIBP feature is always available
To simplify MSR_SPEC_CTRL handling always present the guest
with STIBP feature as available if IBRS is present.
(See upstream commit d297b56682e7 ('x86/cpuid: Handling of IBRS/IBPB,
STIBP and IBRS for guests')
This is a prerequisite for XSA-263
Signed-off-by: Boris Ostrovsky
Reviewed-by: Ross Philipson
Acked-by: Adnan Misherfi
Conflicts:
xen/arch/x86/domctl.c
xen/arch/x86/hvm/vmx/vmx.c
xen/include/asm-x86/msr.h
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.186]
- From 80391fccc66d86781a6215061a885349a9297397 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Mon, 21 May 2018 11:26:56 -0400
Subject: [PATCH 02/18] x86/spec_ctrl: Updates to retpoline-safety decision making
All of this is as recommended by the Intel whitepaper:
https://software.intel.com/sites/default/files/managed/1d/46/Retpoline-A-Branch-Target-Injection-Mitigation.pdf
The 'RSB Alternative' bit in MSR_ARCH_CAPABILITIES may be set by a hypervisor
to indicate that the virtual machine may migrate to a processor which isn't
retpoline-safe. Introduce a shortened name (to reduce code volume), treat it
as authorative in retpoline_safe(), and print its value along with the other
ARCH_CAPS bits.
The exact processor models which do have RSB semantics which fall back to BTB
predictions are enumerated, and include Kabylake and Coffeelake. Leave a
printk() in the default case to help identify cases which aren't covered.
The exact microcode versions from Broadwell RSB-safety are taken from the
referenced microcode update file (adjusting for the known-bad microcode
versions). Despite the exact wording of the text, it is only Broadwell
processors which need a microcode check.
In practice, this means that all Broadwell hardware with up-to-date microcode
will use retpoline in preference to IBRS, which will be a performance
improvement for desktop and server systems which would previously always opt
for IBRS over retpoline.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Release-acked-by: Juergen Gross
From upstream commit 1232378bd2fef45f613db049b33852fdf84d7ddf
No significant differences from original. Had to add some
MSR register defines.
This is a prerequisite for XSA-263
Signed-off-by: Ross Philipson
Also include backport of upstream's 27170adb54a5 ('x86/spec_ctrl:
Fix typo in ARCH_CAPS decode')
Signed-off-by: Boris Ostrovsky
Reviewed-by: Ross Philipson
Acked-by: Adnan Misherfi
Conflict:
xen/arch/x86/spec_ctrl.c
Removed __AC() to avoid compiler issue.
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.185]
- From 01d76ca4b02343dbab5bb4532c1aa793f6ea8023 Mon Sep 17 00:00:00 2001
From: Boris Ostrovsky
Date: Wed, 23 May 2018 14:28:03 -0400
Subject: [PATCH 01/18] Revert 'x86/boot: Disable IBRS in intr/nmi exit path at bootup stage'
This reverts commit bd3938aea66e9fd7e569e18f3333a7430e2690bf.
The subsequent series will provide the same functionality (see
introduction of bsp_delay_spec_ctrl variable in 'x86/spec_ctrl:
Explicitly set Xen's default MSR_SPEC_CTRL value' patch)
This is a prerequisite for XSA-263
Signed-off-by: Boris Ostrovsky
Reviewed-by: Konrad Rzeszutek Wilk
Acked-by: Adnan Misherfi
Backported-by: Zhenzhong Duan
Reviewed-by: Ross Philipson
[4.1.3-25.el5.223.184]
- x86/HVM: Restart ioreq processing state machine
XSA-262 (commit 0c1b2f70 ('x86/HVM: guard against emulator
driving ioreq state in weird ways') introduced a check on ioreq state to
make sure the state's numerical value never goes back. This was done to
prevent malicious qemu from triggering an infinite loop in the
hypervisor.
However, there is, in fact, a case when the state may be reset back to
STATE_IOREQ_READY after STATE_IORESP_READY, and that is when hvm_io_assist()
queues another request. This will cause another iteration of the loop,
resulting in 'Weird HVM ioreq state transition' warning followed by
domain termination.
To avoid this, reset prev_state back to STATE_IOREQ_NONE.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Ross Philipson
Acked-by: Adnan Misherfi
This patch is backported from OVS345.
OVS345 commit: 67e64eec4bfe342ca6c2ff0858ae7f5c39041013
This patch is used to fix an error in previous OVS345 backport.
Backported-by: Dongli Zhang
Reviewed-by: Patrick Colp
[4.1.3-25.el5.223.183]
- x86/HVM: guard against emulator driving ioreq state in weird ways
In the case where hvm_wait_for_io() calls wait_on_xen_event_channel(),
p->state ends up being read twice in succession: once to determine that
state != p->state, and then again at the top of the loop. This gives a
compromised emulator a chance to change the state back between the two
reads, potentially keeping Xen in a loop indefinitely.
Instead:
* Read p->state once in each of the wait_on_xen_event_channel() tests,
* re-use that value the next time around,
* and insist that the states continue to transition 'forward' (with the
exception of the transition to STATE_IOREQ_NONE).
This is XSA-262.
Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
Conflicts:
- hvm_wait_for_io() does not exist, we have the loop in hvm_do_resume();
- struct vcpu does not have 'pending' member;
- we dont check for STATE_IOREQ_NONE in the loop;
Signed-off-by: Elena Ufimtseva
Acked-by: Adnan Misherfi
Reviewed-by: Ross Philipson
Reviewed-by: Patrick Colp
This patch is backported from OVS345.
upstream commit: 92938e5d149669033aecdfb3d1396948d49d1887
OVS345 commit: 0c1b2f70b50bab700bf317050569b741b1ef07d3
Conflicting files:
- xen/arch/x86/hvm/hvm.c
Conflicts:
- pt_restore_timer(v) vs. check_wakeup_from_wait()
Backported-by: Dongli Zhang