OVMSA-2018-0029

OVMSA-2018-0029 - xen security update

Type:SECURITY
Severity:IMPORTANT
Release Date:2018-04-05

Description


[4.1.3-25.el5.223.166]
- From 1e82fe31ed498bd1881c386a94b505e0c769f7bd Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan
Date: Wed, 21 Mar 2018 19:05:06 -0700
Subject: [PATCH 80/80] x86/boot: Disable IBRS in intr/nmi exit path at bootup stage
After reset, IBRS is disabled by processor, but a coming intr/nmi leave IBRS
enabled after their exit. Its not necessory for bootup code to run in low
performance with IBRS enabled.
On ORACLE X6-2(500GB/88 cpus, dom0 11GB/20 vcpus), we observed an 200s+ delay
in construct_dom0.
By initializing use_shadow_spec_ctrl with 1, IBRS is disabled in intr/nmi exit
path. Then delay in construct_dom0 is ~50s.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky
Acked-by: Adnan Misherfi
(cherry picked from commit 52404341e0c4aced6a4ac9897d7b79be512f4e8b)
OraBug: 27751103
Signed-off-by: Patrick Colp
Reviewed-by: Boris Ostrovsky [bug 27751103]

[4.1.3-25.el5.223.165]
- From 2c8d5b6ac15ea746440cdc2dc4a823786c8360cd Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan
Date: Wed, 21 Mar 2018 20:30:22 -0700
Subject: [PATCH 79/80] Fix a wrong check in DO_SPEC_CTRL_EXIT_TO_XEN
The testb instruction in DO_SPEC_CTRL_EXIT_TO_XEN is wrong and it always set
ZF, the following je instruction will always jump.
%rsp doesnt point to cpuinfo struct in intr/nmi context, we need to calculate
a correct pointer for cpuinfo struct.
This patch fix above two issues.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky
Acked-by: Adnan Misherfi
(cherry picked from commit 222bb10d34ac0eae6dd1147ecfa65788f4b9785c)
OraBug: 27751103
This is part of XSA-254.
Signed-off-by: Patrick Colp
Reviewed-by: Boris Ostrovsky [bug 27751103] {CVE-2017-5715}

[4.1.3-25.el5.223.164]
- From 9c04d7b5ac9dd3ea5cb6c9486f21c21fb1e9786e Mon Sep 17 00:00:00 2001
From: Patrick Colp
Date: Thu, 8 Mar 2018 11:08:39 -0800
Subject: [PATCH] x86/hypercall: Add xen/perfc.h to fix compile error
Depending on the setup, compiling xen/arch/x86/hypercall.c will fail
in the following way:
hypercall.c: In function pv_hypercall:
hypercall.c:160: warning: implicit declaration of function perfc_incr
hypercall.c:160: error: hypercalls undeclared (first use in this function)
This adds the xen/perfc.h header to hypercall.c to make the declaration of
perfc_incr() explicit and fix the compile error.
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.163]
- From 76733c3723bed282f0e32a1a712970c2bf0c3185 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 14 Feb 2018 10:38:34 +0000
Subject: [PATCH 77/77] x86/spec_ctrl: Fix several bugs in
SPEC_CTRL_ENTRY_FROM_INTR_IST
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
DO_OVERWRITE_RSB clobbers %rax, meaning in practice that the bti_ist_info
field gets zeroed. Older versions of this code had the DO_OVERWRITE_RSB
register selectable, so reintroduce this ability and use it to cause the
INTR_IST path to use %rdx instead.
The use of %dl for the %cs.rpl check means that when an IST interrupt hits
Xen, we try to load 1 into the high 32 bits of MSR_SPEC_CTRL, suffering a #GP
fault instead.
Also, drop an unused label which was a copy/paste mistake.
Reported-by: Boris Ostrovsky
Reported-by: Zhenzhong Duan
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Reviewed-by: Wei Liu
Reviewed-by: Roger Pau Monne
(cherry picked from commit a2b08fbed388f18235fda5ba1655c1483ef3e215)
Signed-off-by: Patrick Colp [bug 27370020] {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.162]
- From 557bf14fb98fd83c7e3ff8dbb78a1038deb6f3bb Mon Sep 17 00:00:00 2001
From: Jan Beulich
Date: Fri, 2 Feb 2018 11:56:08 +0100
Subject: [PATCH 76/77] x86: allow easier disabling of BTI mitigations
Support both a disable everything and a disable all RSB overwriting
sub-option.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
(cherry picked from commit 37f02a06b9d2f9d965b747a6752301314e935571)
File docs/misc/xen-command-line.markdown doesnt exist, so just ignore
those changes.
Conflicts:
docs/misc/xen-command-line.markdown
Signed-off-by: Patrick Colp [bug 27370020] {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.161]
- From 4deca58f1324708d4c265fd80a4b80ef504ad5d3 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 31 Jan 2018 16:09:39 +0000
Subject: [PATCH 75/77] x86/boot: Make alternative patching NMI-safe
During patching, there is a very slim risk that an NMI or MCE interrupt in the
middle of altering the code in the NMI/MCE paths, in which case bad things
will happen.
The NMI risk can be eliminated by running the patching loop in NMI context, at
which point the CPU will defer further NMIs until patching is complete.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Reviewed-by: Konrad Rzeszutek Wilk
(cherry picked from commit 5191c1ef51b00ec112206917647faea55be8b02f)
Add ACCESS_ONCE() macro to xen/include/xen/lib.h.
Surrounding code is slightly different.
Conflicts:
xen/arch/x86/alternative.c
Signed-off-by: Patrick Colp [bug 27370020] {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.160.1]
- From 3e0b5d50f2111fc4682af00ea749634e9b3c4834 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Tue, 6 Feb 2018 13:45:17 +0000
Subject: [PATCH 74/77] x86/spec_ctrl: Fix determination of when to use IBRS
The original version of this logic was:
/*
* On Intel hardware, wed like to use retpoline in preference to
* IBRS, but only if it is safe on this hardware.
*/
else if ( boot_cpu_has(X86_FEATURE_IBRSB) )
{
if ( retpoline_safe() )
thunk = THUNK_RETPOLINE;
else
ibrs = true;
}
but it was changed by a request during review. Sadly, the result is buggy as
it breaks the later fallback logic by allowing IBRS to appear as available
when in fact it isnt.
This in practice means that on repoline-unsafe hardware without IBRS, we
select THUNK_JUMP despite intending to select THUNK_RETPOLINE.
Reported-by: Zhenzhong Duan
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
(cherry picked from commit 30cbd0c83ef3d0edac2d5bcc41a9a2b7a843ae58)
The surrounding code is a bit different.
Conflicts:
xen/arch/x86/spec_ctrl.c
OraBug: 27370020
CVE: CVE-2017-5715/CVE-2017-5753/CVE-2017-5754
Signed-off-by: Patrick Colp
Reviewed-by: Boris Ostrovsky

[4.1.3-25.el5.223.160]
- From 26c0ff211367cce560d744896000c1aa5d3e312c Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Tue, 6 Feb 2018 12:11:56 -0800
Subject: [PATCH 73/77] xen/cmdline: Fix parse_boolean() for unadorned values
A command line such as cpuid=no-ibrsb,no-stibp tickles a bug in
parse_boolean() because the separating comma fails the NUL case.
Instead, check for slen == nlen which accounts for the boundary (if any)
passed via the e parameter.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
(cherry picked from commit ac37ec1ddef234eeba6f438c29ff687c64962ebd)
Conflicts:
xen/common/kernel.c
Signed-off-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.159]
- From 2a5723f473f2dc3f1a041b452d8a84d80664f90d Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan
Date: Tue, 6 Feb 2018 12:07:53 -0800
Subject: [PATCH 72/77] Optimize the context switch code a bit
Based on upstream commit a2ed643ed783020f885035432e9c0919756921d1
x86/ctxt: Issue a speculation barrier between vcpu contexts
Only flush Branch Target Buffer when switching to a different vcpu context
or non idle context.
Use opt_ibpb instead of cpu_has_xen_ibpb suggested by Boris.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky
Surrounding code was slightly different.
Conflicts:
xen/arch/x86/domain.c
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.158.1]
- From 0fe96932785feea27711a7734f335202bc162f7c Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan
Date: Tue, 6 Feb 2018 11:54:40 -0800
Subject: [PATCH 71/77] Update init_speculation_mitigations() to upstreams
Based on upstream commit 2713715305ca516f698d58cec5e0b322c3b2c4eb
x86/boot: Calculate the most appropriate BTI mitigation to use
Tried to port all changes in upstream commit to current code.
This should include all the changes, such as:
Set opt_rsb_native/opt_rsb_vmexit default to true, prefer retpoline without
checking X86_FEATURE_IBRSB, remove redundant variable have_mitigation,
remove *_SS variants for RSB stuff, enable RSB flushing no matter if IBRS is
enabled, etc.
Signed-off-by: Zhenzhong Duan
Change: bool -> bool_t; false -> 0; true -> 1
Conflicts:
xen/arch/x86/spec_ctrl.c
OraBug: 27370020
CVE: CVE-2017-5715/CVE-2017-5753/CVE-2017-5754
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk

[4.1.3-25.el5.223.158]
- From d2fa0abfae733fbcaa6a9c6b8bd1068ca32d3255 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Tue, 6 Feb 2018 11:23:05 -0800
Subject: [PATCH 70/77] x86/entry: Avoid using alternatives in NMI/#MC paths
This patch is deliberately arranged to be easy to revert if/when alternatives
patching becomes NMI/#MC safe.
For safety, there must be a dispatch serialising instruction in (what is
logically) DO_SPEC_CTRL_ENTRY so that, in the case that Xen needs IBRS set in
context, an attacker cant speculate around the WRMSR and reach an indirect
branch within the speculation window.
Using conditionals opens this attack vector up, so the else clause gets an
LFENCE to force the pipeline to catch up before continuing. This also covers
the safety of RSB conditional, as execution it is guaranteed to either hit the
WRMSR or LFENCE.
One downside of not using alternatives is that there unconditionally an LFENCE
in the IST path in cases where we are not using the features from IBRS-capable
microcode.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
(cherry picked from commit 3fffaf9c13e9502f09ad4ab1aac3f8b7b9398f6f)
Conflicts:
xen/arch/x86/spec_ctrl.c
xen/arch/x86/x86_64/entry.S
xen/include/asm-x86/current.h
Add a #define of UNLIKELY_DISPATCH_LABEL in xen/include/asm-x86/asm_defns.h
picked from upstream commit 8e0da8c07f4f80e14314977a11f738bd74a5b62b
x86: Improve information from domain_crash_synchronous
Signed-off-by: Zhenzhong Duan
Add #define of __maybe_unused to xen/include/xen/compiler.h
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.157.1]
- From 9e95e8af5b01f87dec62fcc699a49f48d53f6191 Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan
Date: Tue, 6 Feb 2018 11:13:13 -0800
Subject: [PATCH 69/77] Update RSB related implementation to upstream ones
Based on upstream commit e6c0128e9ab25bf66df11377a33ee5584d7f99e3
x86/entry: Organise the clobbering of the RSB/RAS on entry to Xen
Update DO_OVERWRITE_RSB definition to to upstreams.
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
CVE: CVE-2017-5715/CVE-2017-5753/CVE-2017-5754
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk

[4.1.3-25.el5.223.157]
- From a07640e9c9f3fd662ba60a2d81eb7114c3a9b632 Mon Sep 17 00:00:00 2001
From: Elena Ufimtseva
Date: Tue, 16 Jan 2018 19:16:36 -0500
Subject: [PATCH 68/77] x86/domain: Move hvm_vcpu_initialize() before
cpuid_policy_changed()
Move hvm_vcpu_initialize() befor cpuid_policy_changed() which
will allocate memory for MSR permission map and can be used in
cpuid_policy_changed without triggering BUG_ON.
Signed-off-by: Elena Ufimtseva
Reviewed-by: Boris Ostrovsky
Use is_hvm_domain() instead of has_hvm_container(), as the latter function
does not exist in older Xen. Instead of going to done on
hvm_vcpu_initialse() failure, call xsave_free_save_area() and return, which
mimics what the original code did.
Conflicts:
xen/arch/x86/domain.c
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.156]
- From bfe75c2972c8089fbec28c579fe0e2eb56e5383b Mon Sep 17 00:00:00 2001
From: Elena Ufimtseva
Date: Thu, 18 Jan 2018 11:31:49 -0500
Subject: [PATCH 67/77] x86/svm: clear CPUID IBPB when feature is not supported
The CPUID bit which exposes to the guest IBPB support was cleared under incorrect
check of stibp field of CPUID policy, resulting in the guest not seeing this feature.
Fix this by using correct check of ibpb in the cpuid_policy structure.
Signed-off-by: Elena Ufimtseva
Reviewed-by: Boris Ostrovsky
(cherry picked from commit bb793ca5296e2100f1453f20360f02dfb9c920e5)
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.155.1]
- From e7b8d84d8c6220195f83333e1a72ef6ca6f7d9e0 Mon Sep 17 00:00:00 2001
From: Boris Ostrovsky
Date: Thu, 11 Jan 2018 10:30:03 -0500
Subject: [PATCH 66/77] x86/Spectre: Set thunk to THUNK_NONE if compiler
support is not available
If no microcode patch is available we end up setting thunk to THUNK_JMP.
Which really is equivalent to THUNK_NONE (if CONFIG_INDIRECT_THUNK is not
set, which it is not) but is somewhat misleading in terms of reporting.
With this change the reported mitigation set will look as follows:
(XEN) Speculative mitigation facilities:
(XEN) Hardware features: SMEP IBRS/IBPB STIBP
(XEN) BTI mitigations: Thunk N/A, Others: IBRS+ IBPB SMEP RSB_VMEXIT
Signed-off-by: Boris Ostrovsky
Reviewed-by: Darren Kenny
Reviewed-by: Bhavesh Davda
(cherry picked from commit 88bf1ed2b377f03de6e6b20283af90be5065b395)
OraBug: 27370020
CVE: CVE-2017-5715/CVE-2017-5753/CVE-2017-5754
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk

[4.1.3-25.el5.223.155]
- From 3f0c8c59efbe126f29cf209a32f63ffb29a07ae3 Mon Sep 17 00:00:00 2001
From: Boris Ostrovsky
Date: Sat, 6 Jan 2018 15:39:54 -0500
Subject: [PATCH 65/77] x86: cpuint. Move trap_init and init_idle_domain
commit x86: cpuint. Move the detection of CPU capabilities move
identify_cpu() ahead. On an env without MSR MSR_INTEL_PLATFORM_INFO,
probe_intel_cpuid_faulting() trigger a #GP.
Move trap_init() ahead too so that exception fixup mechanism take over the #GP.
Move init_idle_domain() ahead to prevent #PG when loading GDT.
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.154.1]
- From 55e087117569f09f45e3ea160f1dbef7a46f89e4 Mon Sep 17 00:00:00 2001
From: Boris Ostrovsky
Date: Sat, 6 Jan 2018 15:06:43 -0500
Subject: [PATCH 64/77] x86: Dont use retpoline if CONFIG_INDIRECT_THUNK is
not set
If this config option is not set (which it is not, unless compiler
support is available) the thunk degenerates to the original indirect
call/jmp.
This is XSA-254.
Reported-by: Bhavesh Davda
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Boris Ostrovsky
Signed-off-by: Zhenzhong Duan
The code surrounding on of the changes is slightly different.
Conflicts:
xen/arch/x86/spec_ctrl.c
OraBug: 27370020
CVE: CVE-2017-5715/CVE-2017-5753/CVE-2017-5754
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk

[4.1.3-25.el5.223.154]
- From 0a00914b7916dd3fe36d6f1a48d245de9aa5d226 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Wed, 3 Jan 2018 18:46:17 -0500
Subject: [PATCH 63/77] x86: cpuint. Move the detection of CPU capabilities
right after the microcode has been loaded but before the
speculation check.
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.153]
- From b73fd2711a3c49da98e6688a7ef1d20a759bc375 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Wed, 3 Jan 2018 18:46:16 -0500
Subject: [PATCH 62/77] migration: Set the CPUID _before_
XEN_DOMCTL_sethvmcontext
As the MSRs depend on the cpuid policies. And if we dont
set them we will always have:
(XEN) HVM6 restore: CPU_MSR 0
(XEN) HVM6 restore: failed to load entry 20/0
Along with:
xc: progress: Reloading memory pages: 262144/1044481 25%
xc: error: error setting the HVM context (1 = Operation not permitted): Internal error
libxl: error: libxl_create.c:942:libxl__xc_domain_restore_done: restoring domain: Resource temporarily unavailable
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.152]
- From 92cf65be49042ecc4aca96ee8537e2cc504edcfc Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Wed, 3 Jan 2018 18:46:15 -0500
Subject: [PATCH 61/77] x86/xen: Make cpu_has_[stibp,ibrsp,etc] work.
All of those macros depend on c->x86_capability bits being
set but we dont set them for word 8 and word 9. Which means
they are always set to zero.
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
Conflicts:
xen/arch/x86/cpu/common.c
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.151]
- From 60b60b3f4604fa1308a49afda01d69bb6db751ff Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Wed, 3 Jan 2018 18:46:14 -0500
Subject: [PATCH 60/77] x86: Expose CPUID.7, EDX.26->27 and CPUID.0x80000008,
EBX.12
If the CPU has this exposed _and_ the CPUID policy specifies it
as such.
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Boris Ostrovsky
Conflicts:
- context
Conflicts with OVM345:
xen/arch/x86/hvm/hvm.c
Signed-off-by: Zhenzhong Duan
The values in tools/libxc/xc_cpufeature.h needed to be changed to be in
the older format (e.g., 12 -> (8*32+12)). Otherwise, the code surrounding
some of the changes is slightly different.
Conflicts:
tools/libxc/xc_cpufeature.h
tools/libxc/xc_cpuid_x86.c
xen/arch/x86/hvm/hvm.c
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.150]
- From c020bf5052cf0c0b49f1c4f4e3e9c368be96ad98 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:46:13 -0500
Subject: [PATCH 59/77] x86/idle: Clear SPEC_CTRL while idle
On contemporary hardware, setting IBRS/STIBP has a performance impact on
adjacent hyperthreads. It is therefore recommended to clear the setting
before becoming idle, to avoid an idle core preventing adjacent userspace
execution from running at full performance.
Care must be taken to ensure there are no ret or indirect branch instructions
between spec_ctrl_{enter,exit}_idle() invocations, which are forced always
inline. Care must also be taken to avoid using spec_ctrl_enter_idle() between
flushing caches and becoming idle, in cases where that matters.
Signed-off-by: Andrew Cooper
Signed-off-by: Boris Ostrovsky
Signed-off-by: Konrad Rzeszutek Wilk
Add #include to xen/include/asm-x86/spec_ctrl.h to fix
missing __stringify.
Signed-off-by: Zhenzhong Duan
The file xen/arch/x86/cpu/mwait-idle.c doesnt exist (nor does its code
exist somewhere else), so just ignore those changes.
The code surrounding some of the changes in cpu_idle.c is slightly
different.
Conflicts:
xen/arch/x86/acpi/cpu_idle.c
xen/arch/x86/cpu/mwait-idle.c
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.149]
- From 1916287d71e6b87a9b326509b22035dce3a82207 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:46:12 -0500
Subject: [PATCH 58/77] x86/cpuid: Offer Indirect Branch Controls to guests
With all infrastructure in place, it is now safe to let guests see and use
these features. Allow AMDs IBPB to be set even on Intel hardware, so the
toolstack can express IBPB only to guests.
This also requires updating the libxc logic to understand the e8b feature
leaf, which has the side effect of also offering CLZERO on applicable
hardware.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Signed-off-by: Boris Ostrovsky
Conflicts:
- No cpuid.c/calculate_host_policy, put the chunk into
update_domain_cpuid_info()
- No need for cpufeature.h changes, they are for auto-generated CPUIDs
- We dont support X86_FEATURE_CLZERO so no related changes in xc_cpuid_hvm_policy()
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.148]
- From a5639cb066ba5a6ccd4ac3a14ed9af0caf63ad90 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:46:11 -0500
Subject: [PATCH 57/77] x86/ctxt: Issue a speculation barrier between vcpu
contexts
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Signed-off-by: Boris Ostrovsky
Conflict:
- cpufeature.h differences
- context
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
The file docs/misc/xen-command-line.markdown doesnt exist, so just ignore
the changes.
Conflicts:
docs/misc/xen-command-line.markdown
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.147]
- From 730f1552a8783e32b1df729efb7edd2f22c3ceee Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Fri, 19 Jan 2018 10:49:06 -0800
Subject: [PATCH 56/77] x86/entry: Clobber the Return Stack Buffer on entry to
Xen
ret instructions are unconditionally speculated based on values in the RSB.
If any path in Xen executes more ret than call instructions, speculation can
start following a guest controlled RSB entry.
There is at least one path (wake from waitqueue) which can end up executing
more ret than call instructions. There may be other paths as well.
To mitigate, overwrite the RSB (when appropriate; see code for details) when
entering Xen from guest context.
Signed-off-by: Andrew Cooper
Signed-off-by: Boris Ostrovsky
Conflicts:
- cpufeature.h differences
- context
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
The file docs/misc/xen-command-line.markdown doesnt exist, so just ignore
the changes.
Conflicts:
docs/misc/xen-command-line.markdown
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.146.1]
- From 9f402c09e29dd4f54a42be030fc34ab85ff2e574 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:46:09 -0500
Subject: [PATCH 55/77] x86/boot: Calculate the most appropriate BTI mitigation
to use
Signed-off-by: Andrew Cooper
Signed-off-by: Boris Ostrovsky
Conflicts:
- context
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
The file docs/misc/xen-command-line.markdown doesnt exist, so just ignore
those changes.
Conflicts:
docs/misc/xen-command-line.markdown
OraBug: 27370020
CVE: CVE-2017-5715/CVE-2017-5753/CVE-2017-5754
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk

[4.1.3-25.el5.223.146]
- From 107b2cb82456a67f367c6fbe00e444ccb46b2bc4 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:46:08 -0500
Subject: [PATCH 54/77] x86/entry: Use MSR_SPEC_CTRL at each entry/exit point
Set or clear IBRS in Xen context, and appropriate guest values in guest
context. See the documentation in asm-x86/spec_ctrl_asm.h for details.
Two semi-unrelated bugfixes are that various asm_defn.h macros have a hidden
dependency on PAGE_SIZE, which results in an assembler error if used in a
.macro definition. Secondly, _ASM_MK_NOP() needs a separator at the end,
rather than relying on its calling context for separation.
Signed-off-by: Andrew Cooper
Signed-off-by: Boris Ostrovsky
Conflicts:
- context in entry.S (all of them), different labels, different routines
- various context conflicts
- add ifdef __ASSEMBLY__ to cpufeature.h
- We dont have GET_STACK_END (from commit 4f6aea06) so use
DO_SPEC_CTRL_EXIT_TO_XEN/DO_SPEC_CTRL_ENTRY from v4
Signed-off-by: Konrad Rzeszutek Wilk
Conflicts with OVM345:
xen/arch/x86/hvm/svm/entry.S
xen/arch/x86/hvm/vmx/entry.S
Signed-off-by: Zhenzhong Duan
The surrounding code of the changes is slightly different.
Conflicts:
xen/arch/x86/hvm/svm/entry.S
xen/arch/x86/hvm/vmx/entry.S
xen/arch/x86/x86_64/asm-offsets.c
xen/arch/x86/x86_64/compat/entry.S
xen/include/asm-x86/current.h
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.145]
- From 578a6587f9e42061f15c0db1d29aaae18a808948 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:46:07 -0500
Subject: [PATCH 53/77] x86: Protect unaware domains from meddling hyperthreads
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Signed-off-by: Boris Ostrovsky
Conflicts:
- cpufeature.h differences
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.144]
- From fb2d96abb5ab24e8865f05039a187a0a0f5b1ac1 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:46:06 -0500
Subject: [PATCH 52/77] x86/hvm: Permit guests direct access to
MSR_{SPEC_CTRL,PRED_CMD}
For performance reasons, HVM guests should have direct access to these MSRs
when possible.
Signed-off-by: Andrew Cooper
Signed-off-by: Boris Ostrovsky
Conflicts:
- Simplified call_policy_changed computation in
update_domain_cpuid_info()
- Adjust for different MSR intercept interface
(vmx_disable_intercept_for_msr() vs vmx_set_msr_intercept())
- context
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.143]
- From 33d9d5ad5e911d63f69542bebb86f96ae57c4d94 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:46:05 -0500
Subject: [PATCH 51/77] x86/migrate: Move MSR_SPEC_CTRL on migrate
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
Signed-off-by: Boris Ostrovsky
Conflicts:
- context in arch/x86/hvm/hvm.c
- No need to port changes to xen/arch/x86/domctl.c (see comment in
x86: Avoid corruption on migrate for vcpus using CPUID Faulting patch)
Signed-off-by: Konrad Rzeszutek Wilk
- And expose in msrs_to_send the new MSR.
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.142]
- From ce1b2a5ef20fd3a0d501db41c4cdfe0acbf477d0 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:46:04 -0500
Subject: [PATCH 50/77] x86/msr: Emulation of MSR_{SPEC_CTRL,PRED_CMD} for
guests
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Signed-off-by: Boris Ostrovsky
Conflicts:
-context
- (re-)add gp_fault label
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
For some reason, old gcc (at least version 4.1.2) does not like shifting
1ULL by 0. SPEC_CTRL_IBRS is defined as ((1ULL) << _SPEC_CTRL_IBRS)
where _SPEC_CTRL_IBRS is defined as 0. This causes the compiler to error
out complaining about unmatched ) and an extra ULL. By removing the ULL
and the extra parentheses around the 1, it compiles fine.
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.141]
- From 58a47a06b43e9b09ba16b98bf604fb4f15ab1348 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:46:03 -0500
Subject: [PATCH 49/77] x86: Introduce a common cpuid_policy_updated()
No practical change at the moment, but future changes will need to react
irrespective of guest type.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
Signed-off-by: Boris Ostrovsky
Conflicts
- Different update_domain_cpuid_info implementation
- context differences
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.140]
- From 6016cb105219bbf3c3228ec414c15e5f05f54cb8 Mon Sep 17 00:00:00 2001
From: Boris Ostrovsky
Date: Wed, 3 Jan 2018 18:46:02 -0500
Subject: [PATCH 48/77] x86: Introduce framework for cpuid policy updates
And also set cpuid_policy bits.
Signed-off-by: Boris Ostrovsky
Signed-off-by: Konrad Rzeszutek Wilk
Conflicts with OVM345:
xen/arch/x86/domctl.c
Signed-off-by: Zhenzhong Duan
Code surrounding the changes is slightly different.
Conflicts:
xen/arch/x86/domctl.c
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.139]
- From 410efcdaaf9cf70a1ecbb2b553356d9a8ac18b75 Mon Sep 17 00:00:00 2001
From: Boris Ostrovsky
Date: Wed, 3 Jan 2018 18:46:01 -0500
Subject: [PATCH 47/77] x86: Introduce cpuid_policy
Just enough to get by...
Also added the allocation on the idle domain path.
Signed-off-by: Boris Ostrovsky
Signed-off-by: Konrad Rzeszutek Wilk
Code surrounding the changes is slightly different.
Conflicts:
xen/arch/x86/domain.c
xen/include/asm-x86/domain.h
OraBug: 27370020
Signed-off-by: Patrick Colp
Signed-off-by: Ankur Arora
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.138]
- From 26ac1001c7aecdbdd8e1800e01ebdbded3cdf5aa Mon Sep 17 00:00:00 2001
From: Gregory Herrero
Date: Thu, 12 Jan 2017 19:56:49 +0100
Subject: [PATCH 46/77] xen: string: add few helpers from kernel side.
strtobool() and strcspn() are needed to parse module parameters.
Signed-off-by: Blaise Boscaccy
Signed-off-by: Gregory Herrero
Backport from OVM345, need it to fix bool type unrecognized compile error
introduced by x86/msr: introduce struct msr_vcpu_policy
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.137]
- From a1344ce0f964610379cad8b42e9d74ca50032b55 Mon Sep 17 00:00:00 2001
From: Sergey Dyasli
Date: Tue, 16 Jan 2018 08:40:57 +0800
Subject: [PATCH 45/77] x86/msr: introduce struct msr_vcpu_policy
The new structure contains information about guests MSRs that are
unique to each vCPU. It starts with only 1 MSR:
MSR_INTEL_MISC_FEATURES_ENABLES
Which currently has only 1 usable bit: cpuid_faulting.
Add 2 global policy objects: hvm_max and pv_max that are inited during
boot up. Availability of MSR_INTEL_MISC_FEATURES_ENABLES depends on
availability of MSR_INTEL_PLATFORM_INFO.
Add init_vcpu_msr_policy() which sets initial MSR policy for every vCPU
during domain creation with a special case for Dom0.
Signed-off-by: Sergey Dyasli
Reviewed-by: Andrew Cooper
Reviewed-by: Kevin Tian
(cherry picked from commit 4187f79dc7184d90a1aa7a0439ccee2bc25355c2)
Signed-off-by: Boris Ostrovsky
Conflicts:
- mostly context
Signed-off-by: Konrad Rzeszutek Wilk
[Also no ZERO_BLOCK_PTR, so fix that with xzalloc_bytes]
Signed-off-by: Boris Ostrovsky
Conflicts:
- Free policy in vcpu_destroy (this happens to be XSA-253)
OVM3.3 didnt have is_pv_domain, use is_hvm_domain instead
Signed-off-by: Zhenzhong Duan
Code surrounding the changes is a bit different.
Conflicts:
xen/arch/x86/domain.c
xen/include/asm-x86/domain.h
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.136]
- From 5c5b7cb98187a2c21675b9d34789182f6762f3c6 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:45:59 -0500
Subject: [PATCH 44/77] x86/cmdline: Introduce a command line option to disable
IBRS/IBPB, STIBP and IBPB
Instead of gaining yet another top level boolean, introduce a more generic
cpuid= option. Also introduce a helper function to parse a generic boolean
value.
Signed-off-by: Andrew Cooper
Signed-off-by: Boris Ostrovsky
Conflicts:
- no arch/x86/cpuid.c, used arch/s86/setup.c for parse_xen_cpuid
- context conflicts
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
The file docs/misc/xen-command-line.markdown doesnt exist, so just ignore
those changes.
Conflicts:
docs/misc/xen-command-line.markdown
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.135]
- From ccedf02175d639d6c752cdec06a9cd1bccb93ef9 Mon Sep 17 00:00:00 2001
From: Juergen Gross
Date: Mon, 15 Jan 2018 04:40:55 +0800
Subject: [PATCH 43/77] xen: add an optional string end parameter to
parse_bool()
Add a parameter to parse_bool() to specify the end of the to be
parsed string. Specifying it as NULL will preserve the current
behavior to parse until the end of the input string, while passing
a non-NULL pointer will specify the first character after the input
string.
This will allow to parse boolean sub-strings without having to
write a NUL byte into the input string.
Modify all users of parse_bool() to pass NULL for the new parameter.
(cherry-picked from commit 532dec8e31174ed450adfd36a4b0b41dec27010d)
Reviewed-by: Kevin Tian
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
Signed-off-by: Boris Ostrovsky
Conflicts:
-context, some files dont need a backport
Signed-off-by: Konrad Rzeszutek Wilk
Chuck for xen/arch/x86/nmi.c is unnecessory for OVM33trunk and ignored
Updated parse_bool() call in xen/drivers/passthrough/x86/ats.c
Signed-off-by: Zhenzhong Duan
The file docs/misc/xen-command-line.markdown doesnt exist, so just ignore
those changes. The file xen/drivers/passthrough/x86/atc.c exists, but at a
different location: xen/drivers/passthrough/vtd/x86/atc.c
The parse_vpmu_param() function doesnt exist, so its changes are not
needed. Otherwise, just some surrounding code is different.
Conflicts:
docs/misc/xen-command-line.markdown
xen/arch/x86/hvm/vpmu.c
xen/drivers/passthrough/iommu.c
xen/drivers/passthrough/x86/ats.c
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.134]
- From 5675a794664de9b3c28d3f0f03cfa2e15e4af4c6 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:45:57 -0500
Subject: [PATCH 42/77] x86/feature: Definitions for Indirect Branch Controls
Contemporary processors are gaining Indirect Branch Controls via microcode
updates. Intel are introducing one bit to indicate IBRS and IBPB support, and
a second bit for STIBP. AMD are introducing IPBP only, so enumerate it with a
separate bit.
Furthermore, depending on compiler and microcode availability, we may want to
run Xen with IBRS set, or clear.
To use these facilities, we synthesise separate IBRS and IBPB bits for
internal use. A lot of infrastructure is required before these features are
safe to offer to guests.
Signed-off-by: Andrew Cooper
Signed-off-by: Boris Ostrovsky
Conflicts:
- No new(-ish) CPUID generation so skip xen-cpuid.c/gen-cpuid.py
- Again, cpufeatures.h is different in OVM
- No boot_cpu_data.extended_cpuid_level, use cpuid_eax(0x80000000)
- context difference in libxl
Signed-off-by: Konrad Rzeszutek Wilk
Conflicts with OVM345:
tools/libxl/libxl_cpuid.c
Signed-off-by: Zhenzhong Duan
The cpuid flags are different (there are fewer in this version of Xen).
Conflicts:
tools/libxl/libxl_cpuid.c
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.133]
- From 4deb27795b9975c9b39b84feb3b468ddeca69625 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:45:56 -0500
Subject: [PATCH 41/77] x86: Introduce alternative indirect thunks
Depending on hardware and microcode availability, we will want to replace
IND_THUNK_REPOLINE with other implementations.
For AMD hardware, choose IND_THUNK_LFENCE in preference to retpoline if lfence
is known to be (or was successfully made) dispatch serialising.
Signed-off-by: Andrew Cooper
Signed-off-by: Boris Ostrovsky
Conflicts:
- Different cpufeature.h implementaion
- docs context conflict
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
docs/mix/xen-command-line.markdown doesnt exist, so just ignore the
changes to it.
Conflicts:
docs/misc/xen-command-line.markdown
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.132]
- From dae9f2fec4a626fb7787d06d3cfc08bdebadeead Mon Sep 17 00:00:00 2001
From: Boris Ostrovsky
Date: Wed, 3 Jan 2018 18:45:55 -0500
Subject: [PATCH 40/77] x86: Backport setup_force_cpu_cap
Signed-off-by: Boris Ostrovsky
Signed-off-by: Zhenzhong Duan
Theres a comment before one of the changes in the original patch, however
the comment is absent in this version of Xen.
Conflicts:
xen/arch/x86/cpu/common.c
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.131]
- From b8df90a5366ea3ad4fc5e8cc8500c0d419089a53 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:45:54 -0500
Subject: [PATCH 39/77] x86/amd: Try to set lfence as being Dispatch
Serialising
This property is required for the AMDs recommended mitigation for Branch
Target Injection, but Xen needs to cope with being unable to detect or modify
the MSR.
Signed-off-by: Andrew Cooper
Signed-off-by: Boris Ostrovsky
Conflicts:
- cpufeatures.h is different
- init_amd(): No X86_FEATURE_MFENCE_RDTSC in OVM
Conflicts with OVM345:
xen/include/asm-x86/cpufeature.h
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.130]
- From 1a49093250112a17e89e02ffef910fe4c237d644 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:45:53 -0500
Subject: [PATCH 38/77] x86/boot: Report details of speculative mitigations
Nothing very interesting at the moment, but the logic will grow as new
mitigations are added.
Signed-off-by: Andrew Cooper
Signed-off-by: Boris Ostrovsky
Conflicts:
- context conflict in setup.c
- No IS_ENABLED in spec_ctl.c
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.129]
- From f3e889485e6d5c9d29468933bfa4679ff40bf6df Mon Sep 17 00:00:00 2001
From: Ankur Arora
Date: Tue, 23 Jan 2018 22:41:43 -0800
Subject: [PATCH 37/77] x86/emulate: Support indirect thunks for xmm
instructions
Add CALL_THUNK for which x86_emulate path for movq.
OraBug: 27370020
Signed-off-by: Ankur Arora
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.128]
- From 33f46f8d7958b47b4febe3eb314ce6b6ecf0d63c Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Mon, 15 Jan 2018 03:22:27 +0800
Subject: [PATCH 36/77] x86: Support indirect thunks from assembly code
Introduce CALL_THUNK and JMP_THUNK which either degrade to a normal indirect
branch, or dispatch to the __x86.indirect_thunk.* symbols.
Update all the manual indirect branches in to use the new thunks. The
indirect branches in the boot and kexec path are left intact as we cant use
the compiled-in thunks at those points.
Signed-off-by: Andrew Cooper
Signed-off-by: Boris Ostrovsky
Conflicts:
- x86_emulate.c code is different
- Include asm/asm_defns.h in x86_emulate.c
- no IS_ENABLED, so use ifdef
- No changes to extable.c (not needed)
- Added -Wa -I CFLAGS option to help compiler find include for asm(.include ...)
Conflicts:
xen/arch/x86/Rules.mk
Signed-off-by: Zhenzhong Duan
Surrounding code to the changes is slightly different.
Conflicts:
xen/arch/x86/x86_64/entry.S
xen/arch/x86/x86_emulate/x86_emulate.c
xen/common/wait.c
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.127]
- From 23186e667629a6dcba88fb9756e0de5f2916ef8a Mon Sep 17 00:00:00 2001
From: Ankur Arora
Date: Tue, 23 Jan 2018 22:07:05 -0800
Subject: [PATCH 35/77] common/wait: Minor fixes to wait infrastructure
check_wakeup_from_wait() uses the local rep movsb instead of the
reusing the one in __prepare_to_wait().
Remove the asm label which we dont end up using here.
No functional change.
OraBug: 27370020
Signed-off-by: Ankur Arora
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.126]
- From c7f98b9bab42107ea3d7aad844480576f312b0c6 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:45:51 -0500
Subject: [PATCH 34/77] common/wait: Clarifications to wait infrastructure
This logic is not as clear as it could be. Add some comments to help.
Rearrange the asm block in __prepare_to_wait() to separate the GPR
saving/restoring from the internal logic.
While tweaking, add an unreachable() following the jmp in
check_wakeup_from_wait().
No functional change.
Signed-off-by: Andrew Cooper
Signed-off-by: Boris Ostrovsky
Signed-off-by: Zhenzhong Duan
A similar change needs to also be made for 32-bit code.
Conflicts:
xen/common/wait.c
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.125]
- From dfebd257fd7c82033f5a835666fbefa477380d58 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:45:50 -0500
Subject: [PATCH 33/77] x86: Support compiling with indirect branch thunks
Use -mindirect-branch=thunk-extern/-mindirect-branch-register when available.
To begin with, use the retpoline thunk. Later work will add alternative
thunks which can be selected at boot time.
Signed-off-by: Andrew Cooper
Signed-off-by: Boris Ostrovsky
Conflicts:
- context
conflicts with OVM3.4.5:
xen/arch/x86/xen.lds.S
Signed-off-by: Zhenzhong Duan
The code surrounding the changes is slightly different.
Conflicts:
xen/arch/x86/Rules.mk
xen/arch/x86/xen.lds.S
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.124]
- From 921ccfa2f69545663c3a14032d3761f0154497f2 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:45:49 -0500
Subject: [PATCH 32/77] x86/entry: Erase guest GPR state on entry to Xen
This reduces the number of code gadgets which can can be attacked with
arbitrary guest-controlled GPR values.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Reviewed-by: Wei Liu
Signed-off-by: Boris Ostrovsky
Conflicts:
- the file is include/asm-x86/x86_64/asm_defns.h
Signed-off-by: Zhenzhong Duan
Move SETUP_EXCEPTION_FRAME_POINTER code inline as its only used in the one
place and this makes it easier to understand the case when
CONFIG_FRAME_POINTER is not defined.
Conflicts:
include/asm-x86/x86_64/asm_defns.h
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.123]
- From 85a429652d951606c7a4c42b83d62089ca252c31 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:45:48 -0500
Subject: [PATCH 31/77] x86/pv: Move hypercall handling up into C
Partial backport of:
939ba61bd376955ae3a519c09364346aed2be070
c99986fa168ef79b1ea6c071f57017e40b367383
5464f1210c6341762ca0457253adfa035ffe666c
51e5d6c7a29640490eeab4e4c3d60b9c2d3d3054
Signed-off-by: Andrew Cooper
Signed-off-by: Boris Ostrovsky
Conflicts with OVM3.4.5:
xen/arch/x86/Makefile
Signed-off-by: Zhenzhong Duan
The trace_hypercall() function is different, but it doesnt matter since
its being removed.
Conflicts:
xen/arch/x86/hypercall.c
xen/arch/x86/trace.c
xen/arch/x86/x86_64/compat/entry.S
xen/arch/x86/x86_64/entry.S
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.122]
- From 8600e6b1ce668397689e51c34e8ff77e9ea8635a Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:45:47 -0500
Subject: [PATCH 30/77] x86/hvm: Use SAVE_ALL to construct the cpu_user_regs
frame after VMExit
No practical change.
One side effect in debug builds is that %rbp is inverted in the manner
expected by the stack unwinder to indicate a interrupt frame.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Reviewed-by: Wei Liu
Signed-off-by: Boris Ostrovsky
Conflicts:
- Different GET_CURRENT() definitions
Conflicts with OVM3.4.5
xen/arch/x86/hvm/svm/entry.S
xen/arch/x86/hvm/vmx/entry.S
Signed-off-by: Zhenzhong Duan
Perform a similar change of the original, but on 32-bit code as well as
the 64-bit code.
Conflicts:
xen/arch/x86/hvm/svm/entry.S
xen/arch/x86/hvm/vmx/entry.S
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.121]
- From 2b12058f0a3d89e2d804ee5f74f6522882962289 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:45:45 -0500
Subject: [PATCH 29/77] x86/entry: Remove support for partial cpu_user_regs
frames
Save all GPRs on entry to Xen.
The entry_int82() path is via a DPL1 gate, only usable by 32bit PV guests, so
can get away with only saving the 32bit registers. All other entrypoints can
be reached from 32 or 64bit contexts.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Signed-off-by: Boris Ostrovsky
Conflicts:
- Drop BUILD_COMMON_IRQ, (comit 29f6c57c2372a53)
- update RESTORE_ALL (get some clobbering from upstream)
- Make SAVE_ALL a macro
- Many asm changes due to context differences
Signed-off-by: Zhenzhong Duan
Many of the changes in the original patch are to remove the function
mark_regs_dirty(), which doesnt exist in this version of Xen.
The patches replace SAVE_VOLATILE TRAP_syscall with a movl and a SAVE_ALL,
however in this version of Xen, this is already how its done, so those
changes can be ignored.
Conflicts:
xen/arch/x86/domain.c
xen/arch/x86/i8259.c
xen/arch/x86/traps.c
xen/arch/x86/x86_64/compat/entry.S
xen/arch/x86/x86_64/entry.S
xen/common/wait.c
xen/include/asm-x86/x86_64/asm_defns.h
OraBug: 27370020
Signed-off-by: Patrick Colp
[ This patch is for the most part a NOP because partial cpu_user_regs
save was only added in 4.2.0 (commit ecf9846a6a20,
x86: save/restore only partial register state where possible.) ]
Signed-off-by: Ankur Arora
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.120.2]
- From 0dc265c4ce4fcb4971454a9c2e6ebfceb3d61ac0 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:45:44 -0500
Subject: [PATCH 28/77] x86/alt: Introduce ALTERNATIVE{,_2} macros
To help creating alternative frames in assembly.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Signed-off-by: Boris Ostrovsky
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
CVE: CVE-2017-5715/CVE-2017-5753/CVE-2017-5754

[4.1.3-25.el5.223.120.1]
- From ba181fe164b407d1cabcf5aad8e5ebc5766041be Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Wed, 3 Jan 2018 18:45:43 -0500
Subject: [PATCH 27/77] x86/alt: Break out alternative-asm into a separate
header file
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Signed-off-by: Boris Ostrovsky
Conflicts:
- alternative.h context
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
CVE: CVE-2017-5715/CVE-2017-5753/CVE-2017-5754
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.120]
- From 1b19473c440ad4541e680f2c306302fbabfb97ad Mon Sep 17 00:00:00 2001
From: Tim Deegan
Date: Mon, 15 Jan 2018 03:31:47 +0800
Subject: [PATCH 26/77] x86: mark BUG()s and assertion failures as terminal.
This helps avoid static analysis false-positives, and might lead to
better code density as the compiler knows it doesnt have to restore
spilled state &c.
Signed-off-by: Tim Deegan
Acked-by: Keir Fraser
Prequisite patch for common/wait: Clarifications to wait infrastructure
Conflicts:
xen/include/asm-x86/bug.h
Signed-off-by: Zhenzhong Duan
The code after the change has an #ifdef for clang, however this version
of Xen doesnt have clang support and therefore doesnt have the #ifdef.
The rest of the surrounding code is the same, though.
Conflicts:
xen/include/xen/compiler.h
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.119]
- From 2bdc87c1e0971e3341bf37ca79e6105dbec7fe5d Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan
Date: Sun, 14 Jan 2018 04:12:12 +0800
Subject: [PATCH 25/77] x86/hvm: assert that we we saved a sane number of MSRs.
Just as a backstop measure against later changes that add MSRs to the
save function without updating the count in the init function.
Signed-off-by: Tim Deegan
Acked-by: Jan Beulich
(cherry picked from commit 891219a9d3958860b915021f622f7119b9b880d8)
Signed-off-by: Konrad Rzeszutek Wilk
This patch is backported from OVS345.
upstream commit: 891219a9d3958860b915021f622f7119b9b880d8
OVS345 commit: 5139d82b5ec7cfc2f493f30e1be7e40ef1b76c42
Backported-by: Dongli Zhang
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.118]
- From 88f9646c87f4857db0691ee2a9fd7488285a10da Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan
Date: Sun, 14 Jan 2018 04:09:39 +0800
Subject: [PATCH 24/77] x86: Avoid corruption on migrate for vcpus using CPUID
Faulting
Xen 4.8 and later virtualises CPUID Faulting support for guests. However, the
value of MSR_MISC_FEATURES_ENABLES is omitted from the vcpu state, meaning
that the current cpuid faulting setting is lost on migrate/suspend/resume.
Instead of following the MSR status quo, take the opportunity to make the
logic more generic, and in particular, trivial to extend for future MSRs.
This is done by discarding the notion of optional MSRs, and requiring the
toolstack to be prepared to move all of the MSRs, although only a subset will
typically need to move.
This allows for the use of guest_{rd,wr}msr() alone to evaluate whether an MSR
needs moving. This is a benefit because it means there is a single piece of
logic responsible for evaluating whether a guest can use an MSR, and which
values are acceptable.
One small adjustment to guest_wrmsr() is required to cope with being called in
toolstack context.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Release-acked-by: Julien Grall
(cherry picked from commit b90f86be161c74df8cb69c98d9f22885d9d87114)
Signed-off-by: Konrad Rzeszutek Wilk
Conflicts:
xen/arch/x86/domctl.c
xen/arch/x86/msr.c
xen/include/asm-x86/msr.h
[But since Xen 4.4 does not have CPUID faulting this just adds
the infrastructure pieces and comments out the MSR_INTEL_MISC_FEATURES_ENABLES.
Also we ignore completely the XEN_DOMCTL_get_vcpu_msrs and
XEN_DOMCTL_set_vcpu_msrs hypercall handling. Which is used to filter
out more selectively which payloads should be migrated over (for example
the guest may not have used the MSR handling code). But in Xen 4.4
it uses the XEN_DOMCTL_gethvmcontext which internally calls hvm_save
which walks over all of the functions that registered via
hvm_save_cpu_msrs - which we didnt do as the .init has never
been set or called - so for all intent and purpose this is a NOP]
Signed-off-by: Boris Ostrovsky
Removed unused rc in hvm_load_cpu_msrs()
This patch is backported from OVS345.
upstream commit: b90f86be161c74df8cb69c98d9f22885d9d87114
OVS345 commit: 744a3f074e93edf9323c2a3c734064c36610210a
Backported-by: Dongli Zhang
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.117]
- From 3a389c0fde448b72f9bc16e1a04b352178ead5b5 Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan
Date: Sun, 14 Jan 2018 03:45:49 +0800
Subject: [PATCH 23/77] x86/hvm: Dont corrupt the HVM context stream when
writing the MSR record
Ever since it was introduced in c/s bd1f0b45ff, hvm_save_cpu_msrs() has had a
bug whereby it corrupts the HVM context stream if some, but fewer than the
maximum number of MSRs are written.
_hvm_init_entry() creates an hvm_save_descriptor with length for
msr_count_max, but in the case that we write fewer than max, h->cur only moves
forward by the amount of space used, causing the subsequent
hvm_save_descriptor to be written within the bounds of the previous one.
To resolve this, reduce the length reported by the descriptor to match the
actual number of bytes used.
A typical failure on the destination side looks like:
(XEN) HVM4 restore: CPU_MSR 0
(XEN) HVM4.0 restore: not enough data left to read 56 MSR bytes
(XEN) HVM4 restore: failed to load entry 20/0
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
Release-acked-by: Julien Grall
(cherry picked from commit d2f86bf604698806d311cc251c1b66fbb752673c)
Signed-off-by: Konrad Rzeszutek Wilk
This patch is backported from OVS345.
upstream commit: d2f86bf604698806d311cc251c1b66fbb752673c
OVS345 commit: 6b9bf9bad2b25c07c4d1161a43c293c10e5c8014
Backported-by: Dongli Zhang
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.116]
- From 8dc3747a3de2513a19ddc7b720ccd8eba62b3260 Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan
Date: Sun, 14 Jan 2018 03:45:17 +0800
Subject: [PATCH 22/77] x86: generic MSRs save/restore
This patch introduces a generic MSRs save/restore mechanism, so that
in the future new MSRs save/restore could be added w/ smaller change
than the full blown addition of a new save/restore type.
Signed-off-by: Jan Beulich
Reviewed-by: Liu Jinsong
Acked-by: Keir Fraser
(cherry picked from commit bd1f0b45ff1fde2de8d2a2b397b9686a1185ed4e)
Signed-off-by: Konrad Rzeszutek Wilk
This patch is backported from OVS345.
upstream commit: bd1f0b45ff1fde2de8d2a2b397b9686a1185ed4e
OVS345 commit: fce3f56b95e3e6135efaaef377ac9c6666b7a222
Backported-by: Dongli Zhang
Code surrounding the changes is slightly different.
Conflicts:
xen/arch/x86/hvm/hvm.c
xen/include/public/arch-x86/hvm/save.h
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.115]
- From 5e6b1c7037b401afa33dd6df336cd3fe531b61fb Mon Sep 17 00:00:00 2001
From: Ankur Arora
Date: Mon, 22 Jan 2018 18:48:15 -0800
Subject: [PATCH 21/77] x86/msr: allocation fixes to d->arch.msr
Allocate d->arch.msr for both i386 and x86-64 in the idle
domain case. This is not necessary for correctness (we
dont support 32-bit Xen) but this way we dont need separate
handle for xfree depending on whether it is i386 or x86-64 path.
Additionally fail right away, in case of failure to allocate.
OraBug: 27370020
Signed-off-by: Ankur Arora
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.114]
- From bf7d3827f2bf3daad688d6897da4c9be10f04dfa Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan
Date: Sun, 14 Jan 2018 03:44:33 +0800
Subject: [PATCH 20/77] x86/msr: introduce guest_wrmsr()
The new function is responsible for handling WRMSR from both HVM and PV
guests. Currently it handles only 2 MSRs:
MSR_INTEL_PLATFORM_INFO
MSR_INTEL_MISC_FEATURES_ENABLES
It has a different behaviour compared to the old MSR handlers: if MSR
is being handled by guest_wrmsr() then WRMSR will either succeed (if
a guest is allowed to access it and provided a correct value based on
its MSR policy) or produce a GP fault. A guest will never see
a successful WRMSR of some MSR unknown to this function.
guest_wrmsr() unifies and replaces the handling code from
vmx_msr_write_intercept() and priv_op_write_msr().
Signed-off-by: Sergey Dyasli
This also fixes a bug on AMD hardware where a guest which tries to
enable CPUID faulting via a direct write to the MSR will observe it
appearing to succeed, but because Xen actually ignored the write.
Reviewed-by: Andrew Cooper
Reviewed-by: Kevin Tian
(cherry picked from commit 664adc5ccab1388ea8ff4dd476473d04effaa2c8)
Signed-off-by: Konrad Rzeszutek Wilk
Conflicts:
xen/arch/x86/hvm/hvm.c
xen/arch/x86/hvm/vmx/vmx.c
xen/arch/x86/pv/emul-priv-op.c
[Which is mostly b/c we are not backporting the CPUID fault framework
and CPUID policy - as such most of this code is just NOP.
We do have to handle the return case more explicitly as we dont
have the full framework to just return a value, we must also
act on it (move the EIP if #GP for example)]
Signed-off-by: Boris Ostrovsky
Removed the (now) unneded label and local variable
This patch is backported from OVS345.
upstream commit: 664adc5ccab1388ea8ff4dd476473d04effaa2c8
OVS345 commit: 4875fd148cfb8e5b58613e56b2c91b55a480174a
Conflicts with OVS345 patch:
xen/arch/x86/hvm/hvm.c
Backported-by: Dongli Zhang
Function hvm_msr_write_intercept() starts with different local variables,
which surround one of the changes and causes a conflict.
Conflicts:
xen/arch/x86/hvm/hvm.c
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.113]
- From b90430eedcedbd400459c05f21dcdb40ba2e8a66 Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan
Date: Sun, 14 Jan 2018 03:43:57 +0800
Subject: [PATCH 19/77] x86/msr: introduce guest_rdmsr()
The new function is responsible for handling RDMSR from both HVM and PV
guests. Currently it handles only 2 MSRs:
MSR_INTEL_PLATFORM_INFO
MSR_INTEL_MISC_FEATURES_ENABLES
It has a different behaviour compared to the old MSR handlers: if MSR
is being handled by guest_rdmsr() then RDMSR will either succeed (if
a guest is allowed to access it based on its MSR policy) or produce
a GP fault. A guest will never see a H/W value of some MSR unknown to
this function.
guest_rdmsr() unifies and replaces the handling code from
vmx_msr_read_intercept() and priv_op_read_msr().
Signed-off-by: Sergey Dyasli
This (along with the prep work in init_domain_msr_policy()) also fixes
a bug where Dom0 could probe and find CPUID faulting, even though it
couldnt actually use it.
Reviewed-by: Andrew Cooper
Reviewed-by: Kevin Tian
(cherry picked from commit 37f074a33831633118735b61c6f4e7b413792629)
Signed-off-by: Konrad Rzeszutek Wilk
Conflicts:
xen/arch/x86/hvm/hvm.c
xen/arch/x86/hvm/vmx/vmx.c
xen/arch/x86/msr.c
xen/arch/x86/pv/emul-priv-op.c
[Granted we dont actually have any of those MSRs to handle so this
just code that adds this support and is a NOP.
And we also have to handle the return in a more obvious fashion
than just returning - that it handle the #GP if needed.]
Signed-off-by: Boris Ostrovsky
Remove the (now) unused gp_fault label and dp variable;
This patch is backported from OVS345.
upstream commit: 37f074a33831633118735b61c6f4e7b413792629
OVS345 commit: 872f5dfaad4970632fd9e3d3efbb8b588882c433
Conflicts with OVS345 patch:
xen/arch/x86/hvm/hvm.c
Backported-by: Dongli Zhang
Function hvm_msr_read_intercept() starts with different local variables,
which surround one of the changes and causes a conflict.
Conflicts:
xen/ar/x86/hvm/hvm.c
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.112]
- From 56ff7617a3fe963a768d1c15dc0948af131ce501 Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan
Date: Sun, 14 Jan 2018 03:42:28 +0800
Subject: [PATCH 18/77] x86/msr: introduce struct msr_domain_policy
The new structure contains information about guests MSRs that are
shared between all domains vCPUs. It starts with only 1 MSR:
MSR_INTEL_PLATFORM_INFO
Which currently has only 1 usable bit: cpuid_faulting.
Add 2 global policy objects: hvm_max and pv_max that are inited during
boot up. Its always possible to emulate CPUID faulting for HVM guests
while for PV guests the H/W support is required.
Add init_domain_msr_policy() which sets initial MSR policy during
domain creation with a special case for Dom0.
Signed-off-by: Sergey Dyasli
Reviewed-by: Andrew Cooper
Reviewed-by: Kevin Tian
(cherry picked from commit 4098b092e1902de9925342a527f8173cdb376426)
Signed-off-by: Konrad Rzeszutek Wilk
Conflicts:
xen/arch/x86/domain.c
xen/arch/x86/setup.c
xen/include/asm-x86/domain.h
xen/include/asm-x86/msr.h
[As we dont have fb034f42, and in fact we dont have code to
handle MSR_INTEL_PLATFORM_INFO so this whole backport is just
to add the basic code]
This patch is backported from OVS345.
upstream commit: 4098b092e1902de9925342a527f8173cdb376426
OVM345 commit: d4c8753d0833fd243feac51455f2b201562c2922
Conflicts with OVS345 patch:
xen/arch/x86/domain.c
xen/arch/x86/msr.c
xen/include/asm-x86/msr.h
Backported-by: Dongli Zhang
Function arch_domain_create() has a slightly different structure for
initial handling of the idle domain. Modify the code to fit into this
different structure.
In domain.h, the surrounding code to the change is just slightly different.
Conflicts:
xen/arch/x86/domain.c
xen/include/asm-x86/domain.h
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.111]
- From d30c90307eabea416e98548193621bf92a888ece Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan
Date: Sun, 14 Jan 2018 01:28:49 +0800
Subject: [PATCH 17/77] microcode: Always scan the initramfs for microcode
And also include the microcode information in the dmesg.
Signed-off-by: Konrad Rzeszutek Wilk
This patch is backported from OVS345.
OVM345 commit: 5e6b4df47e81b4215a7a1d8de3c5b48a333b8b4f
Backported-by: Dongli Zhang
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.110]
- From c4568457e1adc43ea7c84eb1723fe835acb2b44d Mon Sep 17 00:00:00 2001
From: Ross Lagerwall
Date: Sun, 14 Jan 2018 01:27:59 +0800
Subject: [PATCH 16/77] x86: Move microcode loading earlier
Move microcode loading earlier for the boot CPU and secondary CPUs so
that it takes place before identify_cpu() is called for each CPU.
Without this, the detected features may be wrong if the new microcode
loading adjusts the feature bits. That could mean that some fixes (e.g.
d6e9f8d4f35d (x86/vmx: fix vmentry failure with TSX bits in LBR))
dont work as expected.
Previously during boot, the microcode loader was invoked for each
secondary CPU started and then again for each CPU as part of an
initcall. Simplify the code so that it is invoked exactly once for each
CPU during boot.
Signed-off-by: Ross Lagerwall
Reviewed-by: Andrew Cooper
Tested-by: Andrew Cooper
Release-acked-by: Julien Grall
(cherry picked from commit f97838bbd980a0104e16c4a12fbf514f9fa805f1)
Signed-off-by: Konrad Rzeszutek Wilk
Conflicts:
xen/arch/x86/cpu/common.c
xen/arch/x86/setup.c
xen/arch/x86/smpboot.c
xen/include/asm-x86/processor.h
This patch is backported from OVS345.
upstream commit: f97838bbd980a0104e16c4a12fbf514f9fa805f1
OVS345 commit: e9b8b96e2aeefbb561ef85364d0313fb29a5994d
Conflicts with OVS345 patches:
- change true/false to 1/0
- change bool to bool_t
Backported-by: Dongli Zhang
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.109]
- From 7fd0f615b3b65135e99d427b61248a33fab20930 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Sun, 14 Jan 2018 01:27:08 +0800
Subject: [PATCH 15/77] x86/traps: make panic and reboot paths safe during
early boot
Reverse two conditions in show_registers(). For an early crash, it is not
safe to dereference current for its HVM status before knowing that it is a
guest vcpu.
Introduce SYS_STATE_smp_boot to distinguish the point at which APs need
considering before boot is complete. There is one code change required as a
result; .init.text symbols are still in use before Xen is active, so alter its
predicate in is_active_kernel_text().
Make use of SYS_STATE_smp_boot in machine_{halt,restart}(). Before Xen starts
booting the APs, any execution here is certainly the BSP.
When halting or rebooting particularly early, this avoids the risks of a #PF
or #GP when accessing the LAPIC before generic_apic_probe(), as well as trying
to enable interrupts before init_IRQ() is complete.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
upstream commit: 415738e2f6e5635b537cbf93a5a1620b15afff6f
Conflicts:
xen/arch/x86/x86_64/traps.c
Backported-by: Dongli Zhang
Function is_active_kernel_text() doesnt exist, so create it.
Conflicts:
xen/common/symbols.c
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.108]
- From 91d961f66c697813db599c232597b8e116fdcd2e Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Sun, 14 Jan 2018 01:20:16 +0800
Subject: [PATCH 14/77] x86/microcode: Check whether the microcode is correct
We do the microcode code update in two steps - the presmp:
microcode_presmp_init and when CPUs are brought up: microcode_init.
The earlier performs the microcode update on the BSP - but
unfortunately it does not check whether the update failed. Which means
that we might try later to update a incorrect payload on the rest of
CPUs.
This patch handles this odd situation.
Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Andrew Cooper
Acked-by: Keir Fraser
upstream commit: 4deea8515b1caba8803816399068f2a75d65f8ad
Backported-by: Dongli Zhang
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.107]
- From 32fd843dcf4866469457782a049112821d55a011 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Fri, 27 Sep 2013 10:22:55 +0200
Subject: [PATCH 13/77] x86/microcode: Scan the initramfs payload for microcode
blob
The Linux kernel is able to update the microcode during early bootup
via inspection of the initramfs blob to see if there is an cpio image
with certain microcode files. Linux is able to function with two (or
more) cpio archives in the initrd b/c it unpacks all of the cpio
archives.
The format of the early initramfs is nicely documented in Linuxs
Documentation/x86/early-microcode.txt:
Early load microcode
====================
By Fenghua Yu
Kernel can update microcode in early phase of boot time. Loading microcode early
can fix CPU issues before they are observed during kernel boot time.
Microcode is stored in an initrd file. The microcode is read from the initrd
file and loaded to CPUs during boot time.
The format of the combined initrd image is microcode in cpio format followed by
the initrd image (maybe compressed). Kernel parses the combined initrd image
during boot time. The microcode file in cpio name space is:
kernel/x86/microcode/GenuineIntel.bin
During BSP boot (before SMP starts), if the kernel finds the microcode file in
the initrd file, it parses the microcode and saves matching microcode in memory.
If matching microcode is found, it will be uploaded in BSP and later on in all
APs.
The cached microcode patch is applied when CPUs resume from a sleep state.
There are two legacy user space interfaces to load microcode, either through
/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file
in sysfs.
In addition to these two legacy methods, the early loading method described
here is the third method with which microcode can be uploaded to a systems
CPUs.
The following example script shows how to generate a new combined initrd file in
/boot/initrd-3.5.0.ucode.img with original microcode microcode.bin and
original initrd image /boot/initrd-3.5.0.img.
mkdir initrd
cd initrd
mkdir kernel
mkdir kernel/x86
mkdir kernel/x86/microcode
cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin
find .|cpio -oc >../ucode.cpio
cd ..
cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img
As such this code inspects the initrd to see if the microcode
signatures are present and if so updates the hypervisor.
The option to turn this scan on/off is gated by the ucode
parameter. The options are now:
scan Scan for the microcode in any multiboot payload.
Attempt to load microcode blob (not the cpio archive
format) from the multiboot payload number.
This option alters slightly the ucode parameter by only allowing
either parameter:
ucode=[|scan]
Implementation wise the ucode_blob is defined as __initdata.
That is OK from the viewpoint of suspend/resume as the the underlaying
architecture microcode (microcode_intel or microcode_amd) end up saving
the blob in struct ucode_cpu_info which is a per-cpu data
structure (see ucode_cpu_info). They end up saving it when doing the
pre-SMP (for CPU0) and SMP (for the rest) microcode loading.
Naturally if one does a hypercall to update the microcode and it is
newer, then the old per-cpu data is replaced.
Signed-off-by: Konrad Rzeszutek Wilk
Acked-by: Keir Fraser
(cherry picked from commit 155587481e392e4261038364e2761aab27f597ed)
OraBug: 27370020
Signed-off-by: Elena Ufimtseva
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.106]
- From 4d1d3aa8ac20a539e752c3a4a35dc7d0760cd9b3 Mon Sep 17 00:00:00 2001
From: Boris Ostrovsky
Date: Tue, 7 Feb 2012 15:05:19 +0100
Subject: [PATCH 12/77] x86/microcode: add start_update to microcode ops
Adopted from commit from OVS-3.4.2
8cbb5278e034e5d7878f7a6a7d6987e5a7acf986
x86/AMD: Add support for AMDs OSVW feature in guests.
Backported commit does not support AMD OSVW feauture.
OraBug: 27370020
Signed-off-by: Elena Ufimtseva
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.105]
- From ee816c51d66e7dc866963c69ab300d5f3466839b Mon Sep 17 00:00:00 2001
From: Elena Ufimtseva
Date: Mon, 22 Jan 2018 10:35:15 -0500
Subject: [PATCH 11/77] x86/microcode: enable boot time (pre-Dom0) loading
Largely as a result of the continuing resistance of Linux maintainers
to accept a microcode loading patch for pv-ops Xen kernels, this
follows the suggested route and provides a means to load microcode
updates without the assistance of Dom0, thus also addressing eventual
problems in the hardware much earlier.
This leverages the fact that via the multiboot protocol another blob
of data can be easily added in the form of just an extra module. Since
microcode data cannot reliably be recognized by looking at the
provided data, this requires (in the non-EFI case) the use of a
command line parameter (ucode=) to identify which of the
modules is to be parsed for an eventual microcode update (in the EFI
case the module is being identified in the config file, and hence the
command line argument, if given, will be ignored).
This required to adjust the XSM module determination logic accordingly.
The format of the data to be provided is the raw binary blob already
used for AMD CPUs, and the output of the intel-microcode2ucode utility
for the Intel case (either the per-(family,model,stepping) file or -
to make things easier for distro-s integration-wise - simply the
concatenation of all of them).
In order to not convert the spin_lock() in microcode_update_cpu() (and
then obviously also all other uses on microcode_mutex) to
spin_lock_irqsave() (which would be undesirable for the hypercall
context in which the function also runs), the boot time handling gets
done using a tasklet (instead of using on_selected_cpus()).
Signed-off-by: Jan Beulich
Acked-by: Keir Fraser
xen/arch/x86/efi/boot.c doesnt exist, ignore those changes.
Add missing functions microcode_percpu_callback() and
microcode_presmp_init() as well as missing struct microcode_percpu_nfb
to microcode.c.
Add missing prototype for xen_in_range() to setup.h.
Conflicts:
xen/arch/x86/efi/boot.c
xen/arch/x86/microcode.c
xen/include/asm-x86/setup.h
OraBug: 27370020
Signed-off-by: Elena Ufimtseva
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.104.2]
- From bcaff335b5a8af546a14ba635a9a558967d0b5fe Mon Sep 17 00:00:00 2001
From: Jan Beulich
Date: Thu, 4 Feb 2016 11:38:52 +0100
Subject: [PATCH 10/77] x86: support 2- and 3-way alternatives
Parts taken from Linux, but implementing the ALTERNATIVE*() macros
recursively to avoid needless redundancy.
Also make the .discard section non-writable (we might even consider
dropping its alloc flag too) and limit the pushing and popping of
sections.
Signed-off-by: Jan Beulich
(cherry picked from commit 6f8e41c67a884b5eaa321bd58fdcf593179f5f2c)
Conflicts:
xen/include/asm-x86/alternative.h
[As we didnt backport da62246e4c x86/xsaves: enable xsaves/xrstors/xsavec in xen
which added:
+#define ASM_OUTPUT2(a...) a
in the header file]
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
CVE: CVE-2017-5715/CVE-2017-5753/CVE-2017-5754
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.104.1]
- From c996759c21814071f1c1f065019058666370a48c Mon Sep 17 00:00:00 2001
From: Borislav Petkov
Date: Sat, 3 Dec 2016 16:02:58 +0100
Subject: [PATCH 09/77] xen/x86/alternatives: Do not use sync_core() to
serialize I$
We use sync_core() in the alternatives code to stop speculative
execution of prefetched instructions because we are potentially changing
them and dont want to execute stale bytes.
What it does on most machines is call CPUID which is a serializing
instruction. And thats expensive.
However, the instruction cache is serialized when were on the local CPU
and are changing the data through the same virtual address. So then, we
dont need the serializing CPUID but a simple control flow change. Last
being accomplished with a CALL/RET which the noinline causes.
Suggested-by: Linus Torvalds
Signed-off-by: Borislav Petkov
Reviewed-by: Andy Lutomirski
[Linux commit 34bfab0eaf0fb5c6fb14c6b4013b06cdc7984466]
Ported to Xen.
Signed-off-by: Andrew Cooper
Acked-by: Konrad Rzeszutek Wilk
Acked-by: Jan Beulich
(cherry picked from commit b01c2fb5834aea0328db55c310caa34173021d3d)
Conflicts:
xen/arch/x86/livepatch.c
[As the name of the arch_livepatch_apply/arch_livepatch_revert
is what is upstream but we have the jmp in the name, hence
we get a conflict]
Signed-off-by: Konrad Rzeszutek Wilk
patched on text_poke_early directly as we didnt support livepatch
and dont have apply_alternatives_nocheck, etc.
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
CVE: CVE-2017-5715/CVE-2017-5753/CVE-2017-5754
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.104]
- From 866ec76371eb282b79cb92a5fbd0a348c982b43b Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Wed, 30 Mar 2016 13:45:59 -0400
Subject: [PATCH 08/77] x86: Alter nmi_callback_t typedef
Drop paranthesis and function pointer on nmi_callback_t typedef.
Make it more inline with how x86 maintainers want function
typedefs to be.
Signed-off-by: Konrad Rzeszutek Wilk
Acked-by: Andrew Cooper
Prerequisite patch to avoid compile error
Conflict:
xen/include/asm-x86/nmi.h
Remove const type declare for nmi callback
I didnt use the commit from OVM3.4.5 as its partial, use upstream one
instead.
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.103.2]
- From 7a5cc3b9f395a0d708e3d26b001e6b52ff50311e Mon Sep 17 00:00:00 2001
From: Jan Beulich
Date: Wed, 9 Mar 2016 16:51:16 +0100
Subject: [PATCH 07/77] x86/alternatives: correct near branch check
Make sure the near JMP/CALL check doesnt consume uninitialized
data, not even in a benign way. And relax the length check at once.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
(cherry picked from commit cd29140ef0e65a33d62e7f5ee843077e51913f01)
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
CVE: CVE-2017-5715/CVE-2017-5753/CVE-2017-5754
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.103.1]
- From 9a7cfafedd55c603a1cc3ad9d2ef706f03eda377 Mon Sep 17 00:00:00 2001
From: Andrew Cooper
Date: Thu, 25 Feb 2016 13:06:16 +0100
Subject: [PATCH 06/77] x86: disable CR0.WP while applying alternatives
In preparation for marking .text as read-only, care needs to be taken not to
fault while applying alternatives.
Swapping back to RW mappings is a possibility, but would require additional
TLB management. A temporary disabling of CR0.WP is cleaner.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
(cherry picked from commit 36c672b559d35e088b181c67538b1ed5bacb0da5)
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
CVE: CVE-2017-5715/CVE-2017-5753/CVE-2017-5754
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.103]
- From bd25188717f83daaccef5a83679aa0c119896ce9 Mon Sep 17 00:00:00 2001
From: Jan Beulich
Date: Mon, 30 Jun 2014 16:01:03 +0200
Subject: [PATCH 05/77] x86: move alternative.c data fully into .init.*
This wasnt done upon the initial addition of the file since the
section processing needs some adjustment for this: We cant mark the
two arrays needing relocations as either __initdata or __initconst, as
both have the potential of creating section conflicts (with -fPIC the
compiler may want to mark the section writable due to the necessary
relocations, colliding with other __initconst uses, and if the compiler
chooses to use the provided section name, __initdata on a constant
object might collide with other __initdata uses). However, local data
known to be referenced only by init code/data can also safely be moved
into .init.*. Hence the respective logic is being tweaked such that it
wont complain on non-empty .*.local sections.
Signed-off-by: Jan Beulich
(cherry picked from commit eb2952b43a70ae485e297f826212b6b279ca0361)
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
In older Xen, there are no obj-bin-y lines nor are there any other files
that get compiled to .init.o. To keep this as close to the original patch
as possible, also add the SPECIAL_DATA_SECTIONS and corresponding
filter.... This at least allows the code to be compiled, although maybe
theres a more compatible way to do this.
Conflicts:
xen/Rules.mk
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.102]
- From 089e6507c37383ae835708b7b56564e852530482 Mon Sep 17 00:00:00 2001
From: Feng Wu
Date: Tue, 3 Jun 2014 11:31:21 +0200
Subject: [PATCH 04/77] x86: port the basic alternative mechanism from Linux to
Xen
This patch ports the basic alternative mechanism from Linux to Xen.
With this mechanism, we can patch code based on the CPU features.
Signed-off-by: Feng Wu
Reviewed-by: Jan Beulich
(cherry picked from commit 5542ac7f908c2819fcedb06ee9dc24af94d89566)
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
The original patch places changes after the trampoline code in .init.data.
However, this version does not have any trampoline entries in .init.data,
so we just place the code in the otherwise equivalent spot.
Conflicts:
xen/arch/x86/xen.lds.S
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.101.1]
- From 4c190d2aab608d7e6cee9571952b27fa0472e2ac Mon Sep 17 00:00:00 2001
From: Feng Wu
Date: Tue, 3 Jun 2014 11:29:12 +0200
Subject: [PATCH 03/77] x86: add definitions for NOP operation
This patch adds definitions for different length of NOP operation.
Signed-off-by: Feng Wu
Reviewed-by: Andrew Cooper
(cherry-picked from commit 1911b1b3106f410e411115ba8ac0ac69718ca9bf)
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
CVE: CVE-2017-5715/CVE-2017-5753/CVE-2017-5754
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.101]
- From 30f769e2286bad5526abe2779ad61ff62cf5ed9d Mon Sep 17 00:00:00 2001
From: Feng Wu
Date: Tue, 3 Jun 2014 11:29:38 +0200
Subject: [PATCH 02/77] x86: make set_nmi_callback return the old nmi callback
This patch makes set_nmi_callback return the old nmi callback, so
we can set it back later.
Signed-off-by: Feng Wu
Reviewed-by: Andrew Cooper
Prerequisite patch to avoid compile error
Signed-off-by: Zhenzhong Duan
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}

[4.1.3-25.el5.223.100]
- From b6b84d83525e906471e5d6742cfbf8bb00be3f92 Mon Sep 17 00:00:00 2001
From: Julien Grall
Date: Wed, 28 Aug 2013 15:47:16 +0100
Subject: [PATCH 01/77] xen: Introduce __initconst to store initial const data
Its possible to have 2 type (const and non-const) of data in the same
compilation unit. Using only __initdata will result to a compilation error:
error: causes as section tupe conflict with
because a section containing const variables is marked read only and so cannot
contain non-const variables.
Signed-off-by: Julien Grall
Acked-by: Ian Cambell
CC: Jan Beulich
CC: Keir Fraser
Prerequisite patch to avoid compile issue
Signed-off-by: Zhenzhong Duan
The format of the defines in init.h are slightly different. Modify the
format to match the rest of the surrounding defines.
Conflicts:
xen/include/xen/init.h
OraBug: 27370020
Signed-off-by: Patrick Colp
Reviewed-by: Konrad Rzeszutek Wilk [bug 27370020] {CVE-2017-5715/CVE-2017-5753/CVE-2017-5754} {CVE-2017-5715} {CVE-2017-5753} {CVE-2017-5754}


Related CVEs


CVE-2017-5715
CVE-2017-5753
CVE-2017-5754

Updated Packages


Release/ArchitectureFilenameMD5sumSuperseded By Advisory
Oracle VM 3.2 (x86_64) xen-4.1.3-25.el5.223.166.src.rpme8395fe6c9ff41555f9fea3e26682a09OVMSA-2021-0014
xen-4.1.3-25.el5.223.166.x86_64.rpmf7a46e95549a086a6d02951151e9c41eOVMSA-2021-0014
xen-devel-4.1.3-25.el5.223.166.x86_64.rpm29e5ca8dd0feec95bcd89c2b5fd186cfOVMSA-2019-0048
xen-tools-4.1.3-25.el5.223.166.x86_64.rpm7e546743b0c81be1e02aed08d97334b0OVMSA-2021-0014



This page is generated automatically and has not been checked for errors or omissions. For clarification or corrections please contact the Oracle Linux ULN team

software.hardware.complete