[Oraclevm-errata] OVMBA-2017-0032 Oracle VM 3.3 xen bug fix update
Errata Announcements for Oracle VM
oraclevm-errata at oss.oracle.com
Thu Jan 26 05:59:21 PST 2017
Oracle VM Bug Fix Advisory OVMBA-2017-0032
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.6.x86_64.rpm
xen-tools-4.3.0-55.el6.186.6.x86_64.rpm
SRPMS:
http://oss.oracle.com/oraclevm/server/3.3/SRPMS-updates/xen-4.3.0-55.el6.186.6.src.rpm
Description of changes:
[4.3.0-55.el6.186.6]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
Date: Sun, 18 Dec 2016 15:42:59 +0000
Subject: [PATCH] x86/emul: Correct the handling of eflags with SYSCALL
A singlestep #DB is determined by the resulting eflags value from the
execution of SYSCALL, not the original eflags value.
By using the original eflags value, we negate the guest kernels
attempt to
protect itself from a privilege escalation by masking TF.
Introduce a tf boolean and have the SYSCALL emulation recalculate it
after the instruction is complete.
This is XSA-204
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 25294877]
[4.3.0-55.el6.181]
- mm: Don't scrub memory if another processor on the same node is
already doing it
There is no reason to have two processors from the same node to scrub
memory
at the same time.
Original fix of the scrubbing problem tried to prevent multiple
scrubbers by
starting scrub processing only when noone was waiting for the node's
heap lock. Apparently this was not sufficient: per 20800450 a
customer still
observed extremely long (minutes) periods when the system is essentially
unusable due to the heap being unavalable.
My theory is that there is still a window where the lock is not held
(first half of __scrub_free_pages()) which may allow at least one
other CPU
from the same node to start scrubbing. I haven't been able to verify this
since I can't reproduce the bug (20800450) but the patch below, which
explicitly allows only one CPU per node to perform scrubbing, appears to
make the problem go away.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
This patch is originally for bug24376653.
Conflicts:
xen/common/page_alloc.c
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 24376707]
[4.3.0-55.el6.180]
- mm/scrub: clear is_scrubbing flag outside ASSERT()
Otherwise we never clear the flag on NDEBUG builds that turn ASSERT into
a nop.
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>
This is backport from 3.4 tree from bug21819046
commit: 886760e191c696464ef3590391d77437244d55a2
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 24376707]
[4.3.0-55.el6.179]
- vmx: restore debug registers when injecting #DB traps
Commit a929bee0e652 ("x86/vmx: Fix injection of #DB traps following
XSA-156") prevents an infinite loop in certain #DB traps. However, it
changed the behavior to not call hvm_hw_inject_trap() for #DB and #AC
traps which which means that the debug registers are not restored
correctly and nullified commit b56ae5b48c38 ("VMX: fix/adjust trap
injection").
To fix this, restore the original code path through hvm_inject_trap(),
but ensure that the struct hvm_trap is populated with all the required
data.
Signed-off-by: Ross Lagerwall <ross.lagerwall at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Kevin Tian <kevin.tian at intel.com>
Conflicts:
xen/arch/x86/hvm/vmx/vmx.c
Upstream commit ba22f1f4732acb4d5aebd779122e91753a0e374d
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug
24792686] {CVE-2015-5307}
[4.3.0-55.el6.178]
- x86/vmx: Fix injection of #DB traps following XSA-156
Most #DB exceptions are traps rather than faults, meaning that the
instruction
pointer in the exception frame points after the instruction rather
than at it.
However, VMX intercepts all have fault semantics, even when
intercepting a
trap. Re-injecting an intercepted trap as a fault causes an infinite
loop in
the guest, by re-executing the same trapping instruction repeatedly.
This
breaks debugging inside the guest.
Introduce a helper which copies VM_EXIT_INTR_INTO to
VM_ENTRY_INTR_INFO, and
use it to mirror the intercepted interrupt back to the guest.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Kevin Tian <kevin.tian at intel.com>
master commit: 0747bc8b4d85f3fc0ee1e58418418fa0229e8ff8
master date: 2016-01-05 11:28:56 +0000
Conflicts:
xen/arch/x86/hvm/vmx/vmx.c
Upstream commit a929bee0e65296ee565251316dc53f1c6b79084a
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug
24792686] {CVE-2015-5307}
[4.3.0-55.el6.177]
- move TLB-flush filtering out into populate_physmap during vm creation
This patch implemented parts of TODO left in commit id
a902c12ee45fc9389eb8fe54eeddaf267a555c58 (More efficient TLB-flush
filtering in alloc_heap_pages()). It moved TLB-flush filtering out into
populate_physmap. Because of TLB-flush in alloc_heap_pages, it's very
slow
to create a guest with memory size of more than 100GB on host with 100+
cpus.
This patch introduced a "MEMF_no_tlbflush" bit to memflags to indicate
whether TLB-flush should be done in alloc_heap_pages or its caller
populate_physmap. Once this bit is set in memflags, alloc_heap_pages
will
ignore TLB-flush. To use this bit after vm is created might lead to
security issue, that is, this would make pages accessible to the guest B,
when guest A may still have a cached mapping to them.
Therefore, this patch also introduced a "creation_finished" field to
struct
domain to indicate whether this domain has ever got unpaused by
hypervisor.
MEMF_no_tlbflush can be set only during vm creation phase when
creation_finished is still false before this domain gets unpaused for the
first time.
Signed-off-by: Dongli Zhang <dongli.zhang at oracle.com>
Acked-by: Jan Beulich <jbeulich at suse.com>
Acked-by: George Dunlap <george.dunlap at citrix.com>
Reviewed-by: Dario Faggioli <dario.faggioli at citrix.com>
This is backport of upstream commit
bbb17f6f1273857b27197b581b87c20264059a8f
Conflict:
xen/common/domain.c
xen/common/memory.c
xen/include/xen/sched.h
The following changes are made to avoid conflicts:
1. bool is changed to bool_t
2. true/false is changed to 1/0
Signed-off-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com> [bug 24738894]
[4.3.0-55.el6.176]
- replace tlbflush check and operation with inline functions
This patch cleaned up the code by replacing complicated tlbflush
check and
operation with inline functions. We should use those inline functions to
avoid the complicated tlbflush check and tlbflush operations when
implementing TODOs left in commit
a902c12ee45fc9389eb8fe54eeddaf267a555c58
(More efficient TLB-flush filtering in alloc_heap_pages()).
"#include <asm/flushtlb.h>" is removed from
xen/arch/x86/acpi/suspend.c to
avoid the compiling error after we include "<asm/flushtlb.h>" to
xen/include/xen/mm.h.
Signed-off-by: Dongli Zhang <dongli.zhang at oracle.com>
Acked-by: Jan Beulich <jbeulich at suse.com>
Acked-by: George Dunlap <george.dunlap at citrix.com>
Reviewed-by: Dario Faggioli <dario.faggioli at citrix.com>
This is backport of upstream commit
80943aa40e30bcba24f52eff156c29d9d57a2e53
Conflict:
xen/common/page_alloc.c
xen/include/xen/mm.h
The following changes are made to avoid conflicts:
1. bool is changed to bool_t
2. true/false is changed to 1/0
Signed-off-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com> [bug 24738894]
[4.3.0-55.el6.175]
- x86/hvm: don't intercept #UD exceptions in general
The upstream commit is 7d7918e but backporting that would
also require backporting the whole CPUID patchset (~70 patches)
along with some MMIO/PCI configuration interception patches.
But we do not need all of that as:
- We do not support cross-vendor migration (AMD -> Intel or
vice-versa). And that was the only reason the #UD interception
was added.
- Upstream mentions that intercepting #UD:
"opens up the instruction emulator to arbitrary
instruction from an HVM guest, don't use this in production system."
So instead of backporting:
0f1cb96e: x86 hvm: Allow cross-vendor migration
4f7da683: x86/HVM: unify and fix #UD intercept
a6288d5b: xen: make available hvm_fep to non-debug build as well
or fixes to the instruction emulator, like
dee231b x86emul: improve LOCK handling
(which also depends on a whole lot of fixes), we just
disable #UD interception in general.
OraBug: 24385487
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Backport from 3bbc1e4f4cd8ad473365f4d4abca4f542020bad5 OVS 3.4.2
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 24616030]
[4.3.0-55.el6.171]
- xend/netif: Add handle to xenstore to avoid inconsistent vif state
If guest assigned multiple vnics, detach one or some then re-attach it,
vnics state maybe not correct because different handle on xenstore.
This patch add 'handle' of vnics to xenstore to avoid it.
Signed-off-by: Joe Jin <joe.jin at oracle.com>
Reviewed-by: Zhiang Wang <zhigang.x.wang at oracle.com>
Reviewed-by: Adnan Misherfi <adnan.misherfi at oracle.com> [bug 24372976]
[4.3.0-55.el6.170]
- xend/bootloader: Fix unclosed quotation string lead duplicate xend process
When pass unclosed quotation string to bootloader_args it lead child
corrupted and have no chance to exit, then system became unusable
because of 2 xend was running, xend.log have below:
[2016-07-24 21:46:10 1494] ERROR (XendDomainInfo:500) VM start failed
Traceback (most recent call last):
File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py",
line 486, in start
XendTask.log_progress(31, 60, self._initDomain)
File "/usr/lib64/python2.6/site-packages/xen/xend/XendTask.py", line
209, in log_progress
retval = func(*args, **kwds)
File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py",
line 2880, in _initDomain
self._configureBootloader()
File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py",
line 3346, in _configureBootloader
bootloader_args, kernel, ramdisk, args)
File "/usr/lib64/python2.6/site-packages/xen/xend/XendBootloader.py",
line 114, in bootloader
args.extend(shlex.split(blargs))
File "/usr/lib64/python2.6/shlex.py", line 279, in split
return list(lex)
File "/usr/lib64/python2.6/shlex.py", line 269, in next
token = self.get_token()
File "/usr/lib64/python2.6/shlex.py", line 96, in get_token
raw = self.read_token()
File "/usr/lib64/python2.6/shlex.py", line 172, in read_token
raise ValueError, "No closing quotation"
ValueError: No closing quotation
This patch moved construct bootloader args before fork, if any exception
will raise error.
Signed-off-by: Joe Jin <joe.jin at oracle.com>
Reviewed-by: Zhiang Wang <zhigang.x.wang at oracle.com>
Reviewed-by: Adnan Misherfi <adnan.misherfi at oracle.com> [bug 23625563]
[4.3.0-55.el6.169]
- x86/HVM: correct CPUID leaf 80000008 handling - 6c733e54
xsa173_01_0001-x86-HVM-correct-CPUID-leaf-80000008-handling.patch was
based
on upstream commit:
ef437690af8b75e6758dce77af75a22b63982883
x86/HVM: correct CPUID leaf 80000008 handling
It should have been based on upstream commit:
6c733e549889a9b8c4e03140348b8e00241d4ce9
x86/HVM: correct CPUID leaf 80000008 handling
The changes in this patch are the differences between those two patches.
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 24356309]
[4.3.0-55.el6.168]
- x86: fix unintended fallthrough case from XSA-154
... and annotate the other deliberate one: Coverity objects otherwise.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
One of the two instances was actually a bug.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
master commit: 8dd6d1c099865ee5f5916616a0ca79cd943c46f9
master date: 2016-02-18 15:10:07 +0100
Upstream commit ccc7adf9cff5d5f93720afcc1d0f7227d50feab2
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug
22697471] {CVE-2016-2270}
[4.3.0-55.el6.152]
- x86/HVM: correct CPUID leaf 80000008 handling
CPUID[80000008].EAX[23:16] have been given the meaning of the guest
physical address restriction (in case it needs to be smaller than the
host's), hence we need to mirror that into vCPUID[80000008].EAX[7:0].
Enforce a lower limit at the same time, as well as a fixed value for
the virtual address bits, and zero for the guest physical address ones.
In order for the vMTRR code to see these overrides we need to make it
call hvm_cpuid() instead of domain_cpuid(), which in turn requires
special casing (and relaxing) the controlling domain.
This additionally should hide an ordering problem in the tools: Both
xend and xl appear to be restoring a guest from its image before
setting up the CPUID policy in the hypervisor, resulting in
domain_cpuid() returning all zeros and hence the check in
mtrr_var_range_msr_set() failing if the guest previously had more than
the minimum 36 physical address bits.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Tim Deegan <tim at xen.org>
Conflicts:
xen/arch/x86/hvm/mtrr.c
Upstream commit ef437690af8b75e6758dce77af75a22b63982883
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug
23530692] {CVE-2016-3960}
[4.3.0-55.el6.143]
- vga: update vga register setup on vbe changes
Call the new vbe_update_vgaregs() function on vbe configuration
changes, to make sure vga registers are up-to-date.
Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
Signed-off-by: Stefano Stabellini <sstabellini at kernel.org>
Upstream commit 98be1fb6ea31c130264025de8ec87ad2c7532f21
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug
23263093] {CVE-2016-3712}
[4.3.0-55.el6.142]
- vga: factor out vga register setup
When enabling vbe mode qemu will setup a bunch of vga registers to make
sure the vga emulation operates in correct mode for a linear
framebuffer. Move that code to a separate function so we can call it
from other places too.
Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
Signed-off-by: Stefano Stabellini <sstabellini at kernel.org>
Upstream commit 2700250c6b28248b70b15fd6e0b4c9db8b2ddfb7
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug
23263093] {CVE-2016-3712}
[4.3.0-55.el6.141]
- vga: add vbe_enabled() helper
Makes code a bit easier to read.
Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
Signed-off-by: Stefano Stabellini <sstabellini at kernel.org>
Upstream commit e7d7c09689c725be4f0b489b4ba3b741c5d9ab31
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug
23263093] {CVE-2016-3712}
[4.3.0-55.el6.139]
- vbe: make bochs dispi interface return the correct memory size with qxl
VgaState->vram_size is the size of the pci bar. In case of qxl not the
whole pci bar can be used as vga framebuffer. Add a new variable
vbe_size to handle that case. By default (if unset) it equals
vram_size, but qxl can set vbe_size to something else.
This makes sure VBE_DISPI_INDEX_VIDEO_MEMORY_64K returns correct results
and sanity checks are done with the correct size too.
Cc: qemu-stable at nongnu.org
Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
Reviewed-by: Laszlo Ersek <lersek at redhat.com>
Conflicts:
hw/qxl.c
hw/vga.c
hw/vga_init.c
Upstream commit 54a85d462447c1cb8a1638578a7fd086350b4d2d
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug
23263093] {CVE-2016-3712}
[4.3.0-55.el6.136]
- vga: update vga register setup on vbe changes
Call the new vbe_update_vgaregs() function on vbe configuration
changes, to make sure vga registers are up-to-date.
Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
[Backport to qemu-xen-tradition]
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Upstream commit 5e840e6292825fcae90f6750a8f57bc989e28c5f
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug
23263093] {CVE-2016-3712}
[4.3.0-55.el6.135]
- vga: factor out vga register setup
When enabling vbe mode qemu will setup a bunch of vga registers to make
sure the vga emulation operates in correct mode for a linear
framebuffer. Move that code to a separate function so we can call it
from other places too.
Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
[Backport to qemu-xen-tradition]
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Upstream commit df228023ce39e8b72bd5a198b8703319b8b9ca23
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug
23263093] {CVE-2016-3712}
[4.3.0-55.el6.134]
- vga: add vbe_enabled() helper
Makes code a bit easier to read.
Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
[Backport to qemu-xen-tradition]
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Upstream commit 34db09fb9967441408a1ff0579d553222cf17441
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug
23263093] {CVE-2016-3712}
[4.3.0-55.el6.131]
- Backport BUG 22875089 to ovm 3.3
Current block script doesn't handle gaps in loop devices well.
Sorting the losetup -a result with 'sort -g' will fix this issue.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Joe Jin <joe.jin at oracle.com> [bug 23269321]
[4.3.0-55.el6.127]
- x86/irq: limit the maximum number of domain PIRQs
c/s 7e73a6e "have architectures specify the number of PIRQs a
hardware domain
gets" increased the default number of pirqs for dom0, as 256 was
found to be
too low in some cases.
However, it didn't account for the upper bound presented by the
domains EOI
bitmap, registered with the PHYSDEVOP_pirq_eoi_gmfn_v* hypercall.
On a server with 240 cpus, Xen was observed to be attempting to clear
the EOI
bit for dom0's pirq 0xb40f, which hit a pagefault.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
(cherry picked from commit 75d28c917094b0e264874e92e8980b00a372b99f)
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Backported-by: Joe Jin <joe.jin at oracle.com> [bug 22661468] [bug 22668626]
[4.3.0-55.el6.126]
- have architectures specify the number of PIRQs a hardware domain gets
The current value of nr_static_irqs + 256 is often too small for larger
systems. Make it dependent on CPU count and number of IO-APIC pins on
x86, and (until it obtains PCI support) simply NR_IRQS on ARM.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: David Vrabel <david.vrabel at citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Release-Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk at oracle.com>
(cherry picked from commit 7e73a6e7f12ae080222c5d339799905de3443a6e)
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
22668626] [bug 22661468]
More information about the Oraclevm-errata
mailing list