OVMSA-2015-0004

OVMSA-2015-0004 - xen security update

Type:SECURITY
Severity:IMPORTANT
Release Date:2015-01-21

Description


[4.3.0-55.el6.0.16]
- switch to write-biased r/w locks
This is to improve fairness: A permanent flow of read acquires can
otherwise lock out eventual writers indefinitely.
This is XSA-114 / CVE-2014-9065.
Signed-off-by: Keir Fraser
Reviewed-by: Jan Beulich
Reviewed-by: Andrew Cooper
Tested-by: Andrew Cooper
Conflicts:
xen/include/asm-arm/spinlock.h
OVM does not support the ARM architecture so asm-arm/spinlock.h is a stub
Signed-off-by: Chuck Anderson
Reviewed-by: John Haxby [bug 20330505] {CVE-2014-9065,CVE-2014-9066}

[4.3.0-55.el6.0.15]
- x86/HVM: confine internally handled MMIO to solitary regions
While it is generally wrong to cross region boundaries when dealing
with MMIO accesses of repeated string instructions (currently only
MOVS) as that would do things a guest doesn't expect (leaving aside
that none of these regions would normally be accessed with repeated
string instructions in the first place), this is even more of a problem
for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
made dereference NULL 'entry' pointers this way) as well as undersized
(1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
space beyond the one memory page set up for holding LAPIC register
values).
Since those functions validly assume to be called only with addresses
their respective checking functions indicated to be okay, it is generic
code that needs to be fixed to clip the repetition count.
To be on the safe side (and consistent), also do the same for buffered
I/O intercepts, even if their only client (stdvga) doesn't put the
hypervisor at risk (i.e. 'only' guest misbehavior would result).
This is CVE-2014-8867 / XSA-112.
Signed-off-by: Jan Beulich
Reviewed-by: Tim Deegan
Signed-off-by: Chuck Anderson
Reviewed-by: John Haxby [bug 20330364] {CVE-2014-8867}

[4.3.0-55.el6.0.14]
- x86: limit checks in hypercall_xlat_continuation() to actual arguments
HVM/PVH guests can otherwise trigger the final BUG_ON() in that
function by entering 64-bit mode, setting the high halves of affected
registers to non-zero values, leaving 64-bit mode, and issuing a
hypercall that might get preempted and hence become subject to
continuation argument translation (HYPERVISOR_memory_op being the only
one possible for HVM, PVH also having the option of using
HYPERVISOR_mmuext_op). This issue got introduced when HVM code was
switched to use compat_memory_op() - neither that nor
hypercall_xlat_continuation() were originally intended to be used by
other than PV guests (which can't enter 64-bit mode and hence have no
way to alter the high halves of 64-bit registers).
This is XSA-111.
Signed-off-by: Jan Beulich
Reviewed-by: Tim Deegan
Signed-off-by: Chuck Anderson
Reviewed-by: John Haxby [bug 20330251] {CVE-2014-8866}

[4.3.0-55.el6.0.13]
- x86emul: enforce privilege level restrictions when loading CS
Privilege level checks were basically missing for the CS case, the
only check that was done (RPL == DPL for nonconforming segments)
was solely covering a single special case (return to non-conforming
segment).
Additionally in long mode the L bit set requires the D bit to be clear,
as was recently pointed out for KVM by Nadav Amit
.
Finally we also need to force the loaded selector's RPL to CPL (at
least as long as lret/retf emulation doesn't support privilege level
changes).
This is XSA-110.
Signed-off-by: Jan Beulich
Reviewed-by: Tim Deegan
Signed-off-by: Chuck Anderson
Reviewed-by: John Haxby [bug 20330267] {CVE-2014-8595}

[4.3.0-55.el6.0.12]
- page-alloc: scrub pages used by hypervisor upon freeing
... unless they're part of a fully separate pool (and hence can't ever
be used for guest allocations).
This is XSA-100.
Signed-off-by: Jan Beulich
Reviewed-by: Ian Campbell
Acked-by: Keir Fraser
Signed-off-by: Chuck Anderson
Reviewed-by: John Haxby [bug 20328715] {CVE-2014-4021}

[4.3.0-55.el6.0.11]
- x86/paging: make log-dirty operations preemptible
Both the freeing and the inspection of the bitmap get done in (nested)
loops which - besides having a rather high iteration count in general,
albeit that would be covered by XSA-77 - have the number of non-trivial
iterations they need to perform (indirectly) controllable by both the
guest they are for and any domain controlling the guest (including the
one running qemu for it).
This is XSA-97.
Signed-off-by: Jan Beulich
Reviewed-by: Tim Deegan
Confilcts:
xen/arch/x86/mm/paging.c
xen/common/domain.c
Signed-off-by: Chuck Anderson
Reviewed-by: John Haxby [bug 20328433] {CVE-2014-5146,CVE-2014-5149}

[4.3.0-55.el6.0.10]
- Revert from r7887 to r7680 as there is no need to backport to ovm3.3.1
Signed-off-by:Zhenzhong Duan [bug 20141070]

[4.3.0-55.el6.0.9]
- hvmloader: don't use AML operations on 64-bit fields
WinXP and Win2K3, while having no problem with the QWordMemory resource
(there was another one there before), don't like operations on 64-bit
fields. Split the fields d0688669 ('hvmloader: also cover PCI MMIO
ranges above 4G with UC MTRR ranges') added to 32-bit ones, handling
carry over explicitly.
Sadly the constructs needed to create the sub-fields - nominally
CreateDWordField(PRT0, _SB.PCI0._CRS._Y02._MIN, MINL)
CreateDWordField(PRT0, Add(_SB.PCI0._CRS._Y02._MIN, 4), MINH)
- can't be used: The former gets warned upon by newer iasl, i.e. would
need to be replaced by the latter just with the addend changed to 0,
and the latter doesn't translate properly with recent iasl). Hence,
short of having an ASL/iasl expert at hand, we need to work around the
shortcomings of various iasl versions. See the code comment.
Signed-off-by: Jan Beulich
Acked-by: Ian Campbell
(cherry picked from commit 7f8d8abcf6dfb85fae591a547b24f9b27d92272c)
Signed-off-by: Konrad Rzeszutek Wilk
Committed-by: Zhenzhong Duan [bug 20141070]

[4.3.0-55.el6.0.8]
- hvmloader: fix build with certain iasl versions
While most of them support what we have now, Wheezy's dislikes the
empty range. Put a fake one in place - it's getting overwritten upon
evaluation of _CRS anyway.
The range could be grown (downwards) if necessary; the way it is now
it is
- the highest possible one below the 36-bit boundary (with 36 bits
being the lowest common denominator for all supported systems),
- the smallest possible one that said iasl accepts.
Reported-by: Sander Eikelenboom
Signed-off-by: Jan Beulich
Acked-by: Ian Campbell
(cherry picked from commit 119d8a42d3bfe6ebc1785720e1a7260e5c698632)
Signed-off-by: Konrad Rzeszutek Wilk
Committed-by: Zhenzhong Duan [bug 20141070]

[4.3.0-55.el6.0.7]
- hvmloader: also cover PCI MMIO ranges above 4G with UC
MTRR ranges
When adding support for BAR assignments to addresses above 4G, the MTRR
side of things was left out.
Additionally the MMIO ranges in the DSDT's _SB.PCI0._CRS were having
memory types not matching the ones put into MTRRs: The legacy VGA range
is supposed to be WC, and the other ones should be UC.
Signed-off-by: Jan Beulich
Acked-by: Ian Campbell
(cherry picked from commit d06886694328a31369addc1f614cf326728d65a6)
Signed-off-by: Konrad Rzeszutek Wilk
Committed-by: Zhenzhong Duan [bug 20141070]

[4.3.0-55.el6.0.6]
- Add 64-bit support to QEMU.
Currently it is assumed PCI device BAR access < 4G memory. If there is such a
device whose BAR size is larger than 4G, it must access > 4G memory address.
This patch enable the 64bits big BAR support on qemu-xen.
Signed-off-by: Xiantao Zhang
Signed-off-by: Xudong Hao
Tested-by: Michel Riviere
Signed-off-by: Zhenzhong Duan
Signed-off-by: Konrad Rzeszutek Wilk
Committed-by: Zhenzhong Duan [bug 20141070]


Related CVEs


CVE-2014-4021
CVE-2014-5146
CVE-2014-5149
CVE-2014-8595
CVE-2014-8866
CVE-2014-8867
CVE-2014-9065
CVE-2014-9066

Updated Packages


Release/ArchitectureFilenameMD5sumSuperseded By Advisory
Oracle VM 3.3 (x86_64) xen-4.3.0-55.el6.0.16.src.rpm48bca2b672cc28b0375b78b16b8bab2bOVMSA-2021-0014
xen-4.3.0-55.el6.0.16.x86_64.rpmfe8287bfd57bfe6cfc97fa6de30ae7acOVMSA-2021-0014
xen-tools-4.3.0-55.el6.0.16.x86_64.rpm7791dedc8c986693f7046ee0eea6f8ccOVMSA-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