[Oraclevm-errata] OVMSA-2018-0272 Important: Oracle VM 3.2 xen security update
Errata Announcements for Oracle VM
oraclevm-errata at oss.oracle.com
Wed Nov 14 08:50:22 PST 2018
Oracle VM Security Advisory OVMSA-2018-0272
The following updated rpms for Oracle VM 3.2 have been uploaded to the
Unbreakable Linux Network:
x86_64:
xen-4.1.3-25.el5.223.214.x86_64.rpm
xen-devel-4.1.3-25.el5.223.214.x86_64.rpm
xen-tools-4.1.3-25.el5.223.214.x86_64.rpm
SRPMS:
http://oss.oracle.com/oraclevm/server/3.2/SRPMS-updates/xen-4.1.3-25.el5.223.214.src.rpm
Description of changes:
[4.1.3-25.el5.223.214]
- From 45c551670427f54f48c47ac5430e66ecd4a45e00 Mon Sep 17 00:00:00 2001
From: Jan Beulich <jbeulich at suse.com>
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 <jbeulich at suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovksy at oracle.com>
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 <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28555350] {CVE-2018-3665}
[4.1.3-25.el5.223.213]
- From 136de08b33138d72c3bb221bc8dd3c851537b228 Mon Sep 17 00:00:00 2001
From: Jan Beulich <jbeulich at suse.com>
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 <carnold at suse.com>
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Cherry-picked from: 598a375f5230d91ac88e76a9f4b4dde4a62a4c5b
These are followup fixes for Lazy FPU/XSA-267
Signed-off-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovksy at oracle.com>
Backported from OVM3.4.5 commit f9f5f0bb3188437559ca74021b24b83fe52947d4
Conflicts:
arch/x86/hvm/vmx/vmx.c
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28555350] {CVE-2018-3665}
[4.1.3-25.el5.223.212]
- From 2b86542d60564af211219dd37f713bfb3d2c8010 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
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 <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28555350] {CVE-2018-3665}
[4.1.3-25.el5.223.211]
- From c3d5db5e5e0800cbb07a0d8a6b0e87e1ec2b3133 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
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 <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28555350] {CVE-2018-3665}
[4.1.3-25.el5.223.210]
- From b66a5d032e8b31735330e208050c354373ffbc7a Mon Sep 17 00:00:00 2001
From: Julien Grall <julien.grall at linaro.org>
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 <julien.grall at linaro.org>
Acked-by: Keir Fraser <keir at xen.org>
CC: Jan Beulich <jbeulich at suse.com>
This is a prerequisite for XSA-273
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574303] {CVE-2018-3620}
[4.1.3-25.el5.223.209]
- From 3051fa2d29044c7fdcec51ea9d1096560f7edee0 Mon Sep 17 00:00:00 2001
From: Ross Philipson <ross.philipson at oracle.com>
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 <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Conflicts:
tools/misc/Makefile
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574303] {CVE-2018-3646} {CVE-2018-3620}
[4.1.3-25.el5.223.208]
- From 5582b2ee6f2f2482a37bcc8f28e1e75e3351f70c Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <andrew.cooper3 at citrix.com>
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 <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
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 <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574303] {CVE-2018-3646} {CVE-2018-3620}
[4.1.3-25.el5.223.207]
- From a25c8e13df013b8c7af9627fd7597829e869498c Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <andrew.cooper3 at citrix.com>
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 <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
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 <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574303] {CVE-2018-3646} {CVE-2018-3620}
[4.1.3-25.el5.223.206]
- From 47a0500460a19ee2396ef1dad5283452e27ab2e6 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
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 <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Conflicts:
xen/include/asm-x86/msr-index.h - context
docs/misc/xen-command-line.markdown not exist
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574303] {CVE-2018-3646} {CVE-2018-3620}
[4.1.3-25.el5.223.205]
- From 9f6240b1b05bc54b1823d6bf34a056899aaa9a70 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <andrew.cooper3 at citrix.com>
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 <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Conflits:
xen/arch/x86/spec_ctrl.c
No should_use_eager_fpu(), ignore related chunk
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574303] {CVE-2018-3646} {CVE-2018-3620}
[4.1.3-25.el5.223.204]
- From 226222419e04c1b04879b968b44373757c93a7a3 Mon Sep 17 00:00:00 2001
From: Jan Beulich <JBeulich at suse.com>
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 <jbeulich at suse.com>
Reviewed-by: Roger Pau Monn?195?169 <roger.pau at citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Joao Martins <joao.m.martins at oracle.com>
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 <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574303] {CVE-2018-3646} {CVE-2018-3620}
[4.1.3-25.el5.223.203]
- From 0009c9638533cec96bb30ea8451c9c05b39b83dd Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan <zhenzhong.duan at oracle.com>
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 <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574303] {CVE-2018-3620}
[4.1.3-25.el5.223.202]
- From 67f6df533ca10184b6fc5d9bb0ed2e54d49a582b Mon Sep 17 00:00:00 2001
From: Boris Ostrovsky <boris.ostrovsky at oracle.com>
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 $STACK_SIZE-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 <boris.ostrovsky at oracle.com>
Reviewed-by: Bhavesh Davda <bhavesh.davda at oracle.com>
Backported from OVM3.4 commit 37c139ca51ded61f1aa064d0718643054cdb852a
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.201]
- From 665bcb407b5d6c6e44103d8ccc25362c3e3fb291 Mon Sep 17 00:00:00 2001
From: Jan Beulich <jbeulich at suse.com>
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 <jbeulich at suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Release-acked-by: Juergen Gross <jgross at suse.com>
(cherry picked from commit d6239f64713df819278bf048446d3187c6ac4734)
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Patrick Colp <patrick.colp at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Conflict:
xen/arch/x86/spec_ctrl.c
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.200]
- From 8bc4615e37c19e025e938fb3f3cd623f3dac7162 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
(cherry picked from commit cd53023df952cf0084be9ee3d15a90f8837049c2)
This is XSA-263.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
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 <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.199]
- From 72d4cabf7b1c17aa197fc7b9d55b56aeb6df1bd1 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
(cherry picked from commit 9df52a25e0e95a0b9971aa2fc26c5c6a5cbdf4ef)
This is XSA-263.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
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 <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.198]
- From 75c3669e79b88e72dbb658b71df52f6cc36fab53 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 `spec-ctrl=ssbd` command line option is available to force Xen to
disable
Memory Disambiguation on applicable hardware.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
(cherry picked from commit 8c0e338086f060eba31d37b83fbdb883928aa085)
This is XSA-263.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Conflicts:
tools/libxl/libxl_cpuid.c
xen/arch/x86/spec_ctrl.c
xen/include/asm-x86/spec_ctrl.h
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.197]
- From 93fdacc4b8932d189faabc5a0ea5de92edf98b75 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
Date: Thu, 26 Apr 2018 10:52:55 +0100
Subject: [PATCH 13/18] x86/spec_ctrl: Introduce a new `spec-ctrl=`
command line argument to replace `bti=`
In hindsight, the options for `bti=` 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 `spec-ctrl=` 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,
`spec-ctrl=no-pv` 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 `spec-ctrl=no-pv` 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 <andrew.cooper3 at citrix.com>
Reviewed-by: Wei Liu <wei.liu2 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Release-acked-by: Juergen Gross <jgross at suse.com>
(cherry picked from commit 3352afc26c497d26ecb70527db3cb29daf7b1422)
This is a prerequisite for XSA-263
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
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 <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.196]
- From 5726e5cad730fed8872bc5ddd0fc3d4bc38aeabc Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <andrew.cooper3 at citrix.com>
Reviewed-by: Wei Liu <wei.liu2 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Release-acked-by: Juergen Gross <jgross at suse.com>
(cherry picked from commit cb06b308ec71b23f37a44f5e2351fe2cae0306e9)
This is a prerequisite for XSA-263
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
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 <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.195]
- From acaae4ac2c233deb96d68fb5a397a398e6c41b16 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <zhenzhong.duan at oracle.com>
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Wei Liu <wei.liu2 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Release-acked-by: Juergen Gross <jgross at suse.com>
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 <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.194]
- From 7c0b46a7e06d6a46006f98c49c92b7c23cb2aac8 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <andrew.cooper3 at citrix.com>
Reviewed-by: Wei Liu <wei.liu2 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Release-acked-by: Juergen Gross <jgross at suse.com>
From upstream commit fa9eb09d446a1279f5e861e6b84fa8675dabf148
Mostly the same, context differences.
This is a prerequisite for XSA-263
Signed-off-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Conflict:
xen/arch/x86/spec_ctrl.c
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.193]
- From e14c6180ae460efaa70d611fd939d2c5e0136525 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <JBeulich at suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Wei Liu <wei.liu2 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Release-acked-by: Juergen Gross <jgross at suse.com>
From upstream commit 94df6e8588e35cc2028ccb3fd2921c6e6360605e
Mostly the same, context differences.
This is a prerequisite for XSA-263
Signed-off-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.192]
- From a88a6411ddc267c7c9fa1112e2d92dc9a0a5e605 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <andrew.cooper3 at citrix.com>
Reviewed-by: Wei Liu <wei.liu2 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Release-acked-by: Juergen Gross <jgross at suse.com>
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 <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.191]
- From a42a28434470853e4fcf099e5b13dea475682165 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <andrew.cooper3 at citrix.com>
Reviewed-by: Wei Liu <wei.liu2 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Release-acked-by: Juergen Gross <jgross at suse.com>
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 <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Conflicts:
xen/include/asm-x86/current.h
xen/include/asm-x86/spec_ctrl.h
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.190]
- From 87cb80a1cb77bfb001beefc0b9667fc3f350ec4c Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <andrew.cooper3 at citrix.com>
Reviewed-by: Wei Liu <wei.liu2 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Release-acked-by: Juergen Gross <jgross at suse.com>
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 <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.189]
- From c4c6a62d0f74a89b3a029fdfac2a2cbaf2015184 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <andrew.cooper3 at citrix.com>
Reviewed-by: Wei Liu <wei.liu2 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Release-acked-by: Juergen Gross <jgross at suse.com>
From upstream commit 66dfae0f32bfbc899c2f3446d5ee57068cb7f957
No differences from original.
This is a prerequisite for XSA-263
Signed-off-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Conflicts:
xen/arch/x86/spec_ctrl.c
xen/include/asm-x86/current.h
xen/include/asm-x86/spec_ctrl.h
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.188]
- From 0258ecec372bac1461cd1c733897db1f36ed7937 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <andrew.cooper3 at citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Reviewed-by: Wei Liu <wei.liu2 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Release-acked-by: Juergen Gross <jgross at suse.com>
From upstream commit d6c65187252a6c1810fd24c4d46f812840de8d3c
No differences from original.
This is a prerequisite for XSA-263
Signed-off-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Conflict:
xen/arch/x86/spec_ctrl.c
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.187]
- From a365eb8e723691c71b2374a1c39b7262a29b3373 Mon Sep 17 00:00:00 2001
From: Boris Ostrovsky <boris.ostrovsky at oracle.com>
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 <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Conflicts:
xen/arch/x86/domctl.c
xen/arch/x86/hvm/vmx/vmx.c
xen/include/asm-x86/msr.h
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.186]
- From 80391fccc66d86781a6215061a885349a9297397 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
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 <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Release-acked-by: Juergen Gross <jgross at suse.com>
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 <ross.philipson at oracle.com>
Also include backport of upstream's 27170adb54a5 ("x86/spec_ctrl:
Fix typo in ARCH_CAPS decode")
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Conflict:
xen/arch/x86/spec_ctrl.c
Removed __AC() to avoid compiler issue.
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[4.1.3-25.el5.223.185]
- From 01d76ca4b02343dbab5bb4532c1aa793f6ea8023 Mon Sep 17 00:00:00 2001
From: Boris Ostrovsky <boris.ostrovsky at oracle.com>
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 <boris.ostrovsky at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061099] {CVE-2018-3639}
[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 <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
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 <dongli.zhang at oracle.com>
Reviewed-by: Patrick Colp <patrick.colp at oracle.com> [bug 27989762]
{CVE-2018-10981}
[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 <jbeulich at suse.com>
Reviewed-by: George Dunlap <george.dunlap at citrix.com>
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 <elena.ugfimtseva at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Patrick Colp <patrick.colp at oracle.com>
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 <dongli.zhang at oracle.com>
Reviewed-by: Patrick Colp <patrick.colp at oracle.com> [bug 27989762]
{CVE-2018-10981}
[4.1.3-25.el5.223.182]
- x86/vpt: add support for IO-APIC routed interrupts
And modify the HPET code to make use of it. Currently HPET interrupts
are always treated as ISA and thus injected through the vPIC. This is
wrong because HPET interrupts when not in legacy mode should be
injected from the IO-APIC.
To make things worse, the supported interrupt routing values are set
to [20..23], which clearly falls outside of the ISA range, thus
leading to an ASSERT in debug builds or memory corruption in non-debug
builds because the interrupt injection code will write out of the
bounds of the arch.hvm_domain.vpic array.
Since the HPET interrupt source can change between ISA and IO-APIC
always destroy the timer before changing the mode, or else Xen risks
changing it while the timer is active.
Note that vpt interrupt injection is racy in the sense that the
vIO-APIC RTE entry can be written by the guest in between the call to
pt_irq_masked and hvm_ioapic_assert, or the call to pt_update_irq and
pt_intr_post. Those are not deemed to be security issues, but rather
quirks of the current implementation. In the worse case the guest
might lose interrupts or get multiple interrupt vectors injected for
the same timer source.
This is part of XSA-261.
Address actual and potential compiler warnings. Fix formatting.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Patrick Colp <patrick.colp at oracle.com>
This patch is backported from OVS345.
upstream commit: 14c3f68a57361f20be33ec3848f83d8636a0d34e
OVS345 commit: 8f36ff7f3ab2d929d46acba5abdcb5a986c2d1fb
Conflicting files:
- xen/arch/x86/hvm/vpt.c
- xen/include/asm-x86/hvm/irq.h
Conflicts:
- earliest_pt is initialized as NULL
- max_lag is initialized as -1ULL
- if ( is_lapic ) has different pattern of braces
- platform_legacy_irq(irq) && vlapic_accept_pic_intr(v) &&...
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Patrick Colp <patrick.colp at oracle.com> [bug 27989691]
{CVE-2018-10982}
[4.1.3-25.el5.223.181]
- xen: add virtual x2apic support for apicv
basically to benefit from apicv, we need clear MSR bitmap for
corresponding x2apic MSRs:
0x800 - 0x8ff: no read intercept for apicv register virtualization
TPR,EOI,SELF-IPI: no write intercept for virtual interrupt
delivery
Signed-off-by: Jiongxi Li <jiongxi.li at intel.com>
Committed-by: Keir Fraser <keir at xen.org>
upstream commit: c892426ce32dc68487613a95c1bf6441e8b15e43
This is prerequisite patch for XSA-261.
Conflicting files:
- xen/arch/x86/hvm/vmx/vmcs.c
- xen/arch/x86/hvm/vmx/vmx.c
- xen/include/asm-x86/hvm/vmx/vmcs.h
Conflicts:
- condition is not ( cpu_has_vmx_pat && paging_mode_hap(d) )
- vmx_disable_intercept_for_msr() is used at more locations than the
original patch
- vmx_add_guest_msr() is not declared
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Patrick Colp <patrick.colp at oracle.com> [bug 27989691]
{CVE-2018-10982}
[4.1.3-25.el5.223.180]
- xen: enable Virtual-interrupt delivery
Virtual interrupt delivery avoids Xen to inject vAPIC interrupts
manually, which is fully taken care of by the hardware. This needs
some special awareness into existing interrupr injection path:
For pending interrupt from vLAPIC, instead of direct injection, we may
need update architecture specific indicators before resuming to guest.
Before returning to guest, RVI should be updated if any pending IRRs
EOI exit bitmap controls whether an EOI write should cause VM-Exit. If
set, a trap-like induced EOI VM-Exit is triggered. The approach here
is to manipulate EOI exit bitmap based on value of TMR. Level
triggered irq requires a hook in vLAPIC EOI write, so that vIOAPIC EOI
is triggered and emulated
Signed-off-by: Gang Wei <gang.wei at intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang at intel.com>
Signed-off-by: Jiongxi Li <jiongxi.li at intel.com>
Committed-by: Keir Fraser <keir at xen.org>
upstream commit: 25b81a7941d71fabd4c8c56e9d3d76801d061842
This is prerequisite patch for XSA-261.
Conflicting files:
- xen/arch/x86/hvm/vmx/vmx.c
- xen/include/asm-x86/hvm/hvm.h
- xen/include/asm-x86/hvm/vmx/vmcs.h
Conclicts:
- some methods not implemented for vmx_function_table
- some methods not defined in struct hvm_function_table
- vmx_vmcs_switch() is not declared
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Patrick Colp <patrick.colp at oracle.com> [bug 27989691]
{CVE-2018-10982}
[4.1.3-25.el5.223.179]
- xen: enable APIC-Register Virtualization
Add APIC register virtualization support
- APIC read doesn't cause VM-Exit
- APIC write becomes trap-like
Signed-off-by: Gang Wei <gang.wei at intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang at intel.com>
Signed-off-by: Jiongxi Li <jiongxi.li at intel.com>
upstream commit: f62b02e177cd03da2b8397b9bdf1a53b541df3f3
This is prerequisite patch for XSA-261.
Conflicting files:
- xen/arch/x86/hvm/vmx/vmx.c
- xen/include/asm-x86/hvm/vmx/vmcs.h
- xen/include/asm-x86/hvm/vmx/vmx.h
Conflicts:
- local variable 'mode' not defined in vmx_vmexit_handler()
- hvm_inject_hw_exception() is not available
- SECONDARY_EXEC_ENABLE_INVPCID is not defined
- EXIT_REASON_INVPCID is not defined
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Patrick Colp <patrick.colp at oracle.com> [bug 27989691]
{CVE-2018-10982}
[4.1.3-25.el5.223.178]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
Subject: x86/traps: Fix handling of #DB exceptions in hypervisor context
The WARN_ON() can be triggered by guest activities, and emits a full
stack
trace without rate limiting. Swap it out for a ratelimited printk
with just
enough information to work out what is going on.
Not all #DB exceptions are traps, so blindly continuing is not a safe
action
to take. We don't let PV guests select these settings in the real
%dr7 to
begin with, but for added safety against unexpected situations,
detect the
fault cases and crash in an obvious manner.
This is part of XSA-260 / CVE-2018-8897.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
27989670] {CVE-2018-8897}
[4.1.3-25.el5.223.177]
- From: Andrew Cooper <andrew.cooper2 at citrix.com>
Subject: x86/traps: Use an Interrupt Stack Table for #DB
PV guests can use architectural corner cases to cause #DB to be
raised after
transitioning into supervisor mode.
Use an interrupt stack table for #DB to prevent the exception being
taken with
a guest controlled stack pointer.
This is part of XSA-260 / CVE-2018-8897.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Conflict:
xen/arch/x86/cpu/common.c
xen/arch/x86/x86_64/traps.c
xen/arch/x86/hvm/svm/svm.c
Changes for xen/arch/x86/cpu/common.c moved to
xen/arch/x86/x86_64/traps.c for
OVM3.3.
There are no get_stack_trace_bottom() and get_stack_dump_bottom() in
OVM3.3,
the related chunks for xen/arch/x86/traps.c are ignored.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
27989670] {CVE-2018-8897}
[4.1.3-25.el5.223.176]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
Subject: x86/pv: Move exception injection into
{,compat_}test_all_events()
This allows paths to jump straight to {,compat_}test_all_events() and
have
injection of pending exceptions happen automatically, rather than
requiring
all calling paths to handle exceptions themselves.
The normal exception path is simplified as a result, and
compat_post_handle_exception() is removed entirely.
This is part of XSA-260 / CVE-2018-8897.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Conflicts:
xen/arch/x86/x86_64/compat/entry.S
xen/arch/x86/x86_64/entry.S
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
27989670] {CVE-2018-8897}
[4.1.3-25.el5.223.175]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
Subject: x86/traps: Fix %dr6 handing in #DB handler
Most bits in %dr6 accumulate, rather than being set directly based on the
current source of #DB. Have the handler follow the manuals guidance,
which
avoids leaking hypervisor debugging activities into guest context.
This is part of XSA-260 / CVE-2018-8897.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Conflict:
xen/arch/x86/traps.c
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
27989670] {CVE-2018-8897}
[4.1.3-25.el5.223.174]
- From 2313478dc93085d2a9bf407d76c34f6bf50e85a8 Mon Sep 17 00:00:00 2001
From: Jan Beulich <jbeulich at suse.com>
Date: Thu, 26 Mar 2015 11:08:28 +0100
Subject: [PATCH] introduce gprintk()
... and convert several gdprintk()-s to it, as the next patch will make
them no-ops in non-debug builds.
Note that as a non-debug facility this does not print file name and
line number of the origin, to people are expected to use meaningful and
easily distinguishable messages (i.e. just like with plain printk()).
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
This is a partial port of upstream commit, define gprintk()
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
27989670] {CVE-2018-8897}
[4.1.3-25.el5.223.173]
- From: Jan Beulich <jbeulich at suse.com>
Subject: gnttab: don't blindly free status pages upon version change
There may still be active mappings, which would trigger the respective
BUG_ON(). Split the loop into one dealing with the page attributes and
the second (when the first fully passed) freeing the pages. Return an
error if any pages still have pending references.
This is part of XSA-255.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Conflict:
xen/common/grant_table.c
xsa255-4.6-1.patch and ARM related chunks are ignored.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
27834983] {CVE-2018-7541}
[4.1.3-25.el5.223.172]
- From 177bd5fb7b991e6ac461ede4d2b70c0ec5bfc294 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
Date: Fri, 5 Jun 2015 12:10:33 +0200
Subject: [PATCH] mem: expose typesafe mfns/gfns/pfns to common code
As the first step of memory management cleanup, introduce the common
code to
mfn_t, gfn_t and pfn_t.
The typesafe construction moves to its own header file, while the
declarations
and sentinal values are moved to being common.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Tim Deegan <tim at xen.org>
Conflicts:
xen/include/asm-x86/guest_pt.h
xen/include/asm-x86/mm.h
xen/include/asm-x86/paging.h
xen/include/xen/mm.h
Prerequisite patch for XSA-255, add gfn_t
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
27834983] {CVE-2018-7541}
[4.1.3-25.el5.223.171]
- From: Jan Beulich <jbeulich at suse.com>
Subject: memory: don't implicitly unpin for decrease-reservation
It very likely was a mistake (copy-and-paste from domain cleanup code)
to implicitly unpin here: The caller should really unpin itself before
(or after, if they so wish) requesting the page to be removed.
This is XSA-252.
Reported-by: Jann Horn <jannh at google.com>
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
27835039] {CVE-2018-7540}
More information about the Oraclevm-errata
mailing list