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

Errata Announcements for Oracle VM oraclevm-errata at oss.oracle.com
Tue Jun 2 18:36:23 PDT 2015


Oracle VM Security Advisory OVMSA-2015-0064

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


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



Description of changes:

[4.3.0-55.el6.22.46]
- xen/pt: unknown PCI config space fields should be read-only
   ... by default. Add a per-device "permissive" mode similar to pciback's
   to allow restoring previous behavior (and hence break security again,
   i.e. should be used only for trusted guests).
   This is part of XSA-131.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Reviewed-by: Anthony PERARD <anthony.perard at citrix.com>)
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21164495] 
{CVE-2015-4106}

[4.3.0-55.el6.22.45]
- xen/pt: unknown PCI config space fields should be read-only
   ... by default. Add a per-device "permissive" mode similar to pciback's
   to allow restoring previous behavior (and hence break security again,
   i.e. should be used only for trusted guests).
   This is part of XSA-131.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Reviewed-by: Anthony PERARD <anthony.perard at citrix.com>)
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21164495] 
{CVE-2015-4106}

[4.3.0-55.el6.22.44]
- xen/pt: add a few PCI config space field descriptions
   Since the next patch will turn all not explicitly described fields
   read-only by default, those fields that have guest writable bits need
   to be given explicit descriptors.
   This is a preparatory patch for XSA-131.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21164495] 
{CVE-2015-4106}

[4.3.0-55.el6.22.43]
- xen/pt: add a few PCI config space field descriptions
   Since the next patch will turn all not explicitly described fields
   read-only by default, those fields that have guest writable bits need
   to be given explicit descriptors.
   This is a preparatory patch for XSA-131.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   ---
   Notes:
   - blindly allowing all VPD reads may still be a problem (out of bounds
   addresses aren't allowed, but the spec doesn't say what the effect
   would be) ==> also an issue in pciback?
   - Vendor Specific cap regs aren't in the table (will become r/o by
   default with this change)
   - many PCIe cap regs aren't in the table (will again become r/o)
   - same for PM cap regs at offsets 6 and 7
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21164495] 
{CVE-2015-4106}

[4.3.0-55.el6.22.42]
- xen/pt: mark reserved bits in PCI config space fields
   The adjustments are solely to make the subsequent patches work right
   (and hence make the patch set consistent), namely if permissive mode
   (introduced by the last patch) gets used (as both reserved registers
   and reserved fields must be similarly protected from guest access in
   default mode, but the guest should be allowed access to them in
   permissive mode).
   This is a preparatory patch for XSA-131.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21164495] 
{CVE-2015-4106}

[4.3.0-55.el6.22.41]
- xen/pt: mark reserved bits in PCI config space fields
   The adjustments are solely to make the subsequent patches work right
   (and hence make the patch set consistent), namely if permissive mode
   (introduced by the last patch) gets used (as both reserved registers
   and reserved fields must be similarly protected from guest access in
   default mode, but the guest should be allowed access to them in
   permissive mode).
   This is a preparatory patch for XSA-131.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21164495] 
{CVE-2015-4106}

[4.3.0-55.el6.22.40]
- xen/pt: mark all PCIe capability bits read-only
   xen_pt_emu_reg_pcie[]'s PCI_EXP_DEVCAP needs to cover all bits as read-
   only to avoid unintended write-back (just a precaution, the field ought
   to be read-only in hardware).
   This is a preparatory patch for XSA-131.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21164495] 
{CVE-2015-4106}

[4.3.0-55.el6.22.39]
- xen/pt: mark all PCIe capability bits read-only
   xen_pt_emu_reg_pcie[]'s PCI_EXP_DEVCAP needs to cover all bits as read-
   only to avoid unintended write-back (just a precaution, the field ought
   to be read-only in hardware).
   This is a preparatory patch for XSA-131.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21164495] 
{CVE-2015-4106}

[4.3.0-55.el6.22.38]
- xen/pt: split out calculation of throughable mask in PCI config space 
handling
   This is just to avoid having to adjust that calculation later in
   multiple places.
   Note that including ->ro_mask in get_throughable_mask()'s calculation
   is only an apparent (i.e. benign) behavioral change: For r/o fields it
   doesn't matter > whether they get passed through - either the same flag
   is also set in emu_mask (then there's no change at all) or the field is
   r/o in hardware (and hence a write won't change it anyway).
   This is a preparatory patch for XSA-131.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Reviewed-by: Anthony PERARD <anthony.perard at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21164495] 
{CVE-2015-4106}

[4.3.0-55.el6.22.37]
- xen/pt: split out calculation of throughable mask in PCI config space 
handling
   This is just to avoid having to adjust that calculation later in
   multiple places.
   Note that including ->ro_mask in get_throughable_mask()'s calculation
   is only an apparent (i.e. benign) behavioral change: For r/o fields it
   doesn't matter > whether they get passed through - either the same flag
   is also set in emu_mask (then there's no change at all) or the field is
   r/o in hardware (and hence a write won't change it anyway).
   This is a preparatory patch for XSA-131.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Reviewed-by: Anthony PERARD <anthony.perard at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21164495] 
{CVE-2015-4106}

[4.3.0-55.el6.22.36]
- xen/pt: correctly handle PM status bit
   xen_pt_pmcsr_reg_write() needs an adjustment to deal with the RW1C
   nature of the not passed through bit 15 (PCI_PM_CTRL_PME_STATUS).
   This is a preparatory patch for XSA-131.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21164495] 
{CVE-2015-4106}

[4.3.0-55.el6.22.35]
- xen/pt: correctly handle PM status bit
   xen_pt_pmcsr_reg_write() needs an adjustment to deal with the RW1C
   nature of the not passed through bit 15 (PCI_PM_CTRL_PME_STATUS).
   This is a preparatory patch for XSA-131.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21164495] 
{CVE-2015-4106}

[4.3.0-55.el6.22.34]
- xen/pt: consolidate PM capability emu_mask
   There's no point in xen_pt_pmcsr_reg_{read,write}() each ORing
   PCI_PM_CTRL_STATE_MASK and PCI_PM_CTRL_NO_SOFT_RESET into a local
   emu_mask variable - we can have the same effect by setting the field
   descriptor's emu_mask member suitably right away. Note that
   xen_pt_pmcsr_reg_write() is being retained in order to allow later
   patches to be less intrusive.
   This is a preparatory patch for XSA-131.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21164495] 
{CVE-2015-4106}

[4.3.0-55.el6.22.33]
- xen/pt: consolidate PM capability emu_mask
   There's no point in xen_pt_pmcsr_reg_{read,write}() each ORing
   PCI_PM_CTRL_STATE_MASK and PCI_PM_CTRL_NO_SOFT_RESET into a local
   emu_mask variable - we can have the same effect by setting the field
   descriptor's emu_mask member suitably right away. Note that
   xen_pt_pmcsr_reg_write() is being retained in order to allow later
   patches to be less intrusive.
   This is a preparatory patch for XSA-131.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21164495] 
{CVE-2015-4106}

[4.3.0-55.el6.22.32]
- xen/MSI: don't open-code pass-through of enable bit modifications
   Without this the actual XSA-131 fix would cause the enable bit to not
   get set anymore (due to the write back getting suppressed there based
   on the OR of emu_mask, ro_mask, and res_mask).
   Note that the fiddling with the enable bit shouldn't really be done by
   qemu, but making this work right (via libxc and the hypervisor) will
   require more extensive changes, which can be postponed until after the
   security issue got addressed.
   This is a preparatory patch for XSA-131.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21164495] 
{CVE-2015-4106}

[4.3.0-55.el6.22.31]
- xen/MSI: don't open-code pass-through of enable bit modifications
   Without this the actual XSA-131 fix would cause the enable bit to not
   get set anymore (due to the write back getting suppressed there based
   on the OR of emu_mask, ro_mask, and res_mask).
   Note that the fiddling with the enable bit shouldn't really be done by
   qemu, but making this work right (via libxc and the hypervisor) will
   require more extensive changes, which can be postponed until after the
   security issue got addressed.
   This is a preparatory patch for XSA-131.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21164495] 
{CVE-2015-4106}

[4.3.0-55.el6.22.30]
- xen/MSI-X: disable logging by default
   ... to avoid allowing the guest to cause the control domain's disk to
   fill.
   This is XSA-130.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21159380] 
{CVE-2015-4105}

[4.3.0-55.el6.22.29]
- xen/MSI-X: limit error messages resulting from bad guest behavior
   ... to avoid allowing the guest to cause the control domain's disk to
   fill.
   The first message in pci_msix_write() can simply be deleted, as this
   is indeed bad guest behavior, but such out of bounds writes don't
   really need to be logged.
   The second one is more problematic, as there guest behavior may only
   appear to be wrong: For one, the old logic didn't take the mask-all bit
   into account. And then this shouldn't depend on host device state (i.e.
   the host may have masked the entry without the guest having done so).
   Plus these writes shouldn't be dropped even when an entry is unmasked.
   Instead, if they can't be made take effect right away, they should take
   effect on the next unmasking or enabling operation - the specification
   explicitly describes such caching behavior. Until we can validly drop
   the message (implementing such caching/latching behavior), issue the
   message just once per MSI-X table entry.
   Note that the log message in pci_msix_read() similar to the one being
   removed here is not an issue: "addr" being of unsigned type, and the
   maximum size of the MSI-X table being 32k, entry_nr simply can't be
   negative and hence the conditonal guarding issuing of the message will
   never be true.
   This is XSA-130.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21159380] 
{CVE-2015-4105}

[4.3.0-55.el6.22.28]
- xen: don't allow guest to control MSI mask register
   It's being used by the hypervisor. For now simply mimic a device not
   capable of masking, and fully emulate any accesses a guest may issue
   nevertheless as simple reads/writes without side effects.
   This is XSA-129.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21158644] 
{CVE-2015-4104}

[4.3.0-55.el6.22.27]
- xen: don't allow guest to control MSI mask register
   It's being used by the hypervisor. For now simply mimic a device not
   capable of masking, and fully emulate any accesses a guest may issue
   nevertheless as simple reads/writes without side effects.
   This is XSA-129.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21158644] 
{CVE-2015-4104}

[4.3.0-55.el6.22.26]
- xen: properly gate host writes of modified PCI CFG contents
   The old logic didn't work as intended when an access spanned multiple
   fields (for example a 32-bit access to the location of the MSI Message
   Data field with the high 16 bits not being covered by any known field).
   Remove it and derive which fields not to write to from the accessed
   fields' emulation masks: When they're all ones, there's no point in
   doing any host write.
   This fixes a secondary issue at once: We obviously shouldn't make any
   host write attempt when already the host read failed.
   This is XSA-128.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21157378] 
{CVE-2015-4103}

[4.3.0-55.el6.22.25]
- xen: properly gate host writes of modified PCI CFG contents
   The old logic didn't work as intended when an access spanned multiple
   fields (for example a 32-bit access to the location of the MSI Message
   Data field with the high 16 bits not being covered by any known field).
   Remove it and derive which fields not to write to from the accessed
   fields' emulation masks: When they're all ones, there's no point in
   doing any host write.
   This fixes a secondary issue at once: We obviously shouldn't make any
   host write attempt when already the host read failed.
   This is XSA-128.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21157378] 
{CVE-2015-4103}




More information about the Oraclevm-errata mailing list