[Oraclevm-errata] OVMSA-2018-0271 Important: Oracle VM 3.3 xen security update
Errata Announcements for Oracle VM
oraclevm-errata at oss.oracle.com
Wed Nov 14 08:50:02 PST 2018
Oracle VM Security Advisory OVMSA-2018-0271
The following updated rpms for Oracle VM 3.3 have been uploaded to the
Unbreakable Linux Network:
x86_64:
xen-4.3.0-55.el6.186.195.x86_64.rpm
xen-tools-4.3.0-55.el6.186.195.x86_64.rpm
SRPMS:
http://oss.oracle.com/oraclevm/server/3.3/SRPMS-updates/xen-4.3.0-55.el6.186.195.src.rpm
Description of changes:
[4.3.0-55.el6.186.195]
- From 7d8b5dd98463524686bdee8b973b53c00c232122 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu at intel.com>
Date: Mon, 25 Nov 2013 11:19:04 +0100
Subject: [PATCH v2 6/6] x86/xsave: fix nonlazy state handling
Nonlazy xstates should be xsaved each time when vcpu_save_fpu.
Operation to nonlazy xstates will not trigger #NM exception, so
whenever vcpu scheduled in it got restored and whenever scheduled
out it should get saved.
Currently this bug affects AMD LWP feature, and later Intel MPX
feature. With the bugfix both LWP and MPX will work fine.
Signed-off-by: Liu Jinsong <jinsong.liu at intel.com>
Furthermore, during restore we also need to set nonlazy_xstate_used
according to the incoming accumulated XCR0.
Also adjust the changes to i387.c such that there won't be a pointless
clts()/stts() pair.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Based on commit from OVM3.4.5
(cherry picked from commit 7d8b5dd98463524686bdee8b973b53c00c232122)
Backported-by: Jie Li <jie.l.li at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Darren Kenny <darren.kenny at oracle.com> [bug 28555335]
{CVE-2018-3665}
[4.3.0-55.el6.186.194]
- From 32df6a92ef8065da5ab471f86ab9c67df29fcafa Mon Sep 17 00:00:00 2001
From: Jan Beulich <jbeulich at suse.com>
Date: Mon, 30 Jul 2018 14:17:45 +0200
Subject: [PATCH v2 5/6] 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
Orabug: 28696347
Signed-off-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovksy at oracle.com>
Based on commit from OVM3.4.5
(Cherry-picked from: 32df6a92ef8065da5ab471f86ab9c67df29fcafa)
Backported-by: Jie Li <jie.l.li at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Darren Kenny <darren.kenny at oracle.com> [bug 28555335]
{CVE-2018-3665}
[4.3.0-55.el6.186.193]
- From f9f5f0bb3188437559ca74021b24b83fe52947d4 Mon Sep 17 00:00:00 2001
From: Jan Beulich <jbeulich at suse.com>
Date: Thu, 28 Jun 2018 12:28:21 +0200
Subject: [PATCH v2 4/6] 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
Orabug: 28696347
Signed-off-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovksy at oracle.com>
Based on commit from OVM3.4.5
(Cherry-picked from: f9f5f0bb3188437559ca74021b24b83fe52947d4)
Conflicts:
- context difference only
Backported-by: Jie Li <jie.l.li at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Darren Kenny <darren.kenny at oracle.com> [bug 28555335]
{CVE-2018-3665}
[4.3.0-55.el6.186.192]
- From fccf5221ce4a55268e31a6c069b4889ee35416e6 Mon Sep 17 00:00:00 2001
From: Jan Beulich <jbeulich at suse.com>
Date: Thu, 28 Jun 2018 12:27:56 +0200
Subject: [PATCH v2 3/6] x86/EFI: further correct FPU state handling
around runtime calls
We must not leave a vCPU with CR0.TS clear when it is not in fully eager
mode and has not touched non-lazy state. Instead of adding a 3rd
invocation of stts() to vcpu_restore_fpu_eager(), consolidate all of
them into a single one done at the end of the function.
Rename the function at the same time to better reflect its purpose, as
the patches touches all of its occurences anyway.
The new function parameter is not really well named, but
"need_stts_if_not_fully_eager" seemed excessive to me.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Paul Durrant <paul.durrant at citrix.com>
Cherry-picked from: b7b7c4df2d251b1feba217939ea0b618094a48c2
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>
The previous version of this patch was reverted. This second version
of this patch fixes a crash in xrstor due to idle domain threads not
having an xsave area which leads to a NULL ptr deref. When Xen is
booted as an EFI boot loader, it calls run time services at early
boot time where this occurs on an idle domain vcpu. The fix is to check
for a NULL xsave_area in xsave() and xrstor().
Orabug: 28746888
Signed-off-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovksy at oracle.com>
Based on commit from OVM3.4.5
(Cherry-picked from: fccf5221ce4a55268e31a6c069b4889ee35416e6)
Conflicts:
- context differences
- is_hvm_vcpu() is used instead of is_pv_vcpu() due to 3.3 doesn't
have the latter
Backported-by: Jie Li <jie.l.li at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Darren Kenny <darren.kenny at oracle.com> [bug 28555335]
{CVE-2018-3665}
[4.3.0-55.el6.186.191]
- From 8b43dba27c8ea017aae4908bb380693263624e10 Mon Sep 17 00:00:00 2001
From: Jan Beulich <jbeulich at suse.com>
Date: Thu, 28 Jun 2018 12:27:34 +0200
Subject: [PATCH v2 2/6] x86/EFI: fix FPU state handling around
runtime calls
There are two issues. First, the nonlazy xstates were never restored
after returning from the runtime call.
Secondly, with the fully_eager_fpu mitigation for XSA-267 / LazyFPU, the
unilateral stts() is no longer correct, and hits an assertion later when
a lazy state restore tries to occur for a fully eager vcpu.
Fix both of these issues by calling vcpu_restore_fpu_eager(). As EFI
runtime services can be used in the idle context, the idle assertion
needs to move until after the fully_eager_fpu check.
Introduce a "curr" local variable and replace other uses of "current"
at the same time.
Reported-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Tested-by: Juergen Gross <jgross at suse.com>
Cherry-picked from: ba7d0117ab535280e2b6821aa6d323053ac6b266
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>
The previous version of this patch was reverted. This second version
of this patch fixes a crash in xrstor due to idle domain threads not
having an xsave area which leads to a NULL ptr deref. When Xen is
booted as an EFI boot loader, it calls run time services at early
boot time where this occurs on an idle domain vcpu. The fix is to check
for a NULL xsave_area in xsave() and xrstor().
Orabug: 28746888
Signed-off-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovksy at oracle.com>
Based on commit from OVM3.4.5
(Cherry-picked from: 8b43dba27c8ea017aae4908bb380693263624e10)
Conflicts:
- context differences
- is_hvm_vcpu() is used instead of is_pv_vcpu() due to 3.3 doesn't
have the latter
Backported-by: Jie Li <jie.l.li at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Darren Kenny <darren.kenny at oracle.com> [bug 28555335]
{CVE-2018-3665}
[4.3.0-55.el6.186.190]
- From 3ed5db85b82cb67e669fdddffa205187a6343a9c Mon Sep 17 00:00:00 2001
From: Jan Beulich <jbeulich at suse.com>
Date: Tue, 24 Jun 2014 09:42:49 +0200
Subject: [PATCH v2 1/6] x86/EFI: allow FPU/XMM use in runtime service
functions
UEFI spec update 2.4B developed a requirement to enter runtime service
functions with CR0.TS (and CR0.EM) clear, thus making feasible the
already previously stated permission for these functions to use some of
the XMM registers. Enforce this requirement (along with the connected
ones on FPU control word and MXCSR) by going through a full FPU save
cycle (if the FPU was dirty) in efi_rs_enter() (along with loading the
specified values into the other two registers).
Note that the UEFI spec mandates that extension registers other than
XMM ones (for our purposes all that get restored eagerly) are preserved
across runtime function calls, hence there's nothing we need to restore
in efi_rs_leave() (they do get saved, but just for simplicity's sake).
Signed-off-by: Jan Beulich <jbeulich at suse.com>
master commit: e0fe297dabc96d8161d568f19a99722c4739b9f9
master date: 2014-06-18 15:53:27 +0200
Based on commit from OVM3.4.5.
This is a prerequisite for XSA-267
(Cherry-picked from: 3ed5db85b82cb67e669fdddffa205187a6343a9c)
Conflicts:
- context difference only
Backported-by: Jie Li <jie.l.li at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Darren Kenny <darren.kenny at oracle.com> [bug 28555335]
{CVE-2018-3665}
[4.3.0-55.el6.186.189]
- From: Julien Grall <julien.grall at linaro.org>
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
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574332] {CVE-2018-3620}
[4.3.0-55.el6.186.188]
- From: Ross Philipson <ross.philipson at oracle.com>
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>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574332] {CVE-2018-3646} {CVE-2018-3620}
[4.3.0-55.el6.186.187]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
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>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574332] {CVE-2018-3646} {CVE-2018-3620}
[4.3.0-55.el6.186.186]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
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>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574332] {CVE-2018-3646} {CVE-2018-3620}
[4.3.0-55.el6.186.185]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
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>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574332] {CVE-2018-3646} {CVE-2018-3620}
[4.3.0-55.el6.186.184]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
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>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574332] {CVE-2018-3646} {CVE-2018-3620}
[4.3.0-55.el6.186.183]
- From: Jan Beulich <JBeulich at suse.com>
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>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574332] {CVE-2018-3646} {CVE-2018-3620}
[4.3.0-55.el6.186.182]
- From: Jan Beulich <jbeulich at suse.com>
While I've run into the issue with further patches in place which no
longer guarantee the per-CPU area to start out as all zeros, the
CPU_DOWN_FAILED processing looks to have the same issue: By not zapping
the per-CPU cpupool pointer, cpupool_cpu_add()'s (indirect) invocation
of schedule_cpu_switch() will trigger the "c != old_pool" assertion
there.
Clearing the field during CPU_DOWN_PREPARE is too early (afaict this
should not happen before cpu_disable_scheduler()). Clearing it in
CPU_DEAD and CPU_DOWN_FAILED would be an option, but would take the same
piece of code twice. Since the field's value shouldn't matter while the
CPU is offline, simply clear it (implicitly) for CPU_ONLINE and
CPU_DOWN_FAILED, but only for other than the suspend/resume case (which
gets specially handled in cpupool_cpu_remove()).
By adjusting the conditional in cpupool_cpu_add() CPU_DOWN_FAILED
handling in the suspend case should now also be handled better.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Juergen Gross <jgross at suse.com>
This is a prerequisite for XSA-273
Orabug: 28487050
(cherry picked from commit cb1ae9a27819cea0c5008773c68a7be6f37eb0e5)
Applied cleanly.
Signed-off-by: Ross Philipson <ross.philipson at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574332] {CVE-2018-3646} {CVE-2018-3620}
[4.3.0-55.el6.186.181]
- From: Dario Faggioli <dario.faggioli at citrix.com>
in fact, before this change, shutting down or suspending the
system with some CPUs not assigned to any cpupool, would
crash as follows:
(XEN) Xen call trace:
(XEN) [<ffff82d080101757>] disable_nonboot_cpus+0xb5/0x138
(XEN) [<ffff82d0801a8824>] enter_state_helper+0xbd/0x369
(XEN) [<ffff82d08010614a>]
continue_hypercall_tasklet_handler+0x4a/0xb1
(XEN) [<ffff82d0801320bd>] do_tasklet_work+0x78/0xab
(XEN) [<ffff82d0801323f3>] do_tasklet+0x5e/0x8a
(XEN) [<ffff82d080163cb6>] idle_loop+0x56/0x6b
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at cpu.c:191
(XEN) ****************************************
This is because, for free CPUs, -EBUSY were being returned
when trying to tear them down, making cpu_down() unhappy.
It is certainly unpractical to forbid shutting down or
suspenging if there are unassigned CPUs, so this change
fixes the above by just avoiding returning -EBUSY for those
CPUs. If shutting off, that does not matter much anyway. If
suspending, we make sure that the CPUs remain unassigned
when resuming.
While there, take the chance to:
- fix the doc comment of cpupool_cpu_remove() (it was
wrong);
- improve comments in general around and in cpupool_cpu_remove()
and cpupool_cpu_add();
- add a couple of ASSERT()-s for checking consistency.
Signed-off-by: Dario Faggioli <dario.faggioli at citrix.com>
Reviewed-by: Juergen Gross <jgross at suse.com>
Tested-by: Juergen Gross <jgross at suse.com>
This is a prerequisite for XSA-273
For OVM3.3 only and OVM3.4 already has the commit.
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574332] {CVE-2018-3620}
[4.3.0-55.el6.186.180]
- From: Juergen Gross <jgross at suse.com>
When shutting down the machine while there are cpus in a cpupool
other than
Pool-0 a crash is triggered due to cpupool handling rejecting
offlining the
non-boot cpus in other cpupools.
It is easy to detect this case and allow offlining those cpus.
Reported-by: Stefan Bader <stefan.bader at canonical.com>
Signed-off-by: Juergen Gross <jgross at suse.com>
Tested-by: Stefan Bader <stefan.bader at canonical.com>
master commit: 05377dede434c746e6708f055858378d20f619db
master date: 2014-07-23 18:03:19 +0200
This is a prerequisite for XSA-273
For OVM3.3 only and OVM3.4 already has the commit.
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574332] {CVE-2018-3620}
[4.3.0-55.el6.186.179]
- From: Dario Faggioli <dario.faggioli at citrix.com>
which means such an event must be handled at the call sites
of cpupool_assign_cpu_locked(), and the error, if occurring,
properly propagated.
Signed-off-by: Dario Faggioli <dario.faggioli at citrix.com>
Reviewed-by: Juergen Gross <jgross at suse.com>
This is a prerequisite for XSA-273
For OVM3.3 only and OVM3.4 already has the commit.
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28574332] {CVE-2018-3620}
[4.3.0-55.el6.186.178]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
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:
Context differences only
Orabug: 28135175
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.con>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28555335] {CVE-2018-3665} {CVE-2018-3665}
[4.3.0-55.el6.186.177]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
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:
Context differences only
Orabug: 28135175
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.con>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28555335] {CVE-2018-3665} {CVE-2018-3665}
[4.3.0-55.el6.186.176]
- From 2b1ac3ced59e3d0309572c146d74e90a2e861965 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 OVM3.3.x v2 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: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.175]
- From cf1d101056f5ac447d09dd3cefb5a560bfd8af8a 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 OVM3.3.x v2 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>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.174]
- From 5ce626add58bbe7b2d7463942d9c97e50aff97fb 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 OVM3.3.x v2 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
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.173]
- From b031a8b6e42f8ff595b7896c147056fc9fbea88c 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.3.x v2 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.
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.172]
- From 1c4bde7d9761d63cf9564a02f349351ccc9fdcd8 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 OVM3.3.x v2 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
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.171]
- From 86eac18feb0c1cbaa350e627176a99e9bd73297a 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 OVM3.3.x v2 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
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.170]
- From f76070cd46469b905d27c28308f95641f0414c2e 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 OVM3.3.x v2 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
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.169]
- From 6fb449d31503913d6187ccb9203f7d00094fa715 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 OVM3.3.x v2 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: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.168]
- From b3f576f2dc8fa64ddf05348463e1e6578f6050d8 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 OVM3.3.x v2 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>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.167]
- From 6fe58f4b6cddf7f0f7b7fc311073b15f6af316e0 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 OVM3.3.x v2 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: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.166]
- From ba52881d66d2fea15388b7cfff6376d66000c5d6 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 OVM3.3.x v2 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: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.165]
- From f1044f946c51be916e5eb0a2dd145994da006a55 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 OVM3.3.x v2 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>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.164]
- From 77992b0cb8994714bca172870b9b8718b6610cf8 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 OVM3.3.x v2 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: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.163]
- From 113e2c9fcff229fe762a3013b64239becb573c59 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 OVM3.3.x v2 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>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.162]
- From 3a41113ed77ca29b464ff873c6b09993c33c9f99 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 OVM3.3.x v2 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>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.161]
- From 94f998645d996baa2a60519ce8eab7e492a38a21 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 OVM3.3.x v2 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>
patch_name:0003-x86-spec_ctrl-Assume-that-STIBP-feature-is-always-av.patch
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.160]
- From 1d5367b2ac72d8a40b28fba05fa4ebefac02e43b 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 OVM3.3.x v2 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>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.159]
- From 20dfaeaed8391e17da89f2930c3b8a43bae08fba 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 OVM3.3.x v2 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: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
28061097] {CVE-2018-3639}
[4.3.0-55.el6.186.158]
- 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
27989661] {CVE-2018-8897}
[4.3.0-55.el6.186.157]
- 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
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
27989661] {CVE-2018-8897}
[4.3.0-55.el6.186.156]
- 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
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
27989661] {CVE-2018-8897}
[4.3.0-55.el6.186.155]
- 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>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
27989661] {CVE-2018-8897}
[4.3.0-55.el6.186.154]
- 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
27989661] {CVE-2018-8897}
[4.3.0-55.el6.186.153]
- 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: Ross Philipson <ross.philipson at oracle.com> [bug
27989755] {CVE-2018-10981}
[4.3.0-55.el6.186.152]
- 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
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
27989755] {CVE-2018-10981}
[4.3.0-55.el6.186.151]
- 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
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
27989686] {CVE-2018-10982}
[4.3.0-55.el6.186.150]
- x86/hvm/rtc: always deassert the IRQ line when clearing REG_C.IRQF
Even in no-ack mode, there's no reason to leave the line asserted
after an explicit ack of the interrupt.
Furthermore, rtc_update_irq() is an unconditional noop having just
cleared
REG_C.
Signed-off-by: Tim Deegan <tim at xen.org>
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
upstream commit: 6d27a537727ca933bfef8ba01bc65847dc97cee1
This is prerequisite patch for XSA-261.
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
27989686] {CVE-2018-10982}
[4.3.0-55.el6.186.149]
- x86/hvm/rtc: inject RTC periodic interupts from the vpt code
Let the vpt code drive the RTC's timer interrupts directly, as it does
for other periodic time sources, and fix up the register state in a
vpt callback when the interrupt is injected.
This fixes a hang seen on Windows 2003 in no-missed-ticks mode, where
when a tick was pending, the early callback from the VPT code would
always set REG_C.PF on every VMENTER; meanwhile the guest was in its
interrupt handler reading REG_C in a loop and waiting to see it clear.
One drawback is that a guest that attempts to suppress RTC periodic
interrupts by failing to read REG_C will receive up to 10 spurious
interrupts, even in 'strict' mode. However:
- since all previous RTC models have had this property (including
the current one, since 'no-ack' mode is hard-coded on) we're
pretty sure that all guests can handle this; and
- we're already playing some other interesting games with this
interrupt in the vpt code.
One other corner case: a guest that enables the PF timer interrupt,
masks the interupt in the APIC and then polls REG_C looking for PF
will not see PF getting set. The more likely case of enabling the
timers and masking the interrupt with REG_B.PIE is already handled
correctly.
Signed-off-by: Tim Deegan <tim at xen.org>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
upstream commit: c7e35c6ec705d777c0a11124ec28876f1468f2c5
This is prerequisite patch for XSA-261.
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
27989686] {CVE-2018-10982}
[4.3.0-55.el6.186.148]
- x86/hvm/rtc: don't run the vpt timer when !REG_B.PIE
If the guest has not asked for interrupts, don't run the vpt timer
to generate them. This is a prerequisite for a patch to simplify how
the vpt interacts with the RTC, and also gets rid of a timer series in
Xen in a case where it's unlikely to be needed.
Instead, calculate the correct value for REG_C.PF whenever REG_C is
read or PIE is enabled. This allow a guest to poll for the PF bit
while not asking for actual timer interrupts. Such a guest would no
longer get the benefit of the vpt's timer modes.
Signed-off-by: Tim Deegan <tim at xen.org>
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
upstream commit: 4c15a82f034c9c2213a18b6320834f3906d00ba9
This is prerequisite patch for XSA-261.
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
27989686] {CVE-2018-10982}
[4.3.0-55.el6.186.147]
- x86/hvm: fix restart of RTC periodic timer with vpt_align=1
The commit 58afa7ef "x86/hvm: Run the RTC periodic timer on a
consistent time series" aligns the RTC periodic timer to the VM's
boot time.
However, it's aligned later again to the system time in
create_periodic_time()
with vpt_align=1. The next tick might be skipped.
Signed-off-by: Kouya Shimura <kouya at jp.fujitsu.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Tim Deegan <tim at xen.org>
upstream commit: 48535f5798e3e237d9920a74c1ce3802958136c0
This is prerequisite patch for XSA-261.
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Ross Philipson <ross.philipson at oracle.com> [bug
27989686] {CVE-2018-10982}
[4.3.0-55.el6.186.146]
- 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
27827705] {CVE-2018-7541}
[4.3.0-55.el6.186.145]
- 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>
Conflict:
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
27827710] {CVE-2018-7541}
[4.3.0-55.el6.186.144]
- 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
27835053] {CVE-2018-7540}
More information about the Oraclevm-errata
mailing list