[Oraclevm-errata] OVMSA-2015-0004 Important: Oracle VM 3.3 xen security update

[Errata Announcements for Oracle VM]

Oracle VM Security Advisory OVMSA-2015-0004

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.0.16.x86_64.rpm
xen-tools-4.3.0-55.el6.0.16.x86_64.rpm


SRPMS:
http://oss.oracle.com/oraclevm/server/3.3/SRPMS-updates/xen-4.3.0-55.el6.0.16.src.rpm



Description of changes:

[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 <keir at xen.org>
   Reviewed-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Tested-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   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 <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [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 <jbeulich at suse.com>
   Reviewed-by: Tim Deegan <tim at xen.org>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [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 <jbeulich at suse.com>
   Reviewed-by: Tim Deegan <tim at xen.org>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [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
   <namit at cs.technion.ac.il>.
   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 <jbeulich at suse.com>
   Reviewed-by: Tim Deegan <tim at xen.org>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [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 <jbeulich at suse.com>
   Reviewed-by: Ian Campbell <ian.campbell at citrix.com>
   Acked-by: Keir Fraser <keir at xen.org>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [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 <jbeulich at suse.com>
   Reviewed-by: Tim Deegan <tim at xen.org>
   Confilcts:
   xen/arch/x86/mm/paging.c
   xen/common/domain.c
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [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 <zhenzhong.duan at oracle.com> [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 <jbeulich at suse.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   (cherry picked from commit 7f8d8abcf6dfb85fae591a547b24f9b27d92272c)
   Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   Committed-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [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 <linux at eikelenboom.it>
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   (cherry picked from commit 119d8a42d3bfe6ebc1785720e1a7260e5c698632)
   Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   Committed-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [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 <jbeulich at suse.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   (cherry picked from commit d06886694328a31369addc1f614cf326728d65a6)
   Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   Committed-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [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 <xiantao.zhang at intel.com>
   Signed-off-by: Xudong Hao <xudong.hao at intel.com>
   Tested-by: Michel Riviere <michel.riviere at oracle.com>
   Signed-off-by: Zhenzhong Duan<zhenzhong.duan at oracle.com>
   Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   Committed-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 20141070]