[Oraclevm-errata] OVMSA-2017-0162 Important: Oracle VM 3.3 xen security update

[Errata Announcements for Oracle VM]

Oracle VM Security Advisory OVMSA-2017-0162

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


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



Description of changes:

[4.3.0-55.el6.186.60]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
   Subject: x86/cpu: fix IST handling during PCPU bringup
   Clear IST references in newly allocated IDTs.  Nothing good will come of
   having them set before the TSS is suitably constructed (although the 
chances
   of the CPU surviving such an IST interrupt/exception is extremely slim).
   Uniformly set the IST references after the TSS is in place.  This 
fixes an
   issue on AMD hardware, where onlining a PCPU while PCPU0 is in HVM 
context
   will cause IST_NONE to be copied into the new IDT, making that PCPU 
vulnerable
   to privilege escalation from PV guests until it subsequently 
schedules an HVM
   guest.
   This is XSA-244.
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Reviewed-by: Jan Beulich <jbeulich at suse.com>
   Move IST setting in subarch_percpu_traps_init() as no 
load_system_tables() here
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 
26896604]  {CVE-2017-15594}

[4.3.0-55.el6.186.59]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
   Subject: x86/shadow: Don't create self-linear shadow mappings for 
4-level translated guests
   When initially creating a monitor table for 4-level translated 
guests, don't
   install a shadow-linear mapping.  This mapping is actually 
self-linear, and
   trips up the writeable heuristic logic into following Xen's mappings, 
not the
   guests' shadows it was expecting to follow.
   A consequence of this is that sh_guess_wrmap() needs to cope with 
there being
   no shadow-linear mapping present, which in practice occurs once each 
time a
   vcpu switches to 4-level paging from a different paging mode.
   An appropriate shadow-linear slot will be inserted into the monitor table
   either while constructing lower level monitor tables, or by 
sh_update_cr3().
   While fixing this, clarify the safety of the other mappings.  Despite
   appearing unsafe, it is correct to create a guest-linear mapping for
   translated domains; this is self-linear and doesn't point into the 
translated
   domain.  Drop a dead clause for translate != external guests.
   This is part of XSA-243.
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Tim Deegan <tim at xen.org>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 
26896489]  {CVE-2017-15592}

[4.3.0-55.el6.186.58]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
   Subject: x86: Disable the use of auto-translated PV guests
   This is a minimal backport of c/s 92942fd3d469 "x86/mm: drop
   guest_{map,get_eff}_l1e() hooks" from Xen 4.7, which stated:
   Disallow the unmaintained and presumed broken translated-but-not-external
   paging mode combination ...
   It turns out that this mode is insecure to run with, as opposed to 
just simply
   broken.
   This is part of XSA-243.
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 26896489]

[4.3.0-55.el6.186.57]
- From: Jan Beulich <jbeulich at suse.com>
   Subject: x86: don't allow page_unlock() to drop the last type reference
   Only _put_page_type() does the necessary cleanup, and hence not all
   domain pages can be released during guest cleanup (leaving around
   zombie domains) if we get this wrong.
   This is XSA-242.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 
26896488]  {CVE-2017-15593}

[4.3.0-55.el6.186.56]
- From: Jan Beulich <jbeulich at suse.com>
   Subject: x86: don't store possibly stale TLB flush time stamp
   While the timing window is extremely narrow, it is theoretically
   possible for an update to the TLB flush clock and a subsequent flush
   IPI to happen between the read and write parts of the update of the
   per-page stamp. Exclude this possibility by disabling interrupts
   across the update, preventing the IPI to be serviced in the middle.
   This is XSA-241.
   Suggested-by: George Dunlap <george.dunlap at citrix.com>
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: George Dunlap <george.dunlap at citrix.com>
   Conflict:
   xen/arch/x86/mm.c
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 
26896482]  {CVE-2017-15588}

[4.3.0-55.el6.186.55]
- x86/mm: Disable PV linear pagetables by default
   Allowing pagetables to point to other pagetables of the same level
   (often called 'linear pagetables') has been included in Xen since its
   inception.  But it is not used by the most common PV guests (Linux,
   NetBSD, minios), and has been the source of a number of subtle
   reference-counting bugs.
   Add a command-line option to control whether PV linear pagetables are
   allowed (disabled by default).
   Signed-off-by: George Dunlap <george.dunlap at citrix.com>
   Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Conflict:
   docs/misc/xen-command-line.markdown
   Changes since v2:
   - s/_/-/; in command-line option
   - Added __read_mostly
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 
26896443]  {CVE-2017-15595}

[4.3.0-55.el6.186.54]
- From: Jan Beulich <jbeulich at suse.com>
   Subject: x86/HVM: prefill partially used variable on emulation paths
   Certain handlers ignore the access size (vioapic_write() being the
   example this was found with), perhaps leading to subsequent reads
   seeing data that wasn't actually written by the guest. For
   consistency and extra safety also do this on the read path of
   hvm_process_io_intercept(), even if this doesn't directly affect what
   guests get to see, as we've supposedly already dealt with read handlers
   leaving data completely unitialized.
   This is XSA-239.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Conflict:
   xen/arch/x86/hvm/intercept.c
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 
26896434]  {CVE-2017-15589}

[4.3.0-55.el6.186.53]
- From: Jan Beulich <jbeulich at suse.com>
   Subject: x86/FLASK: fix unmap-domain-IRQ XSM hook
   The caller and the FLASK implementation of xsm_unmap_domain_irq()
   disagreed about what the "data" argument points to in the MSI case:
   Change both sides to pass/take a PCI device.
   This is part of XSA-237.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Conflict:
   xen/xsm/flask/hooks.c
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 
26896408]  {CVE-2017-15590}

[4.3.0-55.el6.186.52]
- Subject: x86/IRQ: conditionally preserve irq <-> pirq mapping on map 
error paths
   Mappings that had been set up before should not be torn down when
   handling unrelated errors.
   This is part of XSA-237.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: George Dunlap <george.dunlap at citrix.com>
   Remove the related chunk in xen/arch/x86/irq.c and 
xen/arch/x86/physdev.c as there is no MAP_PIRQ_TYPE_MULTI_MSI
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 26896404]

[4.3.0-55.el6.186.51]
- From: Jan Beulich <jbeulich at suse.com>
   Subject: x86/MSI: disallow redundant enabling
   At the moment, Xen attempts to allow redundant enabling of MSI by
   having pci_enable_msi() return 0, and point to the existing MSI
   descriptor, when the msi already exists.
   Unfortunately, if subsequent errors are encountered, the cleanup
   paths assume pci_enable_msi() had done full initialization, and
   hence undo everything that was assumed to be done by that
   function without also undoing other setup that would normally
   occur only after that function was called (in map_domain_pirq()
   itself).
   Rather than try to make the redundant enabling case work properly, just
   forbid it entirely by having pci_enable_msi() return -EEXIST when MSI
   is already set up.
   This is part of XSA-237.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Reviewed-by: George Dunlap <george.dunlap at citrix.com>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 26896408]

[4.3.0-55.el6.186.50]
- From: Jan Beulich <jbeulich at suse.com>
   Subject: x86: enforce proper privilege when (un)mapping pIRQ-s
   (Un)mapping of IRQs, just like other RESOURCE__ADD* / RESOURCE__REMOVE*
   actions (in FLASK terms) should be XSM_DM_PRIV rather than XSM_TARGET.
   This in turn requires bypassing the XSM check in physdev_unmap_pirq()
   for the HVM emuirq case just like is being done in physdev_map_pirq().
   The primary goal security wise, however, is to no longer allow HVM
   guests, by specifying their own domain ID instead of DOMID_SELF, to
   enter code paths intended for PV guest and the control domains of HVM
   guests only.
   This is part of XSA-237.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: George Dunlap <george.dunlap at citrix.com>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 26896404]

[4.3.0-55.el6.186.49]
- From: Jan Beulich <jbeulich at suse.com>
   Subject: x86: don't allow MSI pIRQ mapping on unowned device
   MSI setup should be permitted only for existing devices owned by the
   respective guest (the operation may still be carried out by the domain
   controlling that guest).
   This is part of XSA-237.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 26896404]