[Oraclevm-errata] OVMSA-2015-0028 Important: Oracle VM 3.2 xen security update
Errata Announcements for Oracle VM
oraclevm-errata at oss.oracle.com
Fri Mar 6 04:22:43 PST 2015
Oracle VM Security Advisory OVMSA-2015-0028
The following updated rpms for Oracle VM 3.2 have been uploaded to the
Unbreakable Linux Network:
x86_64:
xen-4.1.3-25.el5.127.29.x86_64.rpm
xen-devel-4.1.3-25.el5.127.29.x86_64.rpm
xen-tools-4.1.3-25.el5.127.29.x86_64.rpm
SRPMS:
http://oss.oracle.com/oraclevm/server/3.2/SRPMS-updates/xen-4.1.3-25.el5.127.29.src.rpm
Description of changes:
[4.1.3-25.el5.127.29]
- pre-fill structures for certain HYPERVISOR_xen_version sub-ops
... avoiding to pass hypervisor stack contents back to the caller
through space unused by the respective strings.
This is XSA-122.
Acked-by: Jan Beulich <jbeulich at suse.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 20588646]
{CVE-2015-2045}
[4.1.3-25.el5.127.28]
- x86/HVM: return all ones on wrong-sized reads of system device I/O ports
So far the value presented to the guest remained uninitialized.
This is XSA-121.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 20588307]
{CVE-2015-2044}
[4.1.3-25.el5.127.27]
- hvmloader: Define uint64_t
The 'hvmloader: also cover PCI MMIO ranges above 4G with UC MTRR ranges'
adds an uint64_t which is not defined for the ROMBIOS.
Upstream wise I am not entirely sure how the rombios build
pulls in uint64_t as there does not seem to be any decleration
of this type - but it still compiles properly.
This fixes the issue of the build failing because of
uint64_t type.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Orabug: 16796339
Tested-by: Michel Riviere <michel.riviere at oracle.com>
Signed-off-by: Zhenzhong Duan<zhenzhong.duan at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16796339]
[4.1.3-25.el5.127.26]
- fix build with certain iasl versions
Orabug: 16796339
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>
Tested-by: Michel Riviere <michel.riviere at oracle.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16796339]
[4.1.3-25.el5.127.25]
- don't use AML operations on 64-bit fields
Orabug: 16796339
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>
Tested-by: Michel Riviere <michel.riviere at oracle.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16796339]
[4.1.3-25.el5.127.24]
- 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>
Orabug: 16796339
Tested-by: Michel Riviere <michel.riviere at oracle.com>
Signed-off-by: Zhenzhong Duan<zhenzhong.duan at oracle.com>
Conflicts:
tools/firmware/hvmloader/acpi/build.c
[Different location]
tools/firmware/hvmloader/acpi/dsdt.asl
[Different BIOS_INFO_PHYSICAL_ADDRESS == 0xEA000, upstream has
0xFC000000]
tools/firmware/hvmloader/config.h
[Different location]
tools/firmware/hvmloader/pci.c
[File does not exist in Xen 4.1, the code is in hvmloader.c in Xen 4.1]
tools/firmware/hvmloader/config.h
[When backporting we also had to modify the ACPI_PHYSICAL_ADDRESS
as the OperationRegion(BIOS, SystemMemory, 0xEA000, 40) would now
cover the ACPI_PHYSICAL_ADDRESS. That means the RSDP would be put
right there and:
a) If the OS did an _CRS its values would be garbage as it would
pick up the 'RSV ' signature of RSDP, or
b) If the guest did an PCI passthrough and the device was to be
moved above 4GB, then the signature of RSDP would be corrupted
by location of the PCI address.
c) The bios32 entry point is now moved to EA024 - which means that
during bootup the hvmloader would overwrite the RSDP signature
with the address of the Bochs BIOS.
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16796339]
[4.1.3-25.el5.127.23]
- x86/mm: update max_mapped_pfn on MMIO mappings too.
Orabug: 16796339
max_mapped_pfn should reflect the highest mapping we've ever seen of
any type, or the tests in the lookup functions will be wrong. As it
happens, the highest mapping has always been a RAM one, but this is no
longer the case when we allow 64-bit BARs.
Reported-by: Xudong Hao <xudong.hao at intel.com>
Signed-off-by: Tim Deegan <tim at xen.org>
Committed-by: Tim Deegan <tim at xen.org>
Tested-by: Michel Riviere <michel.riviere at oracle.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16796339]
[4.1.3-25.el5.127.22]
- hvmloader: Add 64 bits big bar support
Orabug: 16796339
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
hvmloader.
Signed-off-by: Xiantao Zhang <xiantao.zhang at intel.com>
Signed-off-by: Xudong Hao <xudong.hao at intel.com>
Committed-by: Keir Fraser <keir at xen.org>
Tested-by: Michel Riviere <michel.riviere at oracle.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16796339]
[4.1.3-25.el5.127.21]
- Orabug: 16796339
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>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16796339]
[4.1.3-25.el5.127.20]
- 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).
Note that the tying of the continuations to the invoking domain (which
previously [wrongly] used the invoking vCPU instead) implies that the
tools requesting such operations have to make sure they don't issue
multiple similar operations in parallel.
Note further that this breaks supervisor-mode kernel assumptions in
hypercall_create_continuation() (where regs->eip gets rewound to the
current hypercall stub beginning), but otoh
hypercall_cancel_continuation() doesn't work in that mode either.
Perhaps time to rip out all the remains of that feature?
This is part of CVE-2014-5146 / XSA-97.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Tim Deegan <tim at xen.org>
Tested-by: Andrew Cooper <andrew.cooper3 at citrix.com>
(cherry picked from commit 070493dfd2788e061b53f074b7ba97507fbcbf65)
Conflicts:
xen/arch/x86/domctl.c
xen/arch/x86/hvm/hvm.c
xen/arch/x86/mm/paging.c
xen/common/domain.c
xen/include/asm-x86/paging.h
[Due to not having: c83e878b9efd3a958846a017bfc3e56018ece3dd
"xen/arch/*: add struct domain parameter to arch_do_domctl",
e93e0d9d "streamline guest copy operations"]
[The locking is quite different in Xen 4.4 and later - with more
fine-grained locking. Backporting all the locking changes would
be quite an task so instead this picks the simpler case and uses
the p2m lock that existed in Xen 4.1 area].
p2m lock being split
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19261811]
[4.1.3-25.el5.127.19]
- fix XENMEM_add_to_physmap preemption handling
Just like for all other hypercalls we shouldn't be modifying the input
structure - all of the fields are, even if not explicitly documented,
just inputs.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Tim Deegan <tim at xen.org>
Acked-by: Keir Fraser <keir at xen.org>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
(cherry picked from commit ade868939fe06520bb946dad740e1f3f1c12ea82)
Conflicts:
xen/common/compat/memory.c
[Xen 4.4 had new hypercalls (claim and remove_physmap) which caused
this conflict]
xen/common/memory.c
[We did not have XENMEM_set_memory_map hypercall) which caused
this conflict]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19261811]
[4.1.3-25.el5.127.18]
- move XENMEM_add_to_physmap handling framework to common code
There's really nothing really architecture specific here; the
architecture specific handling is limited to
xenmem_add_to_physmap_one().
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Tim Deegan <tim at xen.org>
Acked-by: Keir Fraser <keir at xen.org>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
(cherry picked from commit 4be86bb194e25e46b6cbee900601bfee76e8090a)
Conflicts:
xen/arch/arm/mm.c
[We don't have ARM in Xen 4.1]
xen/arch/x86/mm.c
xen/arch/x86/x86_64/compat/mm.c
xen/common/compat/memory.c
xen/common/memory.c
xen/include/xen/mm.h
[And new hypercalls - claim, and remove_physmap, and as well
the cleanups done (copyback and XSM calls made earlier, contribute
to the massive conflict]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19261811]
[4.1.3-25.el5.127.17]
- IOMMU: make page table population preemptible
Since this can take an arbitrary amount of time, the rooting domctl as
well as all involved code must become aware of this requiring a
continuation.
The subject domain's rel_mem_list is being (ab)used for this, in a way
similar to and compatible with broken page offlining.
Further, operations get slightly re-ordered in assign_device(): IOMMU
page tables now get set up _before_ the first device gets assigned, at
once closing a small timing window in which the guest may already see
the device but wouldn't be able to access it.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Tim Deegan <tim at xen.org>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Xiantao Zhang <xiantao.zhang at intel.com>
(cherry picked from commit 3e06b9890c0a691388ace5a6636728998b237b90)
Conflicts:
xen/arch/x86/domain.c
xen/arch/x86/domain.c
xen/arch/x86/mm/p2m-pod.c
xen/drivers/passthrough/iommu.c
xen/include/xen/sched.h
[As we are putting this patch on top of
cedfdd43a9798e535a05690bb6f01394490d26bb
"IOMMU: make page table deallocation preemptible" which upstream
is done the other way around]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19261811]
[4.1.3-25.el5.127.16]
- IOMMU: clear "don't flush" override on error paths
Both xenmem_add_to_physmap() and iommu_populate_page_table() each have
an error path that fails to clear that flag, thus suppressing further
flushes on the respective pCPU.
In iommu_populate_page_table() also slightly re-arrange code to avoid
the false impression of the flag in question being guarded by a
domain's page_alloc_lock.
This is CVE-2013-6400 / XSA-80.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Conflicts:
xen/drivers/passthrough/iommu.c
[As we are putting this patch on top of
cedfdd43a9798e535a05690bb6f01394490d26bb
"IOMMU: make page table deallocation preemptible" which upstream
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19261811]
[4.1.3-25.el5.127.15]
- hvmloader: Fix memory relocation loop part 2
The change to tools/firmware/hvmloader/util.h was left out of
hvmloader-Fix-memory-relocation-loop.patch. Change it here.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com>
Patch comments from hvmloader-Fix-memory-relocation-loop.patch:
Signed-off-by: Keir Fraser <keir at xen.org>
(cherry picked from commit 5a9a98a7a680012d7259848f1957ad32cdde4e14)
Conflicts:
tools/firmware/hvmloader/pci.c
[We did not backport 'b39d3fa hvmloader: setup PCI bus in a common
function again.'
which moves the pci_setup in the 'pci.c' file]. [bug 19261811]
[4.1.3-25.el5.127.14]
- Fix memory relocation loop.
Signed-off-by: Keir Fraser <keir at xen.org>
(cherry picked from commit 5a9a98a7a680012d7259848f1957ad32cdde4e14)
Conflicts:
tools/firmware/hvmloader/pci.c
[We did not backport 'b39d3fa hvmloader: setup PCI bus in a common
function again.'
which moves the pci_setup in the 'pci.c' file].
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19261811]
[4.1.3-25.el5.127.13]
- iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid
unnecessary iotlb flush
Add cpu flag that will be checked by the iommu low level code
to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
Signed-off-by: Jean Guyader <jean.guyader at eu.citrix.com>
Committed-by: Keir Fraser <keir at xen.org>
(cherry picked from commit cf95b2a9fd5aff18408e501c67203c095b1ddc1c)
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19261811]
[4.1.3-25.el5.127.12]
- hvmloader: Change memory relocation loop when overlap with PCI hole
Change the way we relocate the memory page if they overlap with pci
hole. Use new map space (XENMAPSPACE_gmfn_range) to move the loop
into xen.
This code usually get triggered when a device is pass through to a
guest and the PCI hole has to be extended to have enough room to map
the device BARs. The PCI hole will starts lower and it might overlap
with some RAM that has been alocated for the guest. That usually
happen if the guest has more than 4G of RAM. We have to relocate
those pages in high mem otherwise they won't be accessible.
Signed-off-by: Jean Guyader <jean.guyader at eu.citrix.com>
Committed-by: Keir Fraser <keir at xen.org>
(cherry picked from commit e51e2e0e581b91a61835413c3bfa5b46426825f7)
Conflicts:
[We did not backport 'b39d3fa hvmloader: setup PCI bus in a common
function again.'
which moves the pci_setup in the 'pci.c' file].
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19261811]
[4.1.3-25.el5.127.11]
- x86: Fix RCU locking in XENMEM_add_to_physmap.
Signed-off-by: Keir Fraser <keir at xen.org>
(cherry picked from commit 28e312a8b710d2208ee9ce2c25e5dfc11bc1c1b0)
Conflicts:
xen/arch/x86/mm.c
[We did not backport 51032ca058e43fbd37ea1f7c7c003496f6451340
'Modify naming of queries into the p2m' which added a 'put_gfn'
and as such the conflict showed up]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19261811]
[4.1.3-25.el5.127.10]
- mm: New XENMEM space, XENMAPSPACE_gmfn_range
XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
a range of pages. The size of the range is defined in a new field.
This new field .size is located in the 16 bits padding between .domid
and .space in struct xen_add_to_physmap to stay compatible with older
versions.
Signed-off-by: Jean Guyader <jean.guyader at eu.citrix.com>
Committed-by: Keir Fraser <keir at xen.org>
(cherry picked from commit a04811a315e059101fa3b3303e75b97eac7c5c95)
Conflicts:
xen/arch/x86/mm.c
[We did not backport 51032ca058e43fbd37ea1f7c7c003496f6451340
'Modify naming of queries into the p2m' which added a 'put_gfn'
and as such the conflict showed up]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19261811]
[4.1.3-25.el5.127.9]
- add_to_physmap: Move the code for XENMEM_add_to_physmap
Move the code for the XENMEM_add_to_physmap case into it's own
function (xenmem_add_to_physmap).
Signed-off-by: Jean Guyader <jean.guyader at eu.citrix.com>
Committed-by: Keir Fraser <keir at xen.org>
(cherry picked from commit 19c617a85bb3c4d4fa9afc4919273e0f9b71cb85)
Conflicts:
xen/arch/x86/mm.c
[We did not backport 51032ca058e43fbd37ea1f7c7c003496f6451340
'Modify naming of queries into the p2m' which added a 'put_gfn'
and as such the conflict showed up]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19261811]
[4.1.3-25.el5.127.8]
- iommu: Introduce iommu_flush and iommu_flush_all.
Signed-off-by: Jean Guyader <jean.guyader at eu.citrix.com>
Committed-by: Keir Fraser <keir at xen.org>
(cherry picked from commit bf3292ca31ef4eedd6aa070b04321178a60e4b8f)
Conflicts:
xen/drivers/passthrough/iommu.c
[As we are putting this patch on top of
cedfdd43a9798e535a05690bb6f01394490d26bb
"IOMMU: make page table deallocation preemptible" which upstream
is done the other way around]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19261811]
[4.1.3-25.el5.127.7]
- vtd: Refactor iotlb flush code
Factorize the iotlb flush code from map_page and unmap_page into
it's own function.
Signed-off-by: Jean Guyader <jean.guyader at eu.citrix.com>
Committed-by: Keir Fraser <keir at xen.org>
(cherry picked from commit c312ccdeafa0ed2ec710f48f27d575c7bf88eafa)
Conflicts:
xen/drivers/passthrough/vtd/iommu.c
[As we are putting this patch on top of
cedfdd43a9798e535a05690bb6f01394490d26bb
"IOMMU: make page table deallocation preemptible" which upstream
is done the other way around]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Committed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19261811]
More information about the Oraclevm-errata
mailing list