[Oraclevm-errata] OVMSA-2015-0068 Important: Oracle VM 3.2 xen security update
Errata Announcements for Oracle VM
oraclevm-errata at oss.oracle.com
Thu Jun 11 10:04:20 PDT 2015
Oracle VM Security Advisory OVMSA-2015-0068
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.52.x86_64.rpm
xen-devel-4.1.3-25.el5.127.52.x86_64.rpm
xen-tools-4.1.3-25.el5.127.52.x86_64.rpm
SRPMS:
http://oss.oracle.com/oraclevm/server/3.2/SRPMS-updates/xen-4.1.3-25.el5.127.52.src.rpm
Description of changes:
[4.1.3-25.el5.127.52]
- x86/traps: loop in the correct direction in compat_iret()
This is XSA-136.
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 21219214]
{CVE-2015-4164}
[4.1.3-25.el5.127.51]
- pcnet: force the buffer access to be in bounds during tx
4096 is the maximum length per TMD and it is also currently the size of
the relay buffer pcnet driver uses for sending the packet data to QEMU
for further processing. With packet spanning multiple TMDs it can
happen that the overall packet size will be bigger than sizeof(buffer),
which results in memory corruption.
Fix this by only allowing to queue maximum sizeof(buffer) bytes.
This is CVE-2015-3209.
Signed-off-by: Petr Matousek <pmatouse at redhat.com>
Reported-by: Matt Tait <matttait at google.com>
Reviewed-by: Peter Maydell <peter.maydell at linaro.org>
Reviewed-by: Stefan Hajnoczi <stefanha at redhat.com>
Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 21218615]
{CVE-2015-3209}
[4.1.3-25.el5.127.50]
- pcnet: fix Negative array index read
From: Gonglei <arei.gonglei at huawei.com>
s->xmit_pos maybe assigned to a negative value (-1),
but in this branch variable s->xmit_pos as an index to
array s->buffer. Let's add a check for s->xmit_pos.
upstream-commit-id: 7b50d00911ddd6d56a766ac5671e47304c20a21b
Signed-off-by: Gonglei <arei.gonglei at huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini at redhat.com>
Reviewed-by: Jason Wang <jasowang at redhat.com>
Reviewed-by: Jason Wang <jasowang at redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com>
Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 21218615]
{CVE-2015-3209}
[4.1.3-25.el5.127.49]
- 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 21164521]
{CVE-2015-????}
[4.1.3-25.el5.127.48]
- 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 21164521]
{CVE-2015-????}
- 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 21164521]
{CVE-2015-????}
[4.1.3-25.el5.127.47]
- 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 21164521]
{CVE-2015-????}
[4.1.3-25.el5.127.46]
- 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 21164521]
{CVE-2015-????}
[4.1.3-25.el5.127.45]
- 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 21164521]
{CVE-2015-????}
[4.1.3-25.el5.127.44]
- 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 21164521]
{CVE-2015-????}
[4.1.3-25.el5.127.43]
- 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 21164521]
{CVE-2015-????}
[4.1.3-25.el5.127.42]
- 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 21159400]
{CVE-2015-????}
[4.1.3-25.el5.127.41]
- 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 21158675]
{CVE-2015-????}
[4.1.3-25.el5.127.40]
- 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>
Conflicts:
tools/ioemu-remote/hw/pass-through.c
Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21157417]
{CVE-2015-????}
[4.1.3-25.el5.127.39]
- fdc: force the fifo access to be in bounds of the allocated buffer
During processing of certain commands such as FD_CMD_READ_ID and
FD_CMD_DRIVE_SPECIFICATION_COMMAND the fifo memory access could
get out of bounds leading to memory corruption with values coming
from the guest.
Fix this by making sure that the index is always bounded by the
allocated memory.
This is CVE-2015-3456.
Signed-off-by: Petr Matousek <pmatouse at redhat.com>
Reviewed-by: John Snow <jsnow at redhat.com>
XSA-133
Based on xen.org's xsa133-qemuu-4.3-4.2.patch
Conflicts:
tools/ioemu-remote/hw/fdc.c
Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 21078935]
{CVE-2015-3456}
[4.1.3-25.el5.127.38]
- x86: vcpu_destroy_pagetables() must not return -EINTR
.. otherwise it has the side effect that: domain_relinquish_resources
will stop and will return to user-space with -EINTR which it is not
equipped to deal with that error code; or vcpu_reset - which will
ignore it and convert the error to -ENOMEM..
The preemption mechanism we have for domain destruction is to return
-EAGAIN (and then user-space calls the hypercall again) and as such
we need
to catch the case of:
domain_relinquish_resources
->vcpu_destroy_pagetables
-> put_page_and_type_preemptible
-> __put_page_type
returns -EINTR
and convert it to the proper type. For:
XEN_DOMCTL_setvcpucontext
-> vcpu_reset
-> vcpu_destroy_pagetables
we need to return -ERESTART otherwise we end up returning -ENOMEM.
There are also other callers of vcpu_destroy_pagetables: arch_vcpu_reset
(vcpu_reset) are:
- hvm_s3_suspend (asserts on any return code),
- vlapic_init_sipi_one (asserts on any return code),
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 20618712]
[4.1.3-25.el5.127.37]
- mm: Make scrubbing a low-priority task
An idle processor will attempt to scrub pages left over by a previously
exited guest. The processor takes global heap_lock in scrub_free_pages(),
manipulates pages on the heap lists and releases the lock before
performing
the actual scrubbing in __scrub_free_pages().
It has been observed that on some systems, even though scrubbing itself
is done with the lock not held, other unrelated heap users are unable
to take the (now free) lock. We theorize that massive scrubbing locks out
the bus (or some other HW resources), preventing lock requests from
reaching
the scrubbing node.
This patch tries to alleviate this problem by having the scrubber monitor
whether there are other waiters for the heap lock and, if such waiters
exist, stop scrubbing.
To achieve this, we make two changes to existing code:
1. Parallelize the heap lock by breaking it to per-node locks
2. Create an atomic per-node counter array. Before a CPU on a particular
node attempts to acquire the (now per-node) lock it increments the
counter.
The scrubbing processor periodically checks this counter and, if it is
non-zero, stops scrubbing.
Few notes:
1. Until now, total_avail_pages and midsize_alloc_zone_pages updates
have been
performed under single heap_lock. Since we no longer have this global
lock,
we introduce pgcount_lock. Note that this is really only to protect
readers
of this variables from reading inconsistent values (such as if
another CPU
is in the middle of updating them). The values themselves are somewhat
"unsynchronized" from actual heap state. We try to be conservative
and decrement
them before pages are taken from the heap and increment them after
they are
placed there.
2. Similarly, page_broken/offlined_list are no longer under heap_lock.
pglist_lock is added to synchronize access to those lists.
3. d->last_alloc_node used to be updated under heap_lock. It was
read, however,
without holding this lock so it seems that lockless updates will not
make the
situation any worse (and since these updates are simple writes, as
opposed to
some sort of RMW, we shouldn't need to convert it to an atomic).
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 20326458]
[4.1.3-25.el5.127.36]
- xen: limit guest control of PCI command register
Otherwise the guest can abuse that control to cause e.g. PCIe
Unsupported Request responses (by disabling memory and/or I/O decoding
and subsequently causing [CPU side] accesses to the respective address
ranges), which (depending on system configuration) may be fatal to the
host.
This is CVE-2015-2756 / XSA-126.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Conflicts:
tools/ioemu-remote/hw/pass-through.c
Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
20739381] {CVE-2015-2756}
[4.1.3-25.el5.127.35]
- Limit XEN_DOMCTL_memory_mapping hypercall to only process up to 64
GFNs (or less)
Said hypercall for large BARs can take quite a while. As such
we can require that the hypercall MUST break up the request
in smaller values.
Another approach is to add preemption to it - whether we do the
preemption using hypercall_create_continuation or returning
EAGAIN to userspace (and have it re-invocate the call) - either
way the issue we cannot easily solve is that in 'map_mmio_regions'
if we encounter an error we MUST call 'unmap_mmio_regions' for the
whole BAR region.
Since the preemption would re-use input fields such as nr_mfns,
first_gfn, first_mfn - we would lose the original values -
and only undo what was done in the current round (i.e. ignoring
anything that was done prior to earlier preemptions).
Unless we re-used the return value as 'EAGAIN|nr_mfns_done<<10' but
that puts a limit (since the return value is a long) on the amount
of nr_mfns that can provided.
This patch sidesteps this problem by:
- Setting an hard limit of nr_mfns having to be 64 or less.
- Toolstack adjusts correspondingly to the nr_mfn limit.
- If the there is an error when adding the toolstack will call the
remove operation to remove the whole region.
The need to break this hypercall down is for large BARs can take
more than the guest (initial domain usually) time-slice. This has
the negative result in that the guest is locked out for a long
duration and is unable to act on any pending events.
We also augment the code to return zero if nr_mfns instead
of trying to the hypercall.
Suggested-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Jan Beulich <jbeulich at suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
This is CVE-2015-2752 / XSA-125.
Conflicts:
xen/arch/x86/domctl.c
Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
20732402] {CVE-2015-2752}
[4.1.3-25.el5.127.34]
- Xend: make pvhvm migration work from ovm328 to ovm329
The original xend patch fixes migration failure from ovm3.2.x to
ovm3.3.x, and this issue exists in xen upstream too. However, that
fix patch is not the best solution. So reverting it here for ovm329,
a new fix will be commited for ovm3.3.x and ovm3.4 to make migration
works well through all ovm version.
Signed-off-by: Annie Li <annie.li at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com> [bug 20604979]
[4.1.3-25.el5.127.33]
- switch internal hypercall restart indication from -EAGAIN to -ERESTART
-EAGAIN being a return value we want to return to the actual caller in
a couple of cases makes this unsuitable for restart indication, and x86
already developed two cases where -EAGAIN could not be returned as
intended due to this (which is being fixed here at once).
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com
Acked-by: Aravind Gopalakrishnan<Aravind.Gopalakrishnan at amd.com>
Reviewed-by: Tim Deegan <tim at xen.org>
(cherry-pick from f5118cae0a7f7748c6f08f557e2cfbbae686434a)
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Conflicts:
A LOT
[There are lot of changes to for this change. We only care about the
one in the domain destruction. We need the value -EAGAIN to be passed
in the toolstack so that it will retry the destruction. Any other
value (-ERESTART) and it will stop it - which some of the other
backports do we convert -ERESTART to -EAGAIN only].
Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 20666807]
[4.1.3-25.el5.127.32]
- rc/xendomains: 'stop' - also take care of stuck guests.
When we are done shutting down the guests (xm --shutdown --all)
are at that point not running at all. They might still have
QEMU or backend drivers setup due to the asynchronous nature
of 'shutdown' process. As such doing an 'destroy' on all
the guests will assure us that the backend drivers and QEMU
are indeed stopped.
The mechanism by which 'shutdown' works is quite complex. There
are three actors at play:
a) xm client (Which connects to the XML RPC),
b) Xend Xenstore watch thread,
c) XML RPC server thread
The way shutdown starts is:
xm client | XML RPC | watch thread
shutdown.py
- server....shutdown ---|--> XenDomainInfo:shutdown
Sets "control/shutdown"
calls xc.domain_shutdown
returns
- loops calling:
domains_with_state ----|-->XendDomain:list_names
gets active |
and inactive | watchMain
list _on_domains_changed
- _refresh
-> _refreshTxn
-> update [sets to
DOM_STATE_SHUTDOWN]
->refreshShutd
own
[spawns a ne
w thread calling _maybeRestart]
[_maybeRestart thread]:
destroy
[sets it to DOM_STATE_HALTED]
-cleanupDomain
- _releaseDevices
- ..
Four threads total.
There is a race between 'watchMain' being executed and
'domains_with_state'
calling 'list_names'. For guests that are in DOM_STATE_UNKNOWN or
DOM_STATE_PAUS
ED
they might not be updated to DOM_STATE_SHUTDOWN as list_names can be
called
_before_ watchMain triggers. There is an lock acquisition to call
'refresh'
in list_names - but if it fails - it will just use the stale list.
As such the process works great for guests that are in STATE_SHUTDOWN,
STATE_HALT, or STATE_RUNNING - which 'domains_with_state' will present
to shutdown process.
For the other states (The more troublesome ones) we might have them
still laying around.
As such this patch calls 'xm destroy' on all those remaining guests
to do cleanup.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 20666802]
[4.1.3-25.el5.127.31]
- xend: Fix race between shutdown and cleanup.
When we invoke 'xm shutdown --wait --all' we will exit the moment
the guest has stopped executing. That is when xcinfo returns
shutdown=1. However that does not mean that all the infrastructure
around the guest has been torn down - QEMU can be still running,
Netback and Blkback as well. In the past the time between
the shutdown and qemu being disposed of was quick - however
the race was still present there.
With our usage of PCIe passthrough we MUST unbind those devices
from a guest before we can continue on with the reboot of
the system. That is due to the complex interaction the SR-IOV
devices have with VF and PFs - as you cannot unload the PF driver
before the VFs driver have been unbound from the guest.
If you try to reboot the machine at this point the PF driver
will not unload.
The VF drivers are bound to Xen pciback - and they are unbound
when QEMU is stopped and XenStore keys are torn down - which
is done _after_ the 'shutdown' xcinfo is set (in the cleanup
stage). Worst the Xen blkback is still active - which means
we cannot unmount the storage until said cleanup has finished.
But as mentioned - 'xm shutdown --wait --all' would happily
exit before the cleanup finished and the shutdown (or reboot)
of the initial domain would continue on. It would eventually
get wedged when trying to unmount the storage which still
had a refcount from Xen block driver - which was not cleaned up
as Xend was killed earlier.
This patch solves this by delaying 'xm shutdown --wait --all'
to wait until the guest has transitioned from RUNNING ->
SHUTDOWN -> HALTED stage. The SHUTDOWN means it has ceased
to execute. The HALTED is that the cleanup is being performed.
We will cycle through all of the guests in that state until
they have moved out of those states (removed completly from
the system).
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 20661867]
[4.1.3-25.el5.127.30]
- x86emul: fully ignore segment override for register-only operations
For ModRM encoded instructions with register operands we must not
overwrite ea.mem.seg (if a - bogus in that case - segment override was
present) as it aliases with ea.reg.
This is CVE-2015-2151 / XSA-123.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Tim Deegan <tim at xen.org>
Reviewed-by: Keir Fraser <keir at xen.org>
Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 20664858]
{CVE-2015-2151}
[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]
[4.1.3-25.el5.127.6]
- set max_phys_cpus=320 [bug 19688525]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
[4.1.3-25.el5.127.5]
- xend: disable sslv3 due to CVE-2014-3566
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Backported-by: Chuang Cao <chuang.cao at oracle.com> [bug 19831403]
[4.1.3-25.el5.127.4]
- IOMMU: make page table deallocation preemptible
Backport of cedfdd43a97.
We are spending lots of time flushing CPU cache, one PTE at a time, to
make sure that IOMMU (which may not be able to watch coherence traffic
on the bus) doesn't load stale PTE from memory.
For guests with lots of memory (say, >512GB) this may take as much as
half a minute or more and as result (because this is a non-preemptable
operation) things start to break down.
Below is the original commit message:
This too can take an arbitrary amount of time.
In fact, the bulk of the work is being moved to a tasklet, as handling
the necessary preemption logic in line seems close to impossible given
that the teardown may also be invoked on error paths.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Xiantao Zhang <xiantao.zhang at intel.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19279122]
[4.1.3-25.el5.127.3]
- x86/HVM: properly bound x2APIC MSR range
While the write path change appears to be purely cosmetic (but still
gets done here for consistency), the read side mistake permitted
accesses beyond the virtual APIC page.
Note that while this isn't fully in line with the specification
(digesting MSRs 0x800-0xBFF for the x2APIC), this is the minimal
possible fix addressing the security issue and getting x2APIC related
code into a consistent shape (elsewhere a 256 rather than 1024 wide
window is being used too). This will be dealt with subsequently.
This is XSA-108.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
19723530] {CVE-2014-7188}
[4.1.3-25.el5.127.2]
- x86emul: only emulate software interrupt injection for real mode
Protected mode emulation currently lacks proper privilege checking of
the referenced IDT entry, and there's currently no legitimate way for
any of the respective instructions to reach the emulator when the guest
is in protected mode.
This is XSA-106.
Reported-by: Andrei LUTAS <vlutas at bitdefender.com>
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Keir Fraser <keir at xen.org>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
19723749] {CVE-2014-7156}
[4.1.3-25.el5.127.1]
- x86/emulate: check cpl for all privileged instructions
Without this, it is possible for userspace to load its own IDT or GDT.
This is XSA-105.
Reported-by: Andrei LUTAS <vlutas at bitdefender.com>
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Tested-by: Andrei LUTAS <vlutas at bitdefender.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
19723614] {CVE-2014-7155}
[4.1.3-25.el5.127]
- Reduce domain destroy time by delay page scrubbing
Bug 18415476 - XM DESTROY OF 1TB MEMORY GUEST TAKES LONG TIME
Because of page scrubbing, it's very slow to destroy a domain with large
memory.
This patch introduced a "PGC_need_scrub" flag, pages with this flag
means it
need to be scrubbed before use.
During domain destory, pages are marked as "PGC_need_scrub" and be
added to free
heap list, so that xl can return quickly. The real scrub is delayed
to the
allocation path if a page with "PGC_need_scrub" is allocated.
Besides that, trigger all idle vcpus to do the scrub job in parallel
before
them enter sleep.
In order to get rid of heavy lock contention, a percpu list is used:
- Delist a batch of pages to a percpu list from "scrub" free page list.
- Scrub pages on this percpu list.
- Return those clean pages to normal "heap" free page list, merge
with other
chunks if needed.
On a ~500GB guest, shutdown took slightly over one minute compared
with over 6
minutes if without this patch.
Signed-off-by: Bob Liu <bob.liu at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19580817]
[4.1.3-25.el5.126]
- tasklet: Introduce per-cpu tasklet for softirq (v5)
This implements a lockless per-cpu tasklet mechanism.
The existing tasklet mechanism has a single global
spinlock that is taken every-time the global list
is touched. And we use this lock quite a lot - when
we call do_tasklet_work which is called via an softirq
and from the idle loop. We take the lock on any
operation on the tasklet_list.
The problem we are facing is that there are quite a lot of
tasklets scheduled. The most common one that is invoked is
the one injecting the VIRQ_TIMER in the guest. Guests
are not insane and don't set the one-shot or periodic
clocks to be in sub 1ms intervals (causing said tasklet
to be scheduled for such small intervalls).
The problem appears when PCI passthrough devices are used
over many sockets and we have an mix of heavy-interrupt
guests and idle guests. The idle guests end up seeing
1/10 of its RUNNING timeslice eaten by the hypervisor
(and 40% steal time).
The mechanism by which we inject PCI interrupts is by
hvm_do_IRQ_dpci which schedules the hvm_dirq_assist
tasklet every time an interrupt is received.
The callchain is:
_asm_vmexit_handler
-> vmx_vmexit_handler
->vmx_do_extint
-> do_IRQ
-> __do_IRQ_guest
-> hvm_do_IRQ_dpci
tasklet_schedule(&dpci->dirq_tasklet);
[takes lock to put the tasklet on]
[later on the schedule_tail is invoked which is 'vmx_do_resume']
vmx_do_resume
-> vmx_asm_do_vmentry
-> call vmx_intr_assist
-> vmx_process_softirqs
-> do_softirq
[executes the tasklet function, takes the
lock again]
While on other CPUs they might be sitting in a idle loop
and invoked to deliver an VIRQ_TIMER, which also ends
up taking the lock twice: first to schedule the
v->arch.hvm_vcpu.assert_evtchn_irq_tasklet (accounted to
the guests' BLOCKED_state); then to execute it - which is
accounted for in the guest's RUNTIME_state.
The end result is that on a 8 socket machine with
PCI passthrough, where four sockets are busy with interrupts,
and the other sockets have idle guests - we end up with
the idle guests having around 40% steal time and 1/10
of its timeslice (3ms out of 30 ms) being tied up
taking the lock. The latency of the PCI interrupts delieved
to guest is also hindered.
With this patch the problem disappears completly.
That is removing the lock for the PCI passthrough use-case
(the 'hvm_dirq_assist' case).
As such this patch introduces the code to setup
softirq per-cpu tasklets and only modifies the PCI
passthrough cases instead of doing it wholesale. This
is done because:
- We want to easily bisect it if things break.
- We modify the code one section at a time to
make it easier to review this core code.
Now on the code itself. The Linux code (softirq.c)
has an per-cpu implementation of tasklets on which
this was based on. However there are differences:
- This patch executes one tasklet at a time - similar
to how the existing implementation does it.
- We use a double-linked list instead of a single linked
list. We could use a single-linked list but folks are
more familiar with 'list_*' type macros.
- This patch does not have the cross-CPU feeders
implemented. That code is in the patch
titled: tasklet: Add cross CPU feeding of per-cpu
tasklets. This is done to support:
"tasklet_schedule_on_cpu"
- We add an temporary 'TASKLET_SOFTIRQ_PERCPU' which
is can co-exist with the TASKLET_SOFTIRQ. It will be
replaced in 'tasklet: Remove the old-softirq
implementation."
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 18132003]
[4.1.3-25.el5.125]
- x86/pci: Store VF's memory space displacement in a 64-bit value
VF's memory space offset can be greater than 4GB and therefore needs
to be stored in a 64-bit variable.
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Ported from Oracle bug 18262495, OVM 3.3.1
mainline Xen commit 001bdcee7bc19be3e047d227b4d940c04972eb02
(x86/pci: Store VF's memory space displacement in a 64-bit value)
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 18190502]
[4.1.3-25.el5.124]
- libxl/sysctl/ionuma: Make 'xl info -n' print device topology
'xl info -n' will provide both CPU and IO topology information. Note
that xend (i.e. 'xm' variant of this command) will continue to only
print CPU topology.
To minimize code changes, libxl_get_topologyinfo (libxl's old interface
for topology) is preserved so its users (other than
output_topologyinfo())
are not modified.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19130568]
[4.1.3-25.el5.123]
- pci: Manage NUMA information for PCI devices
Keep track of device's PXM data (in the form of node ID)
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19130568]
[4.1.3-25.el5.122]
- pci: Add add physdevops
This is a partial backport of upstream's 7620c0cf ("PCI multi-seg: add
new physdevop-s").
We need to support PHYSDEVOP_pci_device_add (and, for symmetry,
PHYSDEVOP_pci_device_remove) in order to properly pass device's PXM
object from dom0 to the hypervisor.
Most of the rest of the original commit is adding support for
multi-segment buses. The hypervisor will (continue to) ignore
segment value passed from dom0. PHYSDEVOP_restore_msi_ext is also
not ported.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 19130568]
[4.1.3-25.el5.121]
- xend: fix domain destroy after reboot
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Joe Jin <joe.jin at oracle.com>
Signed-off-by: Iain MacDonnell <iain.macdonnell at oracle.com> [bug
19557390]
[4.1.3-25.el5.120]
- xen: Only allocating the xenstore event channel earlier
This patch allocates xenstore event channel earlier to fix the migration
issue from ovm3.2.8 to 3.3.1, and also reverts the change for console
event channel to avoid it is set to none after allocation.
Signed-off-by: Annie Li <annie.li at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Backported-by: Joe Jin <joe.jin at oracle.com> [bug 19517920]
[4.1.3-25.el5.119]
- Keep the maxmem and memory same in vm.cfg
Singed-off-by: Annie Li <annie.li at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Signed-off-by: Joe Jin <joe.jin at oracle.com> [bug 19443543]
[4.1.3-25.el5.118]
- Allocates xenstore event channel as early as possible.
Allocates xenstore event channel as early as possible to keep xenstore
event channel same during migration between two different version of Xen.
Signed-off-by: Annie Li <annie.li at oracle.com>
Backported-by: Joe Jin <joe.jin at oracle.com> [bug 19517920]
[4.1.3-25.el5.117]
- x86/hvm: reset TSC to 0 after domain resume from S3
Host S3 implicitly resets the host TSC to 0, but the tsc offset for hvm
domains is not recalculated when they resume, causing it to go into
negative values. In Linux guest using tsc clocksource, this results in
a hang after wrap back to positive values since the tsc clocksource
implementation expects it reset.
Signed-off-by: Tomasz Wroblewski <tomasz.wroblewski at citrix.com>
Ported from Xen mainline e95dc6ba69daef6468b3ae5912710727244d6e2f
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Signed-off-by: Jason Luan <jianhai.luan at oracle.com> [bug 17502351]
[4.1.3-25.el5.116]
- x86/vtsc: update vcpu_time in hvm_set_guest_time
When using a vtsc, hvm_set_guest_time changes hvm_vcpu.stime_offset,
which is used in the vcpu time structure to calculate the
tsc_timestamp, so after updating stime_offset we need to propagate the
change to vcpu_time in order for the guest to get the right time if
using the PV clock.
Signed-off-by: Roger Pau Monn?195?169 <roger.pau at citrix.com>
Reviewed-by: George Dunlap <george.dunlap at eu.citrix.com>
master commit: 32c864a35ece2c24a336d183869a546798a4b241
master date: 2013-06-05 10:03:08 +0200
Ported from Xen mainline 8b94e436ed3f83e899f5b0cc403461f95750964b
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Signed-off-by: Jason Luan <jianhai.luan at oracle.com> [bug 17502351]
[4.1.3-25.el5.115]
- x86/HVM: fix initialization of wallclock time for PVHVM on migration
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Call update_domain_wallclock_time on hvm_latch_shinfo_size even if
the bitness of the guest has already been set, this fixes the problem
with the wallclock not being set for PVHVM guests on resume from
migration.
Signed-off-by: Roger Pau Monn?195?169 <roger.pau at citrix.com>
Clean up the resulting code and retain the (slightly adjusted) original
comment.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Keir Fraser <keir at xen.org>
master commit: f8e8fd56bd7d5675e8331b4ec74bae76c9dbf24e
master date: 2013-06-12 10:05:39 +0200
Ported from Xen mainline e3962c81ef8b04bf84df971ec26e2c160d6b1bac
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Signed-off-by: Jason Luan <jianhai.luan at oracle.com> [bug 17502351]
[4.1.3-25.el5.114]
- x86: don't pass negative time to gtime_to_gtsc() (try 2)
This mostly reverts commit eb60be3d ("x86: don't pass negative time to
gtime_to_gtsc()") and instead corrects __update_vcpu_system_time()'s
handling of this_cpu(cpu_time).stime_local_stamp dating back before the
start of a HVM guest (which would otherwise lead to a negative value
getting passed to gtime_to_gtsc(), causing scale_delta() to produce
meaningless output).
Flushing the value to zero was wrong, and printing a message for
something that can validly happen wasn't very useful either.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Keir Fraser <keir at xen.org>
master commit: 5ad914bc867c5a6a4957869c89918f4e1f9dd9c4
master date: 2013-07-02 08:48:03 +0200
Ported from Xen mainline 4e5c53055025170124213e8cb4844e66f2f6ec12
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Signed-off-by: Jason Luan <jianhai.luan at oracle.com> [bug 17502351]
[4.1.3-25.el5.113]
- x86: don't pass negative time to gtime_to_gtsc()
scale_delta(), which is being called by that function, doesn't cope
with that.
Also print a warning message, so hopefully we can eventually figure why
occasionally a negative value results from the calculation in the first
place.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Keir Fraser <keir at xen.org>
Ported from Xen mainline commit eb60be3dd870aecfa47bed1118069680389c15f7
as a prerequisite for porting 4e5c53055025170124213e8cb4844e66f2f6ec12
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Signed-off-by: Jason Luan <jianhai.luan at oracle.com> [bug 17502351]
[4.1.3-25.el5.112]
- x86/time: Update wallclock in shared info when altering domain time offset
domain_set_time_offset() udpates d->time_offset_seconds, but does not
correct
the wallclock in the shared info, meaning that it is incorrect until
the next
XENPF_settime hypercall from dom0 which resynchronises the wallclock
for all
domains.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Keir Fraser <keir at xen.org>
master commit: 915a59f25c5eddd86bc2cae6389d0ed2ab87e69e
master date: 2013-07-18 09:16:15 +0200
Ported from Xen mainline c60e85a6a61af79ef49094be28588760993183d1
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Signed-off-by: Jason Luan <jianhai.luan at oracle.com> [bug 17502351]
[4.1.3-25.el5.111]
- Oel7 PVM can't be started as it can't parse ${next_entry} in grub2.
Set the arg with 0.
Signed-off-by: Marcel Mol <marcel at mesa.nl>
Signed-off-by: Chuang Cao <chuang.cao at oracle.com>
Acked-by: Ian Campbell <ian.campbell at citix.com>
Acked-by: Joe Jin <joe.jin at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Acked-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug 18969789]
[4.1.3-25.el5.110]
- pygrub: XFS support for pygrub
Signed-off-by: Joe Jin <joe.jin at oracle.com> [bug 19056041]
[4.1.3-25.el5.109]
- 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 18969917]
{CVE-2014-????}
[4.1.3-25.el5.108]
- reduce minimum restart time to 10 seconds
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Backported-by: Joe Jin <joe.jin at oracle.com> [bug 18969630]
[4.1.3-25.el5.107]
- check in upstream dd03048 patch to add support for OL7 VM
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Backported-by: Chuang Cao <chuang.cao at oracle.com> [bug 18665574]
[4.1.3-25.el5.106]
- x86/HVM: use fixed TSC value when saving or restoring domain
When a domain is saved each VCPU's TSC value needs to be preserved.
To get it we
use hvm_get_guest_tsc(). This routine (either itself or via
get_s_time() which
it may call) calculates VCPU's TSC based on current host's TSC value
(by doing a
rdtscll()). Since this is performed for each VCPU separately we end
up with
un-synchronized TSCs.
Similarly, during a restore each VCPU is assigned its TSC based on
host's current
tick, causing virtual TSCs to diverge further.
With this, we can easily get into situation where a guest may see
time going
backwards.
Instead of reading new TSC value for each VCPU when saving/restoring
it we should
use the same value across all VCPUs.
Reported-by: Philippe Coquard <philippe.coquard at mpsa.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Backported-by: Joe Jin <joe.jin at oracle.com>
(commit 88e64cb785c1de4f686c1aa1993a0003b7db9e1a of upstream) [bug
16929020]
[4.1.3-25.el5.105]
- x86/svm: enable TSC scaling
TSC ratio enabling logic is inverted: we want to use it when we
are running in native tsc mode, i.e. when d->arch.vtsc is zero.
Also, since now svm_set_tsc_offset()'s calculations depend
on vtsc's value, we need to call hvm_funcs.set_tsc_offset() after
vtsc changes in tsc_set_info().
In addition, with TSC ratio enabled, svm_set_tsc_offset() will
need to do rdtsc. With that we may end up having TSCs on guest's
processors out of sync. d->arch.hvm_domain.sync_tsc which is set
by the boot processor can now be used by APs as reference TSC
value instead of host's current TSC.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Backported-by: Joe Jin <joe.jin at oracle.com>
(commit b95fd03b5f0b66384bd7c190d5861ae68eb98c85 of upstream) [bug
16929020]
[4.1.3-25.el5.104]
- iommu: set correct IOMMU entries when iommu_hap_pt_share == 0
If the memory map is not shared between HAP and IOMMU we fail to set
correct IOMMU mappings for memory types other than p2m_ram_rw.
This patchs adds IOMMU support for the following memory types:
p2m_grant_map_rw, p2m_map_foreign, p2m_ram_ro, p2m_grant_map_ro and
p2m_ram_logdirty.
Signed-off-by: Roger Pau Monn?195?169 <roger.pau at citrix.com>
Cc: Tim Deegan <tim at xen.org>
Cc: Jan Beulich <jbeulich at suse.com>
Tested-by: David Zhuang <david.zhuang at oracle.com>
---
Changes since v1:
- Move the p2m type switch to IOMMU flags to an inline function that
is shared between p2m-ept and p2m-pt.
- Make p2m_set_entry also use p2m_get_iommu_flags.
---
When backporting this patch it would not apply cleanly due to two commits
not existing in the Xen 4.3 repo:
commit 243cebb3dfa1f94ec7c2b040e8fd15ae4d81cc5a
Author: Mukesh Rathor <mukesh.rathor at oracle.com>
Date: Thu Apr 17 10:05:07 2014 +0200
pvh dom0: introduce p2m_map_foreign
[adds the p2m_map_foreign type]
commit 3d8d2bd048773ababfa65cc8781b9ab3f5cf0eb0
Author: Jan Beulich <jbeulich at suse.com>
Date: Fri Mar 28 13:37:10 2014 +0100
x86/EPT: simplification and cleanup
[simplifies the loop in ept_set_entry]
As such the original patch from
http://lists.xen.org/archives/html/xen-devel/2014-04/msg02928.html
has been slightly changed.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Backported-by: Joe Jin <joe.jin at oracle.com> [bug 18730424]
[4.1.3-25.el5.103]
- Fix XSA-46 regression with xend/xm
The hypervisor side changes for XSA-46 require the tool stack to now
always map the guest pIRQ before granting access permission to the
underlying host IRQ (GSI). This in particular requires that pciif.py
no longer can skip this step (assuming qemu would do it) for HVM
guests.
This in turn exposes, however, an inconsistency between xend and qemu:
The former wants to always establish 1:1 mappings between pIRQ and host
IRQ (for non-MSI only of course), while the latter always wants to
allocate an arbitrary mapping. Since the whole tool stack obviously
should always agree on the mapping model, make libxc enforce the 1:1
mapping as the more natural one (as well as being the one that allows
for easier debugging, since there no need to find out the extra
mapping). Users of libxc that want to establish a particular (rather
than an allocated) mapping are still free to do so, as well as tool
stacks not based on libxc wanting to implement an allocation based
model (which is why it's not the hypervisor that's being changed to
enforce either model).
Since libxl, like xend, already uses a 1:1 model, it's unaffected by
the libxc change (and it being unaffected by the original hypervisor
side changes is - afaict - simply due to qemu getting spawned at a
later point in time compared to the xend event flow).
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Tested-by: Andreas Falck <falck.andreas.lists at gmail.com> (on 4.1)
Tested-by: Gordan Bobic <gordan at bobich.net> (on 4.2)
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
master commit: 934a5253d932b6f67fe40fc48975a2b0117e4cce
master date: 2013-05-21 11:32:34 +0200
Signed-off-by: Joe Jin <joe.jin at oracle.com>
Tested-by: Bin Yan <bin.yan at oracle.com> [bug 18612187]
[4.1.3-25.el5.102]
- qemu-xen-trad: free all the pirqs for msi/msix when driver unload
Pirqs are not freed when driver unload, then new pirqs are allocated when
driver reload. This could exhaust pirqs if do it in a loop.
This patch fixes the bug by freeing pirqs when ENABLE bit is cleared in
msi/msix control reg.
There is also other way of fixing it such as reuse pirqs between
driver reload,
but this way is better.
Xen-devel: http://marc.info/?l=xen-devel&m=136800120304275&w=2
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
[and in OVS]:
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 17230232]
[4.1.3-25.el5.101]
- x86: fix emuirq regression from XSA-21 fix
The XSA-21 patch broke the assumption of "ret" being zero prior to the
IRQ_UNBOUND check.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
[and in OVS]:
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 17230232]
[4.1.3-25.el5.100]
- qemu-xen-trad/pt_msi_disable: do not clear all MSI flags
"qemu-xen-trad: fix msi_translate with PV event delivery" added a
pt_msi_disable() call into pt_msgctrl_reg_write, clearing the MSI flags
as a consequence. MSIs get enabled again soon after by calling
pt_msi_setup.
However the MSI flags are only setup once in the pt_msgctrl_reg_init
function, so from the QEMU point of view the device has lost some
important properties, like for example PCI_MSI_FLAGS_64BIT.
This patch fixes the bug by clearing only the MSI
enabled/mapped/initialized flags in pt_msi_disable.
Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Tested-by: G.R. <firemeteor at users.sourceforge.net>
Xen-devel: http://marc.info/?l=xen-devel&m=135489879503075
[and in OVS]:
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 17230232]
[4.1.3-25.el5.99]
- qemu: clean up MSI-X table handling
This patch does cleaning up of QEMU MSI handling. The fixes are:
1. Changes made to MSI-X table mapping handling to eliminate the small
windows in which guest could have access to physical MSI-X table.
2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is
already in Xen now.
3. For registers that coexists inside the MSI-X table (this could be
only PBA I think), value read from physical page would be returned.
Signed-off-by: Shan Haitao <maillists.shan at gmail.com>
Consolidated duplicate code into _pt_iomem_helper(). Fixed formatting.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Haitao Shan <haitao.shan at intel.com>
Acked-by: Stefano Stabellini <Stefano.Stabellini at eu.citrix.com>
[and in OVS]:
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 17230232]
[4.1.3-25.el5.98]
- Remove this unnecessory code to keep same with xen upstream
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 17230232]
[4.1.3-25.el5.97]
- Just release running lock after a domain is gone.
Signed-off-by: Chuang Cao <chuang.cao at oracle.com>
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Acked-by: Julie Trask <julie.trask at oracle.com>
Backported-by: Chuang Cao <chuang.cao at oracle.com> [bug 18479266]
[4.1.3-25.el5.96]
- libxc: Replace alloca() with mmap() for large array sizes
Replace alloca() with mmap() for array sizes greater than a page in
xc_linux_osdep.c.
When mapping in large amounts of pages (in the GB range) from a guest
in to Dom0 using xc_map_foreign_bulk(), a segfault occurs in the libxc
client application. This is because the pfn array in
linux_privcmd_map_foreign_bulk() is being allocated using alloca() and
the subsequent memcpy causes the stack to blow. This patch replaces
the alloca() with mmap() for pfn array sizes greater than a page.
Fix an error print with the correct function name.
Do the same for the map array in linux_gnttab_grant_map()
Signed-off-by: Aravindh Puthiyaparambil <aravindh at virtuata.com>
Acked-by: Andres Lagar-Cavilla <andres at lagarcavilla.org>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Committed-by: Ian Jackson <ian.jackson at eu.citrix.com>
Backported-by: Joe Jin <joe.jin at oracle.com> [bug 18435911]
[4.1.3-25.el5.95]
- x86/MSI: fix 2nd S3 resume with interrupt remapping enabled
The first resume from S3 was corrupting internal data structures (in
that pci_restore_msi_state() updated the globally stored MSI message
from traditional to interrupt remapped format, which would then be
translated a second time during the second resume, breaking interrupt
delivery).
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Keir Fraser <keir at xen.org>
Backport from upstream commit 42599de39a98fd826b6b6bac0738a8a0d9df18fe
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk<konrad.wilk at oracle.com> [bug 16309346]
[4.1.3-25.el5.94]
- update CVE number and rebuild
[4.1.3-25.el5.93]
- flask: restrict allocations done by hypercall interface
Other than in 4.2 and newer, we're not having an overflow issue here,
but uncontrolled exposure of the operations opens the host to be driven
out of memory by an arbitrary guest. Since all operations other than
FLASK_LOAD simply deal with ASCII strings, limiting the allocations
(and incoming buffer sizes) to a page worth of memory seems like the
best thing we can do.
Consequently, in order to not expose the larger allocation to arbitrary
guests, the permission check for FLASK_LOAD needs to be pulled ahead of
the allocation (and it's perhaps worth noting that - afaict - it was
pointlessly done with the sel_sem spin lock held).
Note that this breaks FLASK_AVC_CACHESTATS on systems with sufficiently
many CPUs (as requiring a buffer bigger than PAGE_SIZE there). No
attempt is made to address this here, as it would needlessly complicate
this fix with rather little gain.
This is XSA-84.
Reported-by: Matthew Daley <mattd at bugfuzz.com>
Signed-off-by: Jan Beulich <jbeulich at suse.com>
The index of boolean variables in FLASK_{GET,SET}BOOL was not always
checked against the bounds of the array.
Reported-by: John McDermott <john.mcdermott at nrl.navy.mil>
Signed-off-by: Daniel De Graaf <dgdegra at tycho.nsa.gov>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: Reviewed-by: John Haxby <john.haxby at oracle.com> [bug
18197025] {CVE-2014-1892,CVE-2014-1893}
[4.1.3-25.el5.92]
- libxc: Fix out-of-memory error handling in xc_cpupool_getinfo()
Avoid freeing info then returning it to the caller.
This is XSA-88.
Coverity-ID: 1056192
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: Reviewed-by: John Haxby <john.haxby at oracle.com> [bug
18174867] {CVE-2014-1950}
[4.1.3-25.el5.91]
- From 708e128356e23271e05cab8514ec03277e8b3646 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
Date: Wed, 12 Sep 2012 19:31:16 +0100
Subject: [PATCH] x86/passthrough: Fix corruption caused by race
conditions
between device allocation and deallocation to a domain.
A toolstack, when dealing with a domain using PCIPassthrough, could
reasonably be expected to issue DOMCTL_deassign_device hypercalls to
remove all passed through devices before issuing a
DOMCTL_destroydomain hypercall to kill the domain. In the case where
a toolstack is perhaps less sensible in this regard, the hypervisor
should not fall over.
In domain_kill(), pci_release_devices() searches the alldevs_list list
looking for PCI devices still assigned to the domain. If the
toolstack has correctly deassigned all devices before killing the
domain, this loop does nothing.
However, if there are still devices attached to the domain, the loop
will call pci_cleanup_msi() without unbinding the pirq from the
domain. This eventually calls destroy_irq() which xfree()'s the
action.
However, as the irq_desc->action pointer is abused in an unsafe
matter, without unbinding first (which at least correctly cleans up),
the action is actually an irq_guest_action_t* rather than an
irqaction*, meaning that the cpu_eoi_map is leaked, and eoi_timer is
free()'d while still being on a pcpu's inactive_timer list. As a
result, when this free()'d memory gets reused, the inactive_timer list
becomes corrupt, and list_*** operations will corrupt hypervisor
memory.
If the above were not bad enough, the loop in pci_release_devices()
still leaves references to the irq it destroyed in
domain->arch.pirq_irq and irq_pirq, meaning that a later loop,
free_domain_pirqs(), which happens as a result of
complete_domain_destroy() will unbind and destroy all irqs which were
still bound to the domain, resulting in a double destroy of any irq
which was still bound to the domain at the point at which the
DOMCTL_destroydomain hypercall happened.
Because of the allocation of irqs from find_unassigned_irq(), the
lowest free irq number is going to be handed back from create_irq().
There is a further race condition between the original (incorrect)
call to destroy_irq() from pci_release_devices(), and the later call
to free_domain_pirqs() (which happens in a softirq context at some
point after the domain has officially died) during which the same irq
number (which is still referenced in a stale way in
domain->arch.pirq_irq and irq_pirq) has been allocated to a new domain
via a PHYSDEVOP_map_pirq hypercall (Say perhaps in the case of
rebooting a domain).
In this case, the cleanup for the dead domain will free the recently
bound irq under the feet of the new domain. Furthermore, after the
irq has been incorrectly destroyed, the same domain with another
PHYSDEVOP_map_pirq hypercall can be allocated the same irq number as
before, leading to an error along the lines of:
../physdev.c:188: dom54: -1:-1 already mapped to 74
In this case, the pirq_irq and irq_pirq mappings get updated to the
new PCI device from the latter PHYSDEVOP_map_pirq hypercall, and the
IOMMU interrupt remapping registers get updated, leading to IOMMU
Primary Pending Fault due to source-id verification failure for
incoming interrupts from the passed through device.
The easy fix is to simply deassign the device in pci_release_devices()
and leave all the real cleanup to the free_domain_pirqs() which
correctly unbinds and destroys the irq without leaving stale
references around.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Committed-by: Keir Fraser <keir at xen.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 17313566]
[4.1.3-25.el5.90]
- Xend: handle died domain in getVCPUInfo()
When created new guest on NUMA server, xend tried to get the best node
by calculated all vcpus info, if domain already be terminated then
getVCPUInfo() will throw below exception and guest start failed:
[2013-09-04 20:01:26 6254] ERROR (XendDomainInfo:496) VM start failed
Traceback (most recent call last):
File "/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 482, in start
XendTask.log_progress(31, 60, self._initDomain)
File "/usr/lib64/python2.4/site-packages/xen/xend/XendTask.py", line
209, in log_progress
retval = func(*args, **kwds)
File "/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 2918, in _initDomain
node = self._setCPUAffinity()
File "/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 2835, in _setCPUAffinity
best_node = find_relaxed_node(candidate_node_list)[0]
File "/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 2803, in find_relaxed_node
cpuinfo = dom.getVCPUInfo()
File "/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 1600, in getVCPUInfo
raise XendError(str(exn))
XendError: (3, 'No such process')
This patch will check return value of xc.vcpu_getinfo() and make sure the
error not caused by domain died before throw the exception.
Signed-off-by: Joe Jin <joe.jin at oracle.com>
Acked-by: Matt Wilson <msw at amazon.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug 17962304]
[4.1.3-25.el5.89]
- x86/AMD: work around erratum 793
The recommendation is to set a bit in an MSR - do this if the firmware
didn't, considering that otherwise we expose ourselves to a guest
induced DoS.
This is CVE-2013-6885 / XSA-82.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 17872288]
{CVE-2013-6885}
[4.1.3-25.el5.88]
- x86/HVM: only allow ring 0 guest code to make hypercalls
Anything else would allow for privilege escalation.
This is CVE-2013-4554 / XSA-76.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: Jerry Snitselaar <jerry.snitselaar at oracle.com> [bug
17822232] {CVE-2013-4554}
[4.1.3-25.el5.87]
- x86: restrict XEN_DOMCTL_getmemlist
Coverity ID 1055652
(See the code comment.)
This is CVE-2013-4553 / XSA-74.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Tim Deegan <tim at xen.org>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: Jerry Snitselaar <jerry.snitselaar at oracle.com> [bug
17821622] {CVE-2013-4553}
[4.1.3-25.el5.86]
- gnttab: update version 1 of xsa73-4.1.patch to version 3
Version 1 of xsa73-4.1.patch had an error:
bool_t drop_dom_ref = (e->tot_pages-- == 0);
should have been:
bool_t drop_dom_ref = (e->tot_pages-- == 1);
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Consolidate error handling.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Keir Fraser <keir at xen.org>
Tested-by: Matthew Daley <mattjd at gmail.com>
Backported to Xen-4.1
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug
17760875] {CVE-2013-4494}
[4.1.3-25.el5.85]
- Xen: Spread boot time page scrubbing across all available CPU's
Written by Malcolm Crossley <malcolm.crossley at citrix.com>
The page scrubbing is done in 256MB chunks in lockstep across all the
CPU's.
This allows for the boot CPU to hold the heap_lock whilst each chunk
is being
scrubbed and then release the heap_lock when all CPU's are finished
scrubing
their individual chunk. This allows for the heap_lock to not be held
continously and for pending softirqs are to be serviced periodically
across
all CPU's.
The page scrub memory chunks are allocated to the CPU's in a NUMA aware
fashion to reduce Socket interconnect overhead and improve performance.
This patch reduces the boot page scrub time on a 256GB 16 core AMD
Opteron
machine from 1 minute 46 seconds to 38 seconds.
Signed-off-by: Mukesh Rathor <mukesh.rathor at oracle.com> [bug 17723396]
[4.1.3-25.el5.84]
- gnttab: correct locking order reversal
Coverity ID 1087189
Correct a lock order reversal between a domains page allocation and grant
table locks.
This is XSA-73.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Consolidate error handling.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Keir Fraser <keir at xen.org>
Tested-by: Matthew Daley <mattjd at gmail.com>
Backported to Xen-4.1
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug
17723396] {CVE-2013-4494}
[4.1.3-25.el5.83]
- piix4acpi, xen, hotplug: Fix race with ACPI AML code and hotplug.
This is a race so the amount varies but on a 4PCPU box
I seem to get only ~14 out of 16 vCPUs I want to online.
The issue at hand is that QEMU xenstore.c hotplug code changes
the vCPU array and triggers an ACPI SCI for each vCPU
online/offline change. That means we modify the array of vCPUs
as the guests ACPI AML code is reading it - resulting in
the guest reading the data only once and not changing the
CPU states appropiately.
The fix is to seperate the vCPU array changes from the ACPI SCI
notification. The code now will enumerate all of the vCPUs
and change the vCPU array if there is a need for a change.
If a change did occur then only _one_ ACPI SCI pulse is sent
to the guest. The vCPU array at that point has the online/offline
modified to what the user wanted to have.
Specifically, if a user provided this command:
xl vcpu-set latest 16
(guest config has vcpus=1, maxvcpus=32) QEMU and the guest
(in this case Linux) would do:
QEMU: Guest OS:
-xenstore_process_vcpu_set_event
-> Gets an XenBus notification for CPU1
-> Updates the gpe_state.cpus_state bitfield.
-> Pulses the ACPI SCI
- ACPI SCI kicks in
-> Gets an XenBus notification for CPU2
-> Updates the gpe_state.cpus_state bitfield.
-> Pulses the ACPI SCI
-> Gets an XenBus notification for CPU3
-> Updates the gpe_state.cpus_state bitfield.
-> Pulses the ACPI SCI
...
- Method(PRST) invoked
-> Gets an XenBus notification for CPU12
-> Updates the gpe_state.cpus_state bitfield.
-> Pulses the ACPI SCI
- reads AF00 for CPU state
[gets 0xff]
- reads AF02 [gets 0x7f]
-> Gets an XenBus notification for CPU13
-> Updates the gpe_state.cpus_state bitfield.
-> Pulses the ACPI SCI
.. until VCPU 16
- Method PRST updates
PR01 through 13 FLG
entry.
- PR01->PR13 _MAD
invoked.
- Brings up 13 CPUs.
While QEMU updates the rest of the cpus_state bitfields the ACPI AML
only does the CPU hotplug on those it had read.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
[v1: Use stack for the 'attr' instead of malloc/free]
Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Acked-by: George Dunlap <george.dunlap at eu.citrix.com> (for 4.3 release)
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 17504060]
[4.1.3-25.el5.82]
- piix4acpi, xen: Clarify that the qemu_set_irq calls just do an IRQ pulse.
The "qemu_cpu_notify" raises and lowers the ACPI SCI line when the
vCPU state has changed.
Instead of doing the two functions, just use one function that
describes exactly what it does.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 17504060]
[4.1.3-25.el5.81]
- piix4acpi, xen, vcpu hotplug: Split the notification from the changes.
This is a prepatory patch that splits the notification
of an vCPU change from the actual changes to the vCPU array.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 17504060]
[4.1.3-25.el5.80]
- Backported Carson's changes - Requests to connect on port 8003 with a
LOW/weak cipher are now rejected.
Signed-off-by: Carson Hovey [bug 17669909]
[4.1.3-25.el5.79]
- x86: check segment descriptor read result in 64-bit OUTS emulation
When emulating such an operation from a 64-bit context (CS has long
mode set), and the data segment is overridden to FS/GS, the result of
reading the overridden segment's descriptor (read_descriptor) is not
checked. If it fails, data_base is left uninitialized.
This can lead to 8 bytes of Xen's stack being leaked to the guest
(implicitly, i.e. via the address given in a #PF).
Coverity-ID: 1055116
This is CVE-2013-4368 / XSA-67.
Signed-off-by: Matthew Daley <mattjd at gmail.com>
Fix formatting.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: Guangyu Sun <guangyu.sun at oracle.com> [bug 17597127]
{CVE-2013-4368}
[4.1.3-25.el5.78]
- Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: Jerry Snitselaar <jerry.snitselaar at oracle.com> [bug
17472532] {CVE-2013-4361}
[4.1.3-25.el5.77]
- x86: properly handle hvm_copy_from_guest_{phys,virt}() errors
Ignoring them generally implies using uninitialized data and, in all
cases dealt with here, potentially leaking hypervisor stack contents to
guests.
This is XSA-63.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Tim Deegan <tim at xen.org>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: Jerry Snitselaar <jerry.snitselaar at oracle.com> [bug
17472447] {CVE-2013-4355}
[4.1.3-25.el5.76]
- x86/xsave: initialize unused register state when restoring for guest
In order to avoid leaking register contents from the prior use of the
registers restored through xrstor due to a guest enabling certain xcr0
bits late (particularly after the context restor in question), force
restoring of all known registers (the ones that never got saved would
be forced to their init state).
This is CVE-2013-1442 / XSA-62.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 17470105]
{CVE-2013-1442}
[4.1.3-25.el5.75]
- libxl: suppress device assignment to HVM guest when there is no IOMMU
This in effect copies similar logic from xend: While there's no way to
check whether a device is assigned to a particular guest,
XEN_DOMCTL_test_assign_device at least allows checking whether an
IOMMU is there and whether a device has been assign to _some_
guest.
For the time being, this should be enough to cover for the missing
error checking/recovery in other parts of libxl's device assignment
paths.
There remains a (functionality-, but not security-related) race in
that the iommu should be set up earlier, but this is too risky a
change for this stage of the 4.3 release.
This is a security issue, XSA-61.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Tested-by: George Dunlap <george.dunlap at eu.citrix.com>
Acked-by: George Dunlap <george.dunlap at eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson at eu.citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 17457971]
{CVE-2013-4329}
[4.1.3-25.el5.74]
- [PATCH 21/21] libxc: check blob size before proceeding in
xc_dom_check_gzip
This is part of the fix to a security issue, XSA-55.
Signed-off-by: Matthew Daley <mattjd at gmail.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16903001]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.73]
- [PATCH 20/21] libxc: range checks in xc_dom_p2m_host and _guest
These functions take guest pfns and look them up in the p2m. They did
no range checking.
However, some callers, notably xc_dom_boot.c:setup_hypercall_page want
to pass untrusted guest-supplied value(s). It is most convenient to
detect this here and return INVALID_MFN.
This is part of the fix to a security issue, XSA-55.
Changes from Xen 4.2 version of this patch:
* 4.2 lacks dom->rambase_pfn, so don't add/subtract/check it.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16903001]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.72]
- [PATCH 19/21] libxc: check return values from malloc
A sufficiently malformed input to libxc (such as a malformed input ELF
or other guest-controlled data) might cause one of libxc's malloc() to
fail. In this case we need to make sure we don't dereference or do
pointer arithmetic on the result.
Search for all occurrences of b(m|c|re)alloc in libxc, and all
functions which call them, and add appropriate error checking where
missing.
This includes the functions xc_dom_malloc*, which now print a message
when they fail so that callers don't have to do so.
The function xc_cpuid_to_str wasn't provided with a sane return value
and has a pretty strange API, which now becomes a little stranger.
There are no in-tree callers.
Changes in the Xen 4.2 version of this series:
* No need to fix code relating to ARM.
* No need to fix code relating to superpage support.
* Additionally fix `dom->p2m_host = xc_dom_malloc...' in xc_dom_ia64.c.
Changes in the Xen 4.1 version of this series:
* An additional check is needed in xc_flask.c:xc_flask_access.
This is part of the fix to a security issue, XSA-55.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16903001]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.71]
- [PATCH 18/21] libxc: check failure of xc_dom_*_to_ptr, xc_map_foreign_r
ange
The return values from xc_dom_*_to_ptr and xc_map_foreign_range are
sometimes dereferenced, or subjected to pointer arithmetic, without
checking whether the relevant function failed and returned NULL.
Add an appropriate error check at every call site.
Changes in the 4.2 backport of this series:
* Fix tools/libxc/xc_dom_x86.c:setup_pgtables_x86_32.
* Fix tools/libxc/xc_dom_ia64.c:start_info_ia64.
* Fix tools/libxc/ia64/xc_ia64_dom_fwloader.c:xc_dom_load_fw_kernel.
Conflicts in the 4.1 backport of this series:
* xc_dom_load_elf_kernel has less error handling in 4.1.
* the VM generation ID code is not in 4.1.
This is part of the fix to a security issue, XSA-55.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.70]
- [PATCH 17/21] libxc: Add range checking to xc_dom_binloader
This is a simple binary image loader with its own metadata format.
However, it is too careless with image-supplied values.
Add the following checks:
* That the image is bigger than the metadata table; otherwise the
pointer arithmetic to calculate the metadata table location may
yield undefined and dangerous values.
* When clamping the end of the region to search, that we do not
calculate pointers beyond the end of the image. The C
specification does not permit this and compilers are becoming ever
more determined to miscompile code when they can "prove" various
falsehoods based on assertions from the C spec.
* That the supplied image is big enough for the text we are allegedly
copying from it. Otherwise we might have a read overrun and copy
the results (perhaps a lot of secret data) into the guest.
This is part of the fix to a security issue, XSA-55.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.69]
- [PATCH 16/21] libelf: abolish obsolete macros
Abolish ELF_PTRVAL_[CONST_]{CHAR,VOID}; change uses to elf_ptrval.
Abolish ELF_HANDLE_DECL_NONCONST; change uses to ELF_HANDLE_DECL.
Abolish ELF_OBSOLETE_VOIDP_CAST; simply remove all uses.
No functional change. (Verified by diffing assembler output.)
This is part of the fix to a security issue, XSA-55.
Conflicts in the 4.1 backport:
* elf_load_image is not in 4.1.
* elf_note_numeric_array is not in 4.1.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.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 16903001]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.68]
- [PATCH 15/21] libelf: check loops for running away
Ensure that libelf does not have any loops which can run away
indefinitely even if the input is bogus. (Grepped for bfor, bwhile
and bgoto in libelf and xc_dom_*loader*.c.)
Changes needed:
* elf_note_next uses the note's unchecked alleged length, which might
wrap round. If it does, return ELF_MAX_PTRVAL (0xfff..fff) instead,
which will be beyond the end of the section and so terminate the
caller's loop.
* In various loops over section and program headers, check that the
calculated header pointer is still within the image, and quit the
loop if it isn't.
We have not changed loops which might, in principle, iterate over the
whole image - even if they might do so one byte at a time with a
nontrivial access check function in the middle.
This is part of the fix to a security issue, XSA-55.
Conflicts in Xen 4.1 version of the series:
* Trivial conflict due to elf_note_numeric_array not existing.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.67]
- [PATCH 14/21] libxc: Introduce xc_bitops.h
Copy the one file tools/libxc/xc_bitops.h from xen.git#aa1355f9.
We will need this for the next patch, which calls for a bitmap in
libxc.
xc_bitops.h was introduced to unify various existing sets of bitmap
operations. In this patch we backport only the introduction, not the
replacement of the other instances. So we introduce another instance
Sorry :-/.
This is part of the fix to a security issue, XSA-55.
This patch is unique to the Xen 4.1 version of the XSA-55 series.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.66]
- [PATCH 13/21] libelf: use only unsigned integers
Signed integers have undesirable undefined behaviours on overflow.
Malicious compilers can turn apparently-correct code into code with
security vulnerabilities etc.
So use only unsigned integers. Exceptions are booleans (which we have
already changed) and error codes.
We _do_ change all the chars which aren't fixed constants from our own
text segment, but not the char*s. This is because it is safe to
access an arbitrary byte through a char*, but not necessarily safe to
convert an arbitrary value to a char.
As a consequence we need to compile libelf with -Wno-pointer-sign.
It is OK to change all the signed integers to unsigned because all the
inequalities in libelf are in contexts where we don't "expect"
negative numbers.
In libelf-dominfo.c:elf_xen_parse we rename a variable "rc" to
"more_notes" as it actually contains a note count derived from the
input image. The "error" return value from elf_xen_parse_notes is
changed from -1 to ~0U.
grepping shows only one occurrence of "PRId" or "%d" or "%ld" in
libelf and xc_dom_elfloader.c (a "%d" which becomes "%u").
This is part of the fix to a security issue, XSA-55.
Conflicts in 4.1 series:
* xc_dom_load_elf_kernel has no rc variable to change.
* elf_load_image doesn't exist.
For those concerned about unintentional functional changes, the
following rune produces a version of the patch which is much smaller
and eliminates only non-functional changes:
GIT_EXTERNAL_DIFF=.../unsigned-differ git-diff <before>..<after>
where <before> and <after> are git refs for the code before and after
this patch, and unsigned-differ is this shell script:
set -e
seddery () {
perl -pe 's/b(?:elf_errorstatus|elf_negerrnoval)b/int/g'
}
path="$1"
in="$2"
out="$5"
set +e
diff -pu --label "$path~" <(seddery <"$in") --label "$path" <(seddery
<"$out
")
rc=$?
set -e
if [ $rc = 1 ]; then rc=0; fi
exit $rc
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.65]
- [PATCH 12/21] libelf: use C99 bool for booleans
We want to remove uses of "int" because signed integers have
undesirable undefined behaviours on overflow. Malicious compilers can
turn apparently-correct code into code with security vulnerabilities
etc.
In this patch we change all the booleans in libelf to C99 bool,
from <stdbool.h>.
For the one visible libelf boolean in libxc's public interface we
retain the use of int to avoid changing the ABI; libxc converts it to
a bool for consumption by libelf.
It is OK to change all values only ever used as booleans to _Bool
(bool) because conversion from any scalar type to a _Bool works the
same as the boolean test in if() or ?: and is always defined (C99
6.3.1.2). But we do need to check that all these variables really are
only ever used that way. (It is theoretically possible that the old
code truncated some 64-bit values to 32-bit ints which might become
zero depending on the value, which would mean a behavioural change in
this patch, but it seems implausible that treating 0x????????00000000
as false could have been intended.)
This is part of the fix to a security issue, XSA-55.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.64]
- [PATCH 11/21] libelf: Make all callers call elf_check_broken
This arranges that if the new pointer reference error checking
tripped, we actually get a message about it. In this patch these
messages do not change the actual return values from the various
functions: so pointer reference errors do not prevent loading. This
is for fear that some existing kernels might cause the code to make
these wild references, which would then break, which is not a good
thing in a security patch.
In xen/arch/x86/domain_build.c we have to introduce an "out" label and
change all of the "return rc" beyond the relevant point into "goto
out".
This is part of the fix to a security issue, XSA-55.
Differences in 4.1 backport:
* No xen/arch/arm.
* There was less error handling in xen/arch/x86/domain_build.c
so less need to change it.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>[PATCH 11/21]
libelf: Make
all callers call elf_check_broken
This arranges that if the new pointer reference error checking
tripped, we actually get a message about it. In this patch these
messages do not change the actual return values from the various
functions: so pointer reference errors do not prevent loading. This
is for fear that some existing kernels might cause the code to make
these wild references, which would then break, which is not a good
thing in a security patch.
In xen/arch/x86/domain_build.c we have to introduce an "out" label and
change all of the "return rc" beyond the relevant point into "goto
out".
This is part of the fix to a security issue, XSA-55.
Differences in 4.1 backport:
* No xen/arch/arm.
* There was less error handling in xen/arch/x86/domain_build.c
so less need to change it.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.63]
- [PATCH 10/21] libelf: Check pointer references in elf_is_elfbinary
elf_is_elfbinary didn't take a length parameter and could potentially
access out of range when provided with a very short image.
We only need to check the size is enough for the actual dereference in
elf_is_elfbinary; callers are just using it to check the magic number
and do their own checks (usually via the new elf_ptrval system) before
dereferencing other parts of the header.
This is part of the fix to a security issue, XSA-55.
Conflicts in 4.1 backport:
* xen/arch/x86/bzimage.c in 4.1 doesn't use elf_is_elfbinary.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.62]
- [PATCH 09/21] libelf: check all pointer accesses
We change the ELF_PTRVAL and ELF_HANDLE types and associated macros:
* PTRVAL becomes a uintptr_t, for which we provide a typedef
elf_ptrval. This means no arithmetic done on it can overflow so
the compiler cannot do any malicious invalid pointer arithmetic
"optimisations". It also means that any places where we
dereference one of these pointers without using the appropriate
macros or functions become a compilation error.
So we can be sure that we won't miss any memory accesses.
All the PTRVAL variables were previously void* or char*, so
the actual address calculations are unchanged.
* ELF_HANDLE becomes a union, one half of which keeps the pointer
value and the other half of which is just there to record the
type.
The new type is not a pointer type so there can be no address
calculations on it whose meaning would change. Every assignment or
access has to go through one of our macros.
* The distinction between const and non-const pointers and char*s
and void*s in libelf goes away. This was not important (and
anyway libelf tended to cast away const in various places).
* The fields elf->image and elf->dest are renamed. That proves
that we haven't missed any unchecked uses of these actual
pointer values.
* The caller may fill in elf->caller_xdest_base and _size to
specify another range of memory which is safe for libelf to
access, besides the input and output images.
* When accesses fail due to being out of range, we mark the elf
"broken". This will be checked and used for diagnostics in
a following patch.
We do not check for write accesses to the input image. This is
because libelf actually does this in a number of places. So we
simply permit that.
* Each caller of libelf which used to set dest now sets
dest_base and dest_size.
* In xc_dom_load_elf_symtab we provide a new actual-pointer
value hdr_ptr which we get from mapping the guest's kernel
area and use (checking carefully) as the caller_xdest area.
* The STAR(h) macro in libelf-dominfo.c now uses elf_access_unsigned.
* elf-init uses the new elf_uval_3264 accessor to access the 32-bit
fields, rather than an unchecked field access (ie, unchecked
pointer access).
* elf_uval has been reworked to use elf_uval_3264. Both of these
macros are essentially new in this patch (although they are derived
from the old elf_uval) and need careful review.
* ELF_ADVANCE_DEST is now safe in the sense that you can use it to
chop parts off the front of the dest area but if you chop more than
is available, the dest area is simply set to be empty, preventing
future accesses.
* We introduce some #defines for memcpy, memset, memmove and strcpy:
- We provide elf_memcpy_safe and elf_memset_safe which take
PTRVALs and do checking on the supplied pointers.
- Users inside libelf must all be changed to either
elf_mem*_unchecked (which are just like mem*), or
elf_mem*_safe (which take PTRVALs) and are checked. Any
unchanged call sites become compilation errors.
* We do _not_ at this time fix elf_access_unsigned so that it doesn't
make unaligned accesses. We hope that unaligned accesses are OK on
every supported architecture. But it does check the supplied
pointer for validity.
This is part of the fix to a security issue, XSA-55.
Additional change in 4.1 backport:
* ELF_PRPTRVAL needs to be defined oddly on 4.1 and earlier because
Xen's headers provide no definitions of uintptr_t or PRIuPTR.
Conflicts:
* Callers of elf_load_binary don't check its return value in 4.1.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.61]
- [PATCH 08/21] libelf: check nul-terminated strings properly
It is not safe to simply take pointers into the ELF and use them as C
pointers. They might not be properly nul-terminated (and the pointers
might be wild).
So we are going to introduce a new function elf_strval for safely
getting strings. This will check that the addresses are in range and
that there is a proper nul-terminated string. Of course it might
discover that there isn't. In that case, it will be made to fail.
This means that elf_note_name might fail, too.
For the benefit of call sites which are just going to pass the value
to a printf-like function, we provide elf_strfmt which returns
"(invalid)" on failure rather than NULL.
In this patch we introduce dummy definitions of these functions. We
introduce calls to elf_strval and elf_strfmt everywhere, and update
all the call sites with appropriate error checking.
There is not yet any semantic change, since before this patch all the
places where we introduce elf_strval dereferenced the value anyway, so
it mustn't have been NULL.
In future patches, when elf_strval is made able return NULL, when it
does so it will mark the elf "broken" so that an appropriate
diagnostic can be printed.
This is part of the fix to a security issue, XSA-55.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.60]
- [PATCH 07/21] tools/xcutils/readnotes: adjust print_l1_mfn_valid_note
Use the new PTRVAL macros and elf_access_unsigned in
print_l1_mfn_valid_note.
No functional change unless the input is wrong, or we are reading a
file for a different endianness.
Separated out from the previous patch because this change does produce
a difference in the generated code.
This is part of the fix to a security issue, XSA-55.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.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 16902314]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.59]
- [PATCH 06/21] libelf: introduce macros for memory access and pointer ha
ndling
We introduce a collection of macros which abstract away all the
pointer arithmetic and dereferences used for accessing the input ELF
and the output area(s). We use the new macros everywhere.
For now, these macros are semantically identical to the code they
replace, so this patch has no functional change.
elf_is_elfbinary is an exception: since it doesn't take an elf*, we
need to handle it differently. In a future patch we will change it to
take, and check, a length parameter. For now we just mark it with a
fixme.
Nontrivial differences in the 4.1 backport:
* We need to provide our own elf_uintptr_t since Xen doesn't.
* We see some additional differences in our verification diff.
* The "function-filter" needs to massage additional symbol names.
Conflicts:
* In xc_dom_load_elf_symtab the old code used
*(Elf64_Word*)(&shdr->e64.sh_name) and the new Elf32_Word
but in fact the type in the struct has changed too so the
new code using elf_store_field is still correct.
* loadelfimage, elf_load_image etc. don't exist and are done
directly with memcpy/memset; patch adjusted appropriately.
* elf_note_numeric_array doesn't exist in 4.1.
That this patch has no functional change can be verified as follows:
0. Copy the scripts "comparison-generate" and "function-filter"
out of this commit message.
1. Check out the tree before this patch.
2. Run the script ../comparison-generate .... ../before
3. Check out the tree after this patch.
4. Run the script ../comparison-generate .... ../after
5. diff --exclude=*.[soi] -ruN before/ after/ |less
Expect these differences:
* stubdom/zlib-x86_64/ztest*.s2
The filename of this test file apparently contains the pid.
* stubdom/grub/kexec.s2:
Large differences following ".section .debug_info" (which
the 4.1 build system erroneously fails to suppress).
* tools/libxc/xc_domain_restore.s2 (64-bit build):
One trivial code gen difference with no semantic import.
* xen/common/version.s2
The xen build timestamp appears in two diff hunks.
Verification that this is all that's needed:
In a completely built xen.git,
find * -name .*.d -type f | xargs grep -l libelf.h
Expect results in:
xen/arch/x86: Checked above.
tools/libxc: Checked above.
tools/xcutils/readnotes: Checked above.
tools/xenstore: Checked above.
xen/common/libelf:
This is the build for the hypervisor; checked in B above.
stubdom:
We have one stubdom which reads ELFs using our libelf,
pvgrub, which is checked above.
I have not done this verification for ARM.
This is part of the fix to a security issue, XSA-55.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
-8<- comparison-generate -8<-
set -ex
test $# = 3 || need-exactly-three-arguments
our_config=$1
build_rune_prefix=$2
result_dir=$3
git clean -x -d -f
cp "$our_config" .
cat <<END >>.config
debug_symbols=n
CFLAGS += -save-temps
END
perl -i~ -pe 's/ -g / -g0 / if m/^CFLAGS/' xen/Rules.mk
if [ -f ./configure ]; then
$build_rune_prefix ./configure
fi
$build_rune_prefix make -C xen
$build_rune_prefix make -C tools/include
$build_rune_prefix make -C stubdom grub
$build_rune_prefix make -C tools/libxc
$build_rune_prefix make -C tools/xenstore
$build_rune_prefix make -C tools/xcutils
rm -rf "$result_dir"
mkdir "$result_dir"
set +x
for f in `find xen tools stubdom -name *.[soi]`; do
mkdir -p "$result_dir"/`dirname $f`
cp $f "$result_dir"/${f}
case $f in
*.s)
../function-filter <$f >"$result_dir"/${f}2
;;
esac
done
echo ok.
-8<-
-8<- function-filter -8<-
use strict;
our @lines;
my $sedderybody = "sub seddery () {n";
while (<>) {
push @lines, $_;
if
(m/^(__FUNCTION__|__func__|_ctx|note_desc|types|last_order|memflags|mute
x|dd_cpu_last|write_count|wall_last|__PRETTY_FUNCTION__).(d+):/ ||
m/^s+.locals+(_ctx|write_count|dd_cpu_last|wall_last|mutex).(d+)s*$/) {
$sedderybody .= " s/$1.$2/__XSA55MANGLED__$1.$./g;n";
}
}
$sedderybody .= "}n1;n";
eval $sedderybody or die $@;
foreach (@lines) {
seddery();
print or die $!;
}
-8<-
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.58]
- [PATCH 05/21] libelf/xc_dom_load_elf_symtab: Do not use "syms" uninitia
lised
xc_dom_load_elf_symtab (with load==0) calls elf_round_up, but it
mistakenly used the uninitialised variable "syms" when calculating
dom->bsd_symtab_start. This should be a reference to "elf".
This change might have the effect of rounding the value differently.
Previously if the uninitialised value (a single byte on the stack) was
ELFCLASS64 (ie, 2), the alignment would be to 8 bytes, otherwise to 4.
However, the value is calculated from dom->kernel_seg.vend so this
could only make a difference if that value wasn't already aligned to 8
bytes.
This is part of the fix to a security issue, XSA-55.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.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 16902314]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.57]
- [PATCH 04/21] libelf: abolish elf_sval and elf_access_signed
These are not used anywhere.
This is part of the fix to a security issue, XSA-55.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.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 16902314]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.56]
- [PATCH 03/21] libxc: Fix range checking in xc_dom_pfn_to_ptr etc.
* Ensure that xc_dom_pfn_to_ptr (when called with count==0) does not
return a previously-allocated block which is entirely before the
requested pfn (!)
* Provide a version of xc_dom_pfn_to_ptr, xc_dom_pfn_to_ptr_retcount,
which provides the length of the mapped region via an out parameter.
* Change xc_dom_vaddr_to_ptr to always provide the length of the
mapped region and change the call site in xc_dom_binloader.c to
check it. The call site in xc_dom_load_elf_symtab will be corrected
in a forthcoming patch, and for now ignores the returned length.
This is part of the fix to a security issue, XSA-55.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
v5: This patch is new in v5 of the series.
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.55]
- [PATCH 02/21] libxc: introduce xc_dom_seg_to_ptr_pages
Provide a version of xc_dom_seg_to_ptr which returns the number of
guest pages it has actually mapped. This is useful for callers who
want to do range checking; we will use this later in this series.
This is part of the fix to a security issue, XSA-55.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.54]
- [PATCH 01/21] libelf: abolish libelf-relocate.c
This file is not actually used. It's not built in Xen's instance of
libelf; in libxc's it's built but nothing in it is called. Do not
compile it in libxc, and delete it.
This reduces the amount of work we need to do in forthcoming patches
to libelf (particularly since as libelf-relocate.c is not used it is
probably full of bugs).
This is part of the fix to a security issue, XSA-55.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.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 16903001]
{CVE-2013-2194,CVE-2013-2195,CVE-2013-2196}
[4.1.3-25.el5.53]
- Update specfile to generate debuginfo rpm
[4.1.3-25.el5.52]
- x86: fix page refcount handling in page table pin error path
In the original patch 7 of the series addressing XSA-45 I mistakenly
took the addition of the call to get_page_light() in alloc_page_type()
to cover two decrements that would happen: One for the PGT_partial bit
that is getting set along with the call, and the other for the page
reference the caller hold (and would be dropping on its error path).
But of course the additional page reference is tied to the PGT_partial
bit, and hence any caller of a function that may leave
->arch.old_guest_table non-NULL for error cleanup purposes has to make
sure a respective page reference gets retained.
Similar issues were then also spotted elsewhere: In effect all callers
of get_page_type_preemptible() need to deal with errors in similar
ways. To make sure error handling can work this way without leaking
page references, a respective assertion gets added to that function.
This is CVE-2013-1432 / XSA-58.
Reported-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Tested-by: Andrew Cooper <andrew.cooper3 at citrix.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 16949936]
[4.1.3-25.el5.51]
- libxl: Restrict permissions on PV console device xenstore nodes
This is CVE-2013-2211 / XSA-57
Signed-off-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 16920607]
{CVE-2013-2211}
[4.1.3-25.el5.50]
- Revert "[PATCH 01/14] libelf: abolish libelf-relocate.c"
xen.org patches for XSA-55 cause regressions
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16902314]
[4.1.3-25.el5.49]
- Revert "[PATCH 02/14] libxc: introduce xc_dom_seg_to_ptr_pages"
xen.org patches for XSA-55 cause regressions
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16902314]
[4.1.3-25.el5.48]
- Revert "[PATCH 03/14] libelf: abolish elf_sval and elf_access_signed"
xen.org patches for XSA-55 cause regressions
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16902314]
[4.1.3-25.el5.47]
- Revert "[PATCH 04/14] libelf/xc_dom_load_elf_symtab: Do not use "syms"
uninitialised"
xen.org patches for XSA-55 cause regressions
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16902314]
[4.1.3-25.el5.46]
- Revert "[PATCH 05/14] libelf: introduce macros for memory access and
pointer handling"
xen.org patches for XSA-55 cause regressions
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16902314]
[4.1.3-25.el5.45]
- Revert "[PATCH 06/14] tools/xcutils/readnotes: adjust
print_l1_mfn_valid_note"
xen.org patches for XSA-55 cause regressions
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16902314]
[4.1.3-25.el5.44]
- Revert "[PATCH 07/14] libelf: check nul-terminated strings properly"
xen.org patches for XSA-55 cause regressions
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16902314]
[4.1.3-25.el5.43]
- Revert "[PATCH 08/14] libelf: check all pointer accesses"
xen.org patches for XSA-55 cause regressions
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16902314]
[4.1.3-25.el5.42]
- Revert "[PATCH 09/14] libelf: Check pointer references in
elf_is_elfbinary"
xen.org patches for XSA-55 cause regressions
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16902314]
[4.1.3-25.el5.41]
- Revert "[PATCH 10/14] libelf: Make all callers call elf_check_broken"
xen.org patches for XSA-55 cause regressions
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16902314]
[4.1.3-25.el5.40]
- Revert "[PATCH 11/14] libelf: use C99 bool for booleans"
xen.org patches for XSA-55 cause regressions
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16902314]
[4.1.3-25.el5.39]
- Revert "[PATCH 12/14] libelf: use only unsigned integers"
xen.org patches for XSA-55 cause regressions
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16902314]
[4.1.3-25.el5.38]
- Revert "[PATCH 13/14] libelf: check loops for running away"
xen.org patches for XSA-55 cause regressions
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16902314]
[4.1.3-25.el5.37]
- Revert "[PATCH 14/14] libelf: abolish obsolete macros"
xen.org patches for XSA-55 cause regressions
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16902314]
[4.1.3-25.el5.36]
- [PATCH 14/14] libelf: abolish obsolete macros
Abolish ELF_PTRVAL_[CONST_]{CHAR,VOID}; change uses to elf_ptrval.
Abolish ELF_HANDLE_DECL_NONCONST; change uses to ELF_HANDLE_DECL.
Abolish ELF_OBSOLETE_VOIDP_CAST; simply remove all uses.
No functional change. (Verified by diffing assembler output.)
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
v2: New patch.
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
[4.1.3-25.el5.35]
- [PATCH 13/14] libelf: check loops for running away
Ensure that libelf does not have any loops which can run away
indefinitely even if the input is bogus. (Grepped for bfor, bwhile
and bgoto in libelf and xc_dom_*loader*.c.)
Changes needed:
* elf_note_next uses the note's unchecked alleged length, which might
wrap round. If it does, return ELF_MAX_PTRVAL (0xfff..fff) instead,
which will be beyond the end of the section and so terminate the
caller's loop.
* In various loops over section and program headers, check that the
calculated header pointer is still within the image, and quit the
loop if it isn't.
We have not changed loops which might, in principle, iterate over the
whole image - even if they might do so one byte at a time with a
nontrivial access check function in the middle.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
v3: Fix a whitespace error.
v2: BUGFIX: elf_shdr_by_name, elf_note_next: Reject new <= old, not
just <.
elf_shdr_by_name: Change order of checks to be a bit clearer.
elf_load_bsdsyms: shdr loop check, improve chance of brokenness
detection.
Style fixes.
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
[4.1.3-25.el5.34]
- [PATCH 12/14] libelf: use only unsigned integers
Signed integers have undesirable undefined behaviours on overflow.
Malicious compilers can turn apparently-correct code into code with
security vulnerabilities etc.
So use only unsigned integers. Exceptions are booleans (which we have
already changed) and error codes.
We _do_ change all the chars which aren't fixed constants from our own
text segment, but not the char*s. This is because it is safe to
access an arbitrary byte through a char*, but not necessarily safe to
convert an arbitrary value to a char.
As a consequence we need to compile libelf with -Wno-pointer-sign.
It is OK to change all the signed integers to unsigned because all the
inequalities in libelf are in contexts where we don't "expect"
negative numbers.
In libelf-dominfo.c:elf_xen_parse we rename a variable "rc" to
"more_notes" as it actually contains a note count derived from the
input image. The "error" return value from elf_xen_parse_notes is
changed from -1 to ~0U.
grepping shows only one occurrence of "PRId" or "%d" or "%ld" in
libelf and xc_dom_elfloader.c (a "%d" which becomes "%u").
For those concerned about unintentional functional changes, the
following rune produces a version of the patch which is much smaller
and eliminates only non-functional changes:
GIT_EXTERNAL_DIFF=.../unsigned-differ git-diff <before>..<after>
where <before> and <after> are git refs for the code before and after
this patch, and unsigned-differ is this shell script:
set -e
seddery () {
perl -pe 's/b(?:elf_errorstatus|elf_negerrnoval)b/int/g'
}
path="$1"
in="$2"
out="$5"
set +e
diff -pu --label "$path~" <(seddery <"$in") --label "$path" <(seddery
<"$out
")
rc=$?
set -e
if [ $rc = 1 ]; then rc=0; fi
exit $rc
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
v3: Changes to booleans split off into separate patch.
v2: BUGFIX: Eliminate conversion to int of return from
elf_xen_parse_notes.
BUGFIX: Fix the one printf format thing which needs changing.
Remove irrelevant change to constify note_desc.name in libelf-dominfo.c.
In xc_dom_load_elf_symtab change one sizeof(int) to sizeof(unsigned).
Do not change type of 2nd argument to memset.
Provide seddery for easier review.
Style fix.
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
[4.1.3-25.el5.33]
- [PATCH 11/14] libelf: use C99 bool for booleans
We want to remove uses of "int" because signed integers have
undesirable undefined behaviours on overflow. Malicious compilers can
turn apparently-correct code into code with security vulnerabilities
etc.
In this patch we change all the booleans in libelf to C99 bool,
from <stdbool.h>.
For the one visible libelf boolean in libxc's public interface we
retain the use of int to avoid changing the ABI; libxc converts it to
a bool for consumption by libelf.
It is OK to change all values only ever used as booleans to _Bool
(bool) because conversion from any scalar type to a _Bool works the
same as the boolean test in if() or ?: and is always defined (C99
6.3.1.2). But we do need to check that all these variables really are
only ever used that way. (It is theoretically possible that the old
code truncated some 64-bit values to 32-bit ints which might become
zero depending on the value, which would mean a behavioural change in
this patch, but it seems implausible that treating 0x????????00000000
as false could have been intended.)
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
v3: Use <stdbool.h>'s bool (or _Bool) instead of defining elf_bool.
Split this into a separate patch.
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
[4.1.3-25.el5.32]
- [PATCH 10/14] libelf: Make all callers call elf_check_broken
This arranges that if the new pointer reference error checking
tripped, we actually get a message about it. In this patch these
messages do not change the actual return values from the various
functions: so pointer reference errors do not prevent loading. This
is for fear that some existing kernels might cause the code to make
these wild references, which would then break, which is not a good
thing in a security patch.
In xen/arch/x86/domain_build.c we have to introduce an "out" label and
change all of the "return rc" beyond the relevant point into "goto
out".
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
v3.1:
Add error check to xc_dom_parse_elf_kernel.
Move check in xc_hvm_build_x86.c:setup_guest to right place.
v2 Acked-by: Ian Campbell <ian.campbell at citrix.com>
v2 Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
v2: Style fixes.
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
[4.1.3-25.el5.31]
- [PATCH 09/14] libelf: Check pointer references in elf_is_elfbinary
elf_is_elfbinary didn't take a length parameter and could potentially
access out of range when provided with a very short image.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
[4.1.3-25.el5.30]
- [PATCH 08/14] libelf: check all pointer accesses
We change the ELF_PTRVAL and ELF_HANDLE types and associated macros:
* PTRVAL becomes a uintptr_t, for which we provide a typedef
elf_ptrval. This means no arithmetic done on it can overflow so
the compiler cannot do any malicious invalid pointer arithmetic
"optimisations". It also means that any places where we
dereference one of these pointers without using the appropriate
macros or functions become a compilation error.
So we can be sure that we won't miss any memory accesses.
All the PTRVAL variables were previously void* or char*, so
the actual address calculations are unchanged.
* ELF_HANDLE becomes a union, one half of which keeps the pointer
value and the other half of which is just there to record the
type.
The new type is not a pointer type so there can be no address
calculations on it whose meaning would change. Every assignment or
access has to go through one of our macros.
* The distinction between const and non-const pointers and char*s
and void*s in libelf goes away. This was not important (and
anyway libelf tended to cast away const in various places).
* The fields elf->image and elf->dest are renamed. That proves
that we haven't missed any unchecked uses of these actual
pointer values.
* The caller may fill in elf->caller_xdest_base and _size to
specify another range of memory which is safe for libelf to
access, besides the input and output images.
* When accesses fail due to being out of range, we mark the elf
"broken". This will be checked and used for diagnostics in
a following patch.
We do not check for write accesses to the input image. This is
because libelf actually does this in a number of places. So we
simply permit that.
* Each caller of libelf which used to set dest now sets
dest_base and dest_size.
* In xc_dom_load_elf_symtab we provide a new actual-pointer
value hdr_ptr which we get from mapping the guest's kernel
area and use (checking carefully) as the caller_xdest area.
* The STAR(h) macro in libelf-dominfo.c now uses elf_access_unsigned.
* elf-init uses the new elf_uval_3264 accessor to access the 32-bit
fields, rather than an unchecked field access (ie, unchecked
pointer access).
* elf_uval has been reworked to use elf_uval_3264. Both of these
macros are essentially new in this patch (although they are derived
from the old elf_uval) and need careful review.
* ELF_ADVANCE_DEST is now safe in the sense that you can use it to
chop parts off the front of the dest area but if you chop more than
is available, the dest area is simply set to be empty, preventing
future accesses.
* We introduce some #defines for memcpy, memset, memmove and strcpy:
- We provide elf_memcpy_safe and elf_memset_safe which take
PTRVALs and do checking on the supplied pointers.
- Users inside libelf must all be changed to either
elf_mem*_unchecked (which are just like mem*), or
elf_mem*_safe (which take PTRVALs) and are checked. Any
unchanged call sites become compilation errors.
* We do _not_ at this time fix elf_access_unsigned so that it doesn't
make unaligned accesses. We hope that unaligned accesses are OK on
every supported architecture. But it does check the supplied
pointer for validity.
Additional changes in 4.1 backport:
* ELF_PRPTRVAL needs to be defined oddly on 4.1 and earlier because
Xen's headers provide no definitions of uintptr_t or PRIuPTR.
* To support 32-bit builds, ELF_UNSAFE_PTR contains an explicit cast
to uintptr_t in case the argument isn't the same size. On 32-bit
some of the values converted to pointers are 64-bit.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
v3.1:
Introduce a change to elf_store_field to undo the effects of
the v3.1 change to the previous patch (the definition there
is not compatible with the new types).
v3: Fix a whitespace error.
v2 Acked-by: Ian Campbell <ian.campbell at citrix.com>
v2: BUGFIX: elf_strval: Fix loop termination condition to actually work.
BUGFIX: elf_strval: Fix return value to not always be totally wild.
BUGFIX: xc_dom_load_elf_symtab: do proper check for small header size.
xc_dom_load_elf_symtab: narrow scope of `hdr_ptr'.
xc_dom_load_elf_symtab: split out uninit'd symtab.class ref fix.
More comments on the lifetime/validity of elf-> dest ptrs etc.
libelf.h: write "obsolete" out in full
libelf.h: rename "dontuse" to "typeonly" and add doc comment
elf_ptrval_in_range: Document trustedness of arguments.
Style and commit message fixes.
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
[4.1.3-25.el5.29]
- [PATCH 07/14] libelf: check nul-terminated strings properly
It is not safe to simply take pointers into the ELF and use them as C
pointers. They might not be properly nul-terminated (and the pointers
might be wild).
So we are going to introduce a new function elf_strval for safely
getting strings. This will check that the addresses are in range and
that there is a proper nul-terminated string. Of course it might
discover that there isn't. In that case, it will be made to fail.
This means that elf_note_name might fail, too.
For the benefit of call sites which are just going to pass the value
to a printf-like function, we provide elf_strfmt which returns
"(invalid)" on failure rather than NULL.
In this patch we introduce dummy definitions of these functions. We
introduce calls to elf_strval and elf_strfmt everywhere, and update
all the call sites with appropriate error checking.
There is not yet any semantic change, since before this patch all the
places where we introduce elf_strval dereferenced the value anyway, so
it mustn't have been NULL.
In future patches, when elf_strval is made able return NULL, when it
does so it will mark the elf "broken" so that an appropriate
diagnostic can be printed.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
v2: Fix coding style, in one "if" statement.
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
[4.1.3-25.el5.28]
- [PATCH 06/14] tools/xcutils/readnotes: adjust print_l1_mfn_valid_note
Use the new PTRVAL macros and elf_access_unsigned in
print_l1_mfn_valid_note.
No functional change unless the input is wrong, or we are reading a
file for a different endianness.
Separated out from the previous patch because this change does produce
a difference in the generated code.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
v2: Split out into its own patch.
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
[4.1.3-25.el5.27]
- [PATCH 05/14] libelf: introduce macros for memory access and pointer
handling
We introduce a collection of macros which abstract away all the
pointer arithmetic and dereferences used for accessing the input ELF
and the output area(s). We use the new macros everywhere.
For now, these macros are semantically identical to the code they
replace, so this patch has no functional change.
elf_is_elfbinary is an exception: since it doesn't take an elf*, we
need to handle it differently. In a future patch we will change it to
take, and check, a length parameter. For now we just mark it with a
fixme.
Differences in the 4.2 backport: ELF_OBSOLETE_VOIDP_CAST includes a
cast to uintptr_t to suppress warnings about conversions between
integers and differently-sized pointers. In elf_load_binary we
include one cast to ELF_PTRVAL_VOID to narrow a 64-bit value to
32-bit on x86_32.
Differences in the 4.1 backport: We need to provide our own
elf_uintptr_t since Xen doesn't. We see an additional difference in
our verification diff. The "function-filter" needs to massage
additional symbol names.
That this patch has no functional change can be verified as follows:
0. Copy the scripts "comparison-generate" and "function-filter"
out of this commit message.
1. Check out the tree before this patch.
2. Run the script ../comparison-generate .... ../before
3. Check out the tree after this patch.
4. Run the script ../comparison-generate .... ../after
5. diff --exclude=*.[soi] -ruN before/ after/ |less
Expect these differences:
* stubdom/zlib-x86_64/ztest*.s2
The filename of this test file apparently contains the pid.
* stubdom/grub/kexec.s2:
Large differences following ".section .debug_info" (which
the 4.1 build system erroneously fails to suppress).
* tools/libxc/xc_dom_x86.s2:
Two trivial code generation differences with no semantic
import.
* xen/common/version.s2
The xen build timestamp appears in two diff hunks.
Verification that this is all that's needed:
In a completely built xen.git,
find * -name .*.d -type f | xargs grep -l libelf.h
Expect results in:
xen/arch/x86: Checked above.
tools/libxc: Checked above.
tools/xcutils/readnotes: Checked above.
tools/xenstore: Checked above.
xen/common/libelf:
This is the build for the hypervisor; checked in B above.
stubdom:
We have one stubdom which reads ELFs using our libelf,
pvgrub, which is checked above.
I have not done this verification for ARM.
-8<- comparison-generate -8<-
set -ex
test $# = 3 || need-exactly-three-arguments
our_config=$1
build_rune_prefix=$2
result_dir=$3
git-clean -x -d -f
cp "$our_config" .
cat <<END >>.config
debug_symbols=n
CFLAGS += -save-temps
END
perl -i~ -pe 's/ -g / -g0 / if m/^CFLAGS/' xen/Rules.mk
if [ -f ./configure ]; then
$build_rune_prefix ./configure
fi
$build_rune_prefix make -C xen
$build_rune_prefix make -C tools/include
$build_rune_prefix make -C stubdom grub
$build_rune_prefix make -C tools/libxc
$build_rune_prefix make -C tools/xenstore
$build_rune_prefix make -C tools/xcutils
rm -rf "$result_dir"
mkdir "$result_dir"
set +x
for f in `find xen tools stubdom -name *.[soi]`; do
mkdir -p "$result_dir"/`dirname $f`
cp $f "$result_dir"/${f}
case $f in
*.s)
../function-filter <$f >"$result_dir"/${f}2
;;
esac
done
echo ok.
-8<-
-8<- function-filter -8<-
use strict;
our @lines;
my $sedderybody = "sub seddery () {n";
while (<>) {
push @lines, $_;
if
(m/^(__FUNCTION__|__func__|_ctx|note_desc|types|last_order|memflags|mutex|dd_cpu_last|write_count|wall_last|__PRETTY_FUNCTION__).(d+):/
||
m/^s+.locals+(_ctx|write_count|dd_cpu_last|wall_last|mutex).(d+)s*$/) {
$sedderybody .= " s/\\b$1.$2\\b/__XSA55MANGLED__$1.$./g;n";
}
}
$sedderybody .= "}n1;n";
eval $sedderybody or die $@;
foreach (@lines) {
seddery();
print or die $!;
}
-8<-
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
v2: Use Xen style for multi-line comments.
Postpone changes to readnotes.c:print_l1_mfn_valid_note.
Much improved verification instructions with new script.
Fixed commit message subject.
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
[4.1.3-25.el5.26]
- [PATCH 04/14] libelf/xc_dom_load_elf_symtab: Do not use "syms"
uninitialised
xc_dom_load_elf_symtab (with load==0) calls elf_round_up, but it
mistakenly used the uninitialised variable "syms" when calculating
dom->bsd_symtab_start. This should be a reference to "elf".
This change might have the effect of rounding the value differently.
Previously if the uninitialised value (a single byte on the stack) was
ELFCLASS64 (ie, 2), the alignment would be to 8 bytes, otherwise to 4.
However, the value is calculated from dom->kernel_seg.vend so this
could only make a difference if that value wasn't already aligned to 8
bytes.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
v2: Split this change into its own patch for proper review.
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
[4.1.3-25.el5.25]
- [PATCH 03/14] libelf: abolish elf_sval and elf_access_signed
These are not used anywhere.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.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 16902314]
[4.1.3-25.el5.24]
- [PATCH 02/14] libxc: introduce xc_dom_seg_to_ptr_pages
Provide a version of xc_dom_seg_to_ptr which returns the number of
guest pages it has actually mapped. This is useful for callers who
want to do range checking; we will use this later in this series.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16902314]
[4.1.3-25.el5.23]
- [PATCH 01/14] libelf: abolish libelf-relocate.c
This file is not actually used. It's not built in Xen's instance of
libelf; in libxc's it's built but nothing in it is called. Do not
compile it in libxc, and delete it.
This reduces the amount of work we need to do in forthcoming patches
to libelf (particularly since as libelf-relocate.c is not used it is
probably full of bugs).
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 16902314]
[4.1.3-25.el5.22]
- x86/xsave: properly check guest input to XSETBV
Other than the HVM emulation path, the PV case so far failed to check
that YMM state requires SSE state to be enabled, allowing for a #GP to
occur upon passing the inputs to XSETBV inside the hypervisor.
This is CVE-2013-2078 / XSA-54.
Signed-off-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 16822750]
{CVE-2013-2078}
[4.1.3-25.el5.21]
- x86/xsave: recover from faults on XRSTOR
Just like FXRSTOR, XRSTOR can raise #GP if bad content is being passed
to it in the memory block (i.e. aspects not under the control of the
hypervisor, other than e.g. proper alignment of the block).
Also correct the comment explaining why FXRSTOR needs exception
recovery code to not wrongly state that this can only be a result of
the control tools passing a bad image.
This is CVE-2013-2077 / XSA-53.
Signed-off-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 16822695]
{CVE-2013-2077}
[4.1.3-25.el5.20]
- x86/xsave: fix information leak on AMD CPUs
Just like for FXSAVE/FXRSTOR, XSAVE/XRSTOR also don't save/restore the
last instruction and operand pointers as well as the last opcode if
there's no pending unmasked exception (see CVE-2006-1056 and commit
9747:4d667a139318).
While the FXSR solution sits in the save path, I prefer to have this in
the restore path because there the handling is simpler (namely in the
context of the pending changes to properly save the selector values for
32-bit guest code).
Also this is using FFREE instead of EMMS, as it doesn't seem unlikely
that in the future we may see CPUs with x87 and SSE/AVX but no MMX
support. The goal here anyway is just to avoid an FPU stack overflow.
I would have preferred to use FFREEP instead of FFREE (freeing two
stack slots at once), but AMD doesn't document that instruction.
This is CVE-2013-2076 / XSA-52.
Signed-off-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 16822596]
{CVE-2013-2076}
[4.1.3-25.el5.19]
- libxc: limit cpu values when setting vcpu affinity
When support for pinning more than 64 cpus was added, check for cpu
out-of-range values was removed. This can lead to subsequent
out-of-bounds cpumap array accesses in case the cpu number is higher
than the actual count.
This patch returns the check.
This is CVE-2013-2072 / XSA-56
Signed-off-by: Petr Matousek <pmatouse at redhat.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: Jerry Snitselaar <jerry.snitselaar at oracle.com> [bug
16801800] {CVE-2013-2072}
[4.1.3-25.el5.18]
- Disable bridge multicast_snooping, the Linux bridge can not forward
these packet to its ports,
and it is not needed.
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Backported-by: Joe Jin <joe.jin at oracle.com> [bug 16756876]
[4.1.3-25.el5.17]
- VT-d: don't permit SVT_NO_VERIFY entries for known device types
Only in cases where we don't know what to do we should leave the IRTE
blank (suppressing all validation), but we should always log a warning
in those cases (as being insecure).
This is CVE-2013-1952 / XSA-49.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: "Zhang, Xiantao" <xiantao.zhang at intel.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16714373]
{CVE-2013-1952}
[4.1.3-25.el5.16]
- x86: make page table handling error paths preemptible
... as they may take significant amounts of time.
This requires cloning the tweaked continuation logic from
do_mmuext_op() to do_mmu_update().
Note that in mod_l[34]_entry() a negative "preemptible" value gets
passed to put_page_from_l[34]e() now, telling the callee to store the
respective page in current->arch.old_guest_table (for a hypercall
continuation to pick up), rather than carrying out the put right away.
This is going to be made a little more explicit by a subsequent cleanup
patch.
This is part of CVE-2013-1918 / XSA-45.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-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 16713684]
{CVE-2013-1918}
[4.1.3-25.el5.15]
- x86: make page table unpinning preemptible
... as it may take significant amounts of time.
Since we can't re-invoke the operation in a second attempt, the
continuation logic must be slightly tweaked so that we make sure
do_mmuext_op() gets run one more time even when the preempted unpin
operation was the last one in a batch.
This is part of CVE-2013-1918 / XSA-45.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-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 16713684]
{CVE-2013-1918}
[4.1.3-25.el5.14]
- x86: make arch_set_info_guest() preemptible
.. as the root page table validation (and the dropping of an eventual
old one) can require meaningful amounts of time.
This is part of CVE-2013-1918 / XSA-45.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-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 16713684]
{CVE-2013-1918}
[4.1.3-25.el5.13]
- x86: make vcpu_reset() preemptible
... as dropping the old page tables may take significant amounts of
time.
This is part of CVE-2013-1918 / XSA-45.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-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 16713684]
{CVE-2013-1918}
[4.1.3-25.el5.12]
- x86: make MMUEXT_NEW_USER_BASEPTR preemptible
... as it may take significant amounts of time.
This is part of CVE-2013-1918 / XSA-45.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-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 16713684]
{CVE-2013-1918}
[4.1.3-25.el5.11]
- x86: make new_guest_cr3() preemptible
... as it may take significant amounts of time.
This is part of CVE-2013-1918 / XSA-45.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-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 16713684]
{CVE-2013-1918}
[4.1.3-25.el5.10]
- x86: make vcpu_destroy_pagetables() preemptible
... as it may take significant amounts of time.
The function, being moved to mm.c as the better home for it anyway, and
to avoid having to make a new helper function there non-static, is
given a "preemptible" parameter temporarily (until, in a subsequent
patch, its other caller is also being made capable of dealing with
preemption).
This is part of CVE-2013-1918 / XSA-45.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-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 16713684]
{CVE-2013-1918}
[4.1.3-25.el5.9]
- Fix rcu domain locking for transitive grants
When acquiring a transitive grant for copy then the owning domain
needs to be locked down as well as the granting domain. This was being
done, but the unlocking was not. The acquire code now stores the
struct domain * of the owning domain (rather than the domid) in the
active entry in the granting domain. The release code then does the
unlock on the owning domain. Note that I believe I also fixed a bug
where, for non-transitive grants the active entry contained a
reference to the acquiring domain rather than the granting
domain. From my reading of the code this would stop the release code
for transitive grants from terminating its recursion correctly.
Signed-off-by: Paul Durrant <paul.durrant at citrix.com>
Also, for non-transitive grants we now avoid incorrectly recursing
in __release_grant_for_copy.
This is CVE-2013-1964 / XSA-50.
Reported-by: Manuel Bouyer <bouyer at antioche.eu.org>
Tested-by: Manuel Bouyer <bouyer at antioche.eu.org>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16690498]
{CVE-2013-1964}
[4.1.3-25.el5.8]
- xen: increase default max grant frames from 32 to 64.
We advertise as being able to launch 32VIFs and 8 VBDs.
But currently the amount of frames that a guest uses is
based on this simple algebra:
So if we have 31VIFs we cannot have any more VBDs nor any
more VIFs. By increasing the value to 64 we have some extra
headroom _and_ we can have at least 8VBDs (or more).
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Backported-by: Joe Jin <joe.jin at oracle.com> [bug 16686562]
[4.1.3-25.el5.7]
- Current Xend allowing multiple call destroy() for the same domain,
this lead
multiple hard resets(FLR) for pci pass-through, and some controller might
failed.
In our test, we pass through 2 LSI HAB controllers to the PVHVM
guest, after
guest brought up, call xm-destroy twice, the adapters's BIOS will
hung, and
we had to reboot the server to recovery it.
BTW: I had send this patch to Xen maillist, but developer said Xend will
obsolete and would not review and merge the fix.
Signed-off-by: Joe Jin <joe.jin at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Reviewed-by: Adnan Misherfi <adnan.misherfi at oracle.com> [bug 16524986]
[4.1.3-25.el5.6]
- defer event channel bucket pointer store until after XSM checks
Otherwise a dangling pointer can be left, which would cause subsequent
memory corruption as soon as the space got re-allocated for some other
purpose.
This is CVE-2013-1920 / XSA-47.
Reported-by: Wei Liu <wei.liu2 at citrix.com>
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 16607361]
[4.1.3-25.el5.5]
- x86: fix various issues with handling guest IRQs
- properly revoke IRQ access in map_domain_pirq() error path
- don't permit replacing an in use IRQ
- don't accept inputs in the GSI range for MAP_PIRQ_TYPE_MSI
- track IRQ access permission in host IRQ terms, not guest IRQ ones
(and with that, also disallow Dom0 access to IRQ0)
This is CVE-2013-1919 / XSA-46.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16607326]
[4.1.3-25.el5.4]
- x86: clear EFLAGS.NT in SYSENTER entry path
... as it causes problems if we happen to exit back via IRET: In the
course of trying to handle the fault, the hypervisor creates a stack
frame by hand, and uses PUSHFQ to set the respective EFLAGS field, but
expects to be able to IRET through that stack frame to the second
portion of the fixup code (which causes a #GP due to the stored EFLAGS
having NT set).
And even if this worked (e.g if we cleared NT in that path), it would
then (through the fail safe callback) cause a #GP in the guest with the
SYSENTER handler's first instruction as the source, which in turn would
allow guest user mode code to crash the guest kernel.
Inject a #GP on the fake (NULL) address of the SYSENTER instruction
instead, just like in the case where the guest kernel didn't register
a corresponding entry point.
On 32-bit we also need to make sure we clear SYSENTER_CS for all CPUs
(neither #RESET nor #INIT guarantee this).
This is CVE-2013-1917 / XSA-44.
Reported-by: Andrew Cooper <andrew.cooper3 at citirx.com>
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Tested-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16607271]
{CVE-2013-1917}
[4.1.3-25.el5.3]
- oxenstored incorrect handling of certain Xenbus ring states
Xen Security Advisory 38 (CVE-2013-0215)
Patch xsa38.patch
The oxenstored daemon (the ocaml version of the xenstore daemon) does
not correctly handle unusual or malicious contents in the xenstore
ring. A malicious guest can exploit this to cause oxenstored to read
past the end of the ring (and very likely crash) or to allocate large
amounts of RAM.
Signed-off-by Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16243250]
{CVE-2013-0215}
[4.1.3-25.el5.2]
- ACPI: acpi_table_parse() should return handler's error code
Currently, the error code returned by acpi_table_parse()'s handler
is ignored. This patch will propagate handler's return value to
acpi_table_parse()'s caller.
AMD,IOMMU: Clean up old entries in remapping tables when creating new
interrupt mapping.
When changing the affinity of an IRQ associated with a passed
through PCI device, clear previous mapping.
In addition, because some BIOSes may incorrectly program IVRS
entries for IOAPIC try to check for entry's consistency. Specifically,
if conflicting entries are found disable IOMMU if per-device
remapping table is used. If entries refer to bogus IOAPIC IDs
disable IOMMU unconditionally
AMD,IOMMU: Disable IOMMU if SATA Combined mode is on
AMD's SP5100 chipset can be placed into SATA Combined mode
that may cause prevent dom0 from booting when IOMMU is
enabled and per-device interrupt remapping table is used.
While SP5100 erratum 28 requires BIOSes to disable this mode,
some may still use it.
This patch checks whether this mode is on and, if per-device
table is in use, disables IOMMU.
AMD,IOMMU: Make per-device interrupt remapping table default
Using global interrupt remapping table may be insecure, as
described by XSA-36. This patch makes per-device mode default.
This is XSA-36 / CVE-2013-0153.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at amd.com>
Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16273845]
{CVE-2013-0153}
[4.1.3-25.el5.1]
- Xen Security Advisory CVE-2012-5634 / XSA-33 (v3)
VT-d interrupt remapping source validation flaw
UPDATES IN VERSION 3
====================
The patch supplied for Xen 4.1 (xsa33-4.1.patch) contained a build
error. A corrected patch is attached. The fix is also now available in
http://xenbits.xen.org/hg/xen-4.1-testing.hg as changeset
23441:2a91623a5807
ISSUE DESCRIPTION
=================
When passing a device which is behind a legacy PCI Bridge through to
a guest Xen incorrectly configures the VT-d hardware. This could allow
incorrect interrupts to be injected to other guests which also have
passthrough devices.
In a typical Xen system many devices are owned by domain 0 or driver
domains, leaving them vulnerable to such an attack. Such a DoS is
likely to have an impact on other guests running in the system.
IMPACT
======
A malicious domain, given access to a device which is behind a legacy
PCI bridge, can mount a denial of service attack affecting the whole
system.
VULNERABLE SYSTEMS
==================
Xen version 4.0 onwards is vulnerable.
Only systems using Intel VT-d for PCI passthrough are vulnerable.
Any domain which is given access to a PCI device that is behind a
legacy PCI bridge can take advantage of this vulnerability.
Domains which are given access to PCIe devices only are not able to
take advantage of this vulnerability.
MITIGATION
==========
This issue can be avoided by not assigning PCI devices which are
behind a legacy PCI bridge to untrusted guests.
Patch:
VT-d: fix interrupt remapping source validation for devices behind
legacy bridges
Using SVT_VERIFY_BUS here doesn't make sense; native Linux also
uses SVT_VERIFY_SID_SQ here instead.
This is XSA-33 / CVE-2012-5634.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
16023718]
[4.1.3-25]
- Xen Security Advisory CVE-2012-5514 / XSA-30 (v4).
aka. Broken error handling in guest_physmap_mark_populate_on_demand()
The original checkin was using v1, which did not have the
extra check for priviliged domains and the less verbose printk.
This patch updates the xsa-30 to v4.
ISSUE DESCRIPTION
=================
guest_physmap_mark_populate_on_demand(), before carrying out its actual
operation, checks that the subject GFNs are not in use. If that check
fails,
the code prints a message and bypasses the gfn_unlock() matching the
gfn_lock() carried out before entering the loop.
Further, the function is exposed to the use of guests on their own
behalf. While we believe that this does not cause any further issues,
we have not conducted a thorough enough review to be sure. Rather, it
should be exposed only to privileged domains.
IMPACT
======
A malicious guest administrator can cause Xen to hang.
Patch:
xen: fix error handling of guest_physmap_mark_populate_on_demand()
The only user of the "out" label bypasses a necessary unlock, thus
enabling the caller to lock up Xen.
Also, the function was never meant to be called by a guest for itself,
so rather than inspecting the code paths in depth for potential other
problems this might cause, and adjusting e.g. the non-guest printk()
in the above error path, just disallow the guest access to it.
Finally, the printk() (considering its potential of spamming the log,
the more that it's not using XENLOG_GUEST), is being converted to
P2M_DEBUG(), as debugging is what it apparently was added for in the
first place.
This is XSA-30 / CVE-2012-5514.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Acked-by: George Dunlap <george.dunlap at eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson at eu.citrix.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
15953919]
[4.1.3-24]
- Disable netfilter on bridges. [bug 15871028]
[4.1.3-23]
- Add vif-switch to the make file so that it is put in the xen scripts
directory. [bug 15886237]
[4.1.3-22]
- Xen Security Advisory CVE-2012-5515 / XSA-31
Several memory hypercall operations allow invalid extent order values
*** EMBARGOED UNTIL Thursday 2012-11-29 12:00:00 UTC ***
ISSUE DESCRIPTION
=================
Allowing arbitrary extent_order input values for
XENMEM_decrease_reservation,
XENMEM_populate_physmap, and XENMEM_exchange can cause arbitrarily
long time
being spent in loops without allowing vital other code to get a chance to
execute. This may also cause inconsistent state resulting at the
completion
of these hypercalls.
IMPACT
======
A malicious guest administrator can cause Xen to hang.
VULNERABLE SYSTEMS
==================
All Xen versions are vulnerable. However, older versions (not supporting
Populate-on-Demand, i.e. before 3.4) may only be theoretically affected.
MITIGATION
==========
Running only trusted guest kernels will avoid this vulnerability.
Patch:
memop: limit guest specified extent order
Allowing unbounded order values here causes almost unbounded loops
and/or partially incomplete requests, particularly in PoD code.
The added range checks in populate_physmap(), decrease_reservation(),
and the "in" one in memory_exchange() architecturally all could use
PADDR_BITS - PAGE_SHIFT, and are being artificially constrained to
MAX_ORDER.
This is XSA-31 / CVE-2012-5515.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Tim Deegan <tim at xen.org>
Acked-by: Ian Jackson <ian.jackson at eu.citrix.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.3-21]
- Xen Security Advisory CVE-2012-5514 / XSA-30
Missing unlock in guest_physmap_mark_populate_on_demand()
*** EMBARGOED UNTIL Thursday 2012-11-29 12:00:00 UTC ***
ISSUE DESCRIPTION
=================
guest_physmap_mark_populate_on_demand(), before carrying out its actual
operation, checks that the subject GFNs are not in use. If that check
fails,
the code bypasses the gfn_unlock() matching the gfn_lock() carried out
before entering the loop.
IMPACT
======
A malicious supervising domain (e.g. stubdom) can cause Xen to hang.
VULNERABLE SYSTEMS
==================
All Xen version from 3.4 on are vulnerable.
The vulnerability is only exposed by HVM guests.
MITIGATION
==========
Running only PV guests, or ensuring that HVM guest supervision is
done only
by trusted code, will avoid this vulnerability.
xen: fix error path of guest_physmap_mark_populate_on_demand()
The only user of the "out" label bypasses a necessary unlock, thus
enabling the caller to lock up Xen.
This is XSA-30 / CVE-2012-5514.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Acked-by: Ian Jackson <ian.jackson at eu.citrix.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.3-20]
- Xen Security Advisory CVE-2012-5513 / XSA-29
XENMEM_exchange may overwrite hypervisor memory
*** EMBARGOED UNTIL Thursday 2012-11-29 12:00:00 UTC ***
ISSUE DESCRIPTION
=================
The handler for XENMEM_exchange accesses guest memory without range
checking
the guest provided addresses, thus allowing these accesses to include the
hypervisor reserved range.
IMPACT
======
A malicious guest administrator can cause Xen to crash. If the out
of address
space bounds access does not lead to a crash, a carefully crafted
privilege
escalation cannot be excluded, even though the guest doesn't itself
control
the values written.
VULNERABLE SYSTEMS
==================
All Xen versions are vulnerable.
The vulnerability is only exposed to PV guests.
MITIGATION
==========
Running only HVM guests, or ensuring that PV guests only use trusted
kernels,
will avoid this vulnerability.
Patch:
xen: add missing guest address range checks to XENMEM_exchange handlers
Ever since its existence (3.0.3 iirc) the handler for this has been
using non address range checking guest memory accessors (i.e.
the ones prefixed with two underscores) without first range
checking the accessed space (via guest_handle_okay()), allowing
a guest to access and overwrite hypervisor memory.
This is XSA-29 / CVE-2012-5513.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Acked-by: Ian Jackson <ian.jackson at eu.citrix.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.3-19]
- Xen Security Advisory CVE-2012-5512 / XSA-28
HVMOP_get_mem_access crash / HVMOP_set_mem_access information leak
*** EMBARGOED UNTIL Thursday 2012-11-29 12:00:00 UTC ***
ISSUE DESCRIPTION
=================
The HVMOP_set_mem_access operation handler uses an input as an array
index
before range checking it.
IMPACT
======
A malicious guest administrator can cause Xen to crash. If the out
of array
bounds access does not crash, the arbitrary value read will be used
if the
caller reads back the default access through the HVMOP_get_mem_access
operation, thus causing an information leak. The caller cannot, however,
directly control the address from which to read, since the value read
in the
first step will be used as an array index again in the second step.
VULNERABLE SYSTEMS
==================
Only Xen version 4.1 is vulnerable.
The vulnerability is only exposed to HVM guests.
MITIGATION
==========
Running only PV guests, or ensuring that the controlling domain of HVM
guests (e.g. dom0 or stubdom) only uses trusted code, will avoid this
vulnerability.
Patch:
x86/HVM: range check xen_hvm_set_mem_access.hvmmem_access before use
Otherwise an out of bounds array access can happen if changing the
default access is being requested, which - if it doesn't crash Xen -
would subsequently allow reading arbitrary memory through
HVMOP_get_mem_access (again, unless that operation crashes Xen).
This is XSA-28 / CVE-2012-5512.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Tim Deegan <tim at xen.org>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.3-18]
- More efficient TLB-flush filtering in alloc_heap_pages().
Rather than per-cpu filtering for every page in a super-page
allocation, simply remember the most recent TLB timestamp across all
allocated pages, and filter on that, just once, at the end of the
function.
For large-CPU systems, doing 2MB allocations during domain creation,
this cuts down the domain creation time *massively*.
TODO: It may make sense to move the filtering out into some callers,
such as memory.c:populate_physmap() and
memory.c:increase_reservation(), so that the filtering can be moved
outside their loops, too.
Signed-off-by: Keir Fraser <keir at xen.org>
xen-unstable changeset: 26056:177fdda0be56
xen-unstable date: Mon Oct 15 15:38:11 UTC 2012 [bug 15885849]
[4.1.3-17]
- Xen Security Advisory CVE-2012-5511 / XSA-27
several HVM operations do not validate the range of their inputs
*** EMBARGOED UNTIL Thursday 2012-11-29 12:00:00 UTC ***
ISSUE DESCRIPTION
=================
Several HVM control operations do not check the size of their inputs
and can tie up a physical CPU for extended periods of time.
In addition dirty video RAM tracking involves clearing the bitmap
provided by the domain controlling the guest (e.g. dom0 or a
stubdom). If the size of that bitmap is overly large, an intermediate
variable on the hypervisor stack may overflow that stack.
IMPACT
======
A malicious guest administrator can cause Xen to become unresponsive
or to crash leading in either case to a Denial of Service.
VULNERABLE SYSTEMS
==================
All Xen versions from 3.4 onwards are vulnerable.
However Xen 4.2 and unstable are not vulnerable to the stack
overflow. Systems running either of these are not vulnerable to the
crash.
Version 3.4, 4.0 and 4.1 are vulnerable to both the stack overflow and
the physical CPU hang.
The vulnerability is only exposed to HVM guests.
MITIGATION
==========
Running only PV guests will avoid this vulnerability.
Patch:
hvm: Limit the size of large HVM op batches
Doing large p2m updates for HVMOP_track_dirty_vram without preemption
ties up the physical processor. Integrating preemption into the p2m
updates is hard so simply limit to 1GB which is sufficient for a 15000
* 15000 * 32bpp framebuffer.
For HVMOP_modified_memory and HVMOP_set_mem_type preemptible add the
necessary machinery to handle preemption.
This is CVE-2012-5511 / XSA-27.
Signed-off-by: Tim Deegan <tim at xen.org>
Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
Acked-by: Ian Jackson <ian.jackson at eu.citrix.com>
x86/paging: Don't allocate user-controlled amounts of stack memory.
This is XSA-27 / CVE-2012-5511.
Signed-off-by: Tim Deegan <tim at xen.org>
Acked-by: Jan Beulich <jbeulich at suse.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.3-16]
- Xen Security Advisory CVE-2012-5510 / XSA-26
Grant table version switch list corruption vulnerability
*** EMBARGOED UNTIL Thursday 2012-11-29 12:00:00 UTC ***
ISSUE DESCRIPTION
=================
Downgrading the grant table version of a guest involves freeing its
status pages. This freeing was incomplete - the page(s) are freed back
to the allocator, but not removed from the domain's tracking
list. This would cause list corruption, eventually leading to a
hypervisor crash.
IMPACT
======
A malicious guest administrator can cause Xen to crash, leading to a
denial of service attack.
VULNERABLE SYSTEMS
==================
All Xen version from 4.0 on are vulnerable.
Version 3.4 and earlier are not vulnerable.
Patch contents:
gnttab: fix releasing of memory upon switches between versions
gnttab_unpopulate_status_frames() incompletely freed the pages
previously used as status frame in that they did not get removed from
the domain's xenpage_list, thus causing subsequent list corruption
when those pages did get allocated again for the same or another purpose.
Similarly, grant_table_create() and gnttab_grow_table() both improperly
clean up in the event of an error - pages already shared with the guest
can't be freed by just passing them to free_xenheap_page(). Fix this by
sharing the pages only after all allocations succeeded.
This is CVE-2012-5510 / XSA-26.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.3-15]
- Correct RTC time offset update error for HVM guest
changeset 24947:b198ada9689d [bug 14676537]
[4.1.3-14]
- fix xm reboot wait exception
For VM reboot, the VM will first shutdown and then xend will recreate
it. This
bug is caused by: when we do server.xend.domains(), the VM is live;
when we do
server.xend.domain.getRestartCount(), the VM is dead, thus raise an
exception.
We can ignore this exception and just continue: this domain will be
handled in
the next loop (it will not in the live vm list).
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Signed-off-by: Jingjie Jiang <jingjie.jiang at oracle.com>
Signed-off-by: Junjie Wei <junjie.wei at oracle.com>
oracle-Bug: 14836200
[4.1.3-13]
- Xen Security Advisory CVE-2012-4544 / XSA-25
Xen domain builder Out-of-memory due to malicious kernel/ramdisk
ISSUE DESCRIPTION
=================
The Xen PV domain builder contained no validation of the size of the
supplied kernel or ramdisk either before or after decompression. This
could cause the toolstack to consume all available RAM in the domain
running the domain builder.
IMPACT
======
A malicious guest administrator who can supply a kernel or ramdisk can
exhaust memory in domain 0 leading to a denial of service attack.
VULNERABLE SYSTEMS
==================
All versions of Xen are vulnerable.
MITIGATION
==========
Running only trusted kernels and ramdisks will avoid this
vulnerability.
Using pvgrub also avoids this vulnerability since the builder will run
in guest context. (nb: use of pygrub *is* vulnerable).
Running only HVM guests will avoid this vulnerability.
RELATED ISSUE
=============
CVE-2012-2625 covers a bug in pygrub which caused that process to
consume excessive amount of memory under similar circumstances to the
above.
This was fixed in xen-unstable (and the fix inherited by Xen 4.2.x) in
revision 25589:60f09d1ab1fe but not called out as a security problem.
This fix is also included, where relevant, in the patches below.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue, including
the related pygrub fix where neccesary.
xsa25-unstable.patch Xen unstable
xsa25-4.2.patch Xen 4.2.x
xsa25-4.1.patch Xen 4.1.x
$ sha256sum xsa25*.patch
613e4b82cdc9cabf9cbd52076118887b298c47e680c2066a28a77f12e9f90606
xsa25-4.1.patch
135bc089d003f9b97991764c37b1ab8d37e9cbcfa1b9bd7429b4503abe00c8f5
xsa25-4.2.patch
534495b7eef6e599f5814f0a67fc84fbe2e8eee9d223a09ad178ff63bdcda3dd
xsa25-unstable.patch
Note that these patches impose a new size limit of 1Gby on both the
compressed and uncompressed sizes of ramdisks. On some systems it may
be desirable to relax these limits and risk virtual address or memory
exhaustion in the toolstack. This can be achieved by setting
XC_DOM_DECOMPRESS_MAX to the desired limit (in bytes). This can be
done by building with "APPEND_CFLAGS=-DXC_DOM_DECOMPRESS_MAX=<limit>"
or by editing tools/libxc/xc_dom.h directly.
NOTE REGARDING LACK OF EMBARGO
==============================
These issues have already been discussed in public in various places,
including https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-2625
and http://bugs.debian.org/688125. This advisory is therefore not
subject to an embargo.
Patch contains:
libxc: builder: limit maximum size of kernel/ramdisk.
Allowing user supplied kernels of arbitrary sizes, especially during
decompression, can swallow up dom0 memory leading to either virtual
address space exhaustion in the builder process or allocation
failures/OOM killing of both toolstack and unrelated processes.
We disable these checks when building in a stub domain for pvgrub
since this uses the guest's own memory and is isolated.
Decompression of gzip compressed kernels and ramdisks has been safe
since 14954:58205257517d (Xen 3.1.0 onwards).
This is XSA-25 / CVE-2012-4544.
Also make explicit checks for buffer overflows in various
decompression routines. These were already ruled out due to other
properties of the code but check them as a belt-and-braces measure.
Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
Acked-by: Ian Jackson <ian.jackson at eu.citrix.com>
[ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.3-12]
- Xen Security Advisory CVE-2012-4538 / XSA-23
Unhooking empty PAE entries DoS vulnerability
*** EMBARGOED UNTIL Tuesday 2012-11-13 12:00:00 UTC ***
ISSUE DESCRIPTION
=================
The HVMOP_pagetable_dying hypercall does not correctly check the
caller's pagetable state, leading to a hypervisor crash.
IMPACT
======
An HVM guest running on shadow pagetables (that is, not HAP) can
cause the hypervisor to crash.
VULNERABLE SYSTEMS
==================
All Xen versions from 4.0 onwards are vulnerable, except that:
- systems that run only PV guests are not vulnerable
- systems that run all HVM guests using HAP (which is the default on
hardware that supports it) are not vulnerable.
MITIGATION
==========
This issue can be avoided by running only PV guests or by running
all HVM guests using hardware-assisited paging (HAP, also called
NPT, RVI and EPT).
Xen will run guests using HAP by default on hardware that
supports it, unless it is disbled by putting 'hap=0' either on
the xen hypervisor command-line or in the VM's configuration.
You can check whether a particular machine supports HAP by looking at
xen's boot messages. On Xen 4.1, 4.2 and unstable, Xen will print
"HVM: Hardware Assisted Paging (HAP) detected" during boot; on xen 4.0
the message is "HVM: Hardware Assisted Paging detected".
Patch contains:
xen/mm/shadow: check toplevel pagetables are present before unhooking
them.
If the guest has not fully populated its top-level PAE entries when
it calls
HVMOP_pagetable_dying, the shadow code could try to unhook entries from
MFN 0. Add a check to avoid that case.
This issue was introduced by c/s 21239:b9d2db109cf5.
This is a security problem, XSA-23 / CVE-2012-4538.
Signed-off-by: Tim Deegan <tim at xen.org>
Tested-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.3-11]
- Xen Security Advisory CVE-2012-4538 / XSA-23
Unhooking empty PAE entries DoS vulnerability
*** EMBARGOED UNTIL Tuesday 2012-11-13 12:00:00 UTC ***
ISSUE DESCRIPTION
=================
The HVMOP_pagetable_dying hypercall does not correctly check the
caller's pagetable state, leading to a hypervisor crash.
IMPACT
======
An HVM guest running on shadow pagetables (that is, not HAP) can
cause the hypervisor to crash.
VULNERABLE SYSTEMS
==================
All Xen versions from 4.0 onwards are vulnerable, except that:
- systems that run only PV guests are not vulnerable
- systems that run all HVM guests using HAP (which is the default on
hardware that supports it) are not vulnerable.
MITIGATION
==========
This issue can be avoided by running only PV guests or by running
all HVM guests using hardware-assisited paging (HAP, also called
NPT, RVI and EPT).
Xen will run guests using HAP by default on hardware that
supports it, unless it is disbled by putting 'hap=0' either on
the xen hypervisor command-line or in the VM's configuration.
You can check whether a particular machine supports HAP by looking at
xen's boot messages. On Xen 4.1, 4.2 and unstable, Xen will print
"HVM: Hardware Assisted Paging (HAP) detected" during boot; on xen 4.0
the message is "HVM: Hardware Assisted Paging detected".
Patch contains:
xen/mm/shadow: check toplevel pagetables are present before unhooking
them.
If the guest has not fully populated its top-level PAE entries when
it calls
HVMOP_pagetable_dying, the shadow code could try to unhook entries from
MFN 0. Add a check to avoid that case.
This issue was introduced by c/s 21239:b9d2db109cf5.
This is a security problem, XSA-23 / CVE-2012-4538.
Signed-off-by: Tim Deegan <tim at xen.org>
Tested-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.3-10]
- Xen Security Advisory CVE-2012-4537 / XSA-22
version 3
Memory mapping failure DoS vulnerability
*** EMBARGOED UNTIL Tuesday 2012-11-13 12:00:00 UTC ***
UPDATES IN VERSION 3
====================
Correct patch names in description. The actual supplied patches were
correct.
ISSUE DESCRIPTION
=================
When set_p2m_entry fails, Xen's internal data structures (the p2m and
m2p tables) can get out of sync. This failure can be triggered by
unusual guest behaviour exhausting the memory reserved for the p2m
table. If it happens, subsequent guest-invoked memory operations can
cause Xen to fail an assertion and crash.
IMPACT
======
A malicious guest administrator might be able to cause Xen to crash.
VULNERABLE SYSTEMS
==================
All versions of Xen since at least 3.4 are vulnerable.
The vulnerability is only exposed to HVM guests.
Patch contains:
x86/physmap: Prevent incorrect updates of m2p mappings
In certain conditions, such as low memory, set_p2m_entry() can fail.
Currently, the p2m and m2p tables will get out of sync because we still
update the m2p table after the p2m update has failed.
If that happens, subsequent guest-invoked memory operations can cause
BUG()s and ASSERT()s to kill Xen.
This is fixed by only updating the m2p table iff the p2m was
successfully updated.
This is a security problem, XSA-22 / CVE-2012-4537.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Acked-by: Ian Jackson <ian.jackson at eu.citrix.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.3-9]
- Xen Security Advisory CVE-2012-4536 / XSA-21
pirq range check DoS vulnerability
*** EMBARGOED UNTIL Tuesday 2012-11-13 12:00:00 UTC ***
ISSUE DESCRIPTION
=================
domain_pirq_to_emuirq() uses the guest provided pirq value before
range checking it, and physdev_unmap_pirq uses domain_pirq_to_emuirq
without checking the pirq value either. Invalid pirq values can cause
Xen to read out of array bounds, usually resulting in a fatal page
fault.
IMPACT
======
A malicious guest administrator can cause Xen to crash. If the out of
array bounds access does not crash, the arbitrary value read will be
ignored due to later error checking, so there is no privilege
escalation and no exploitable information leak.
VULNERABLE SYSTEMS
==================
Only Xen version 4.1 is vulnerable. Other released versions, and
xen-unstable, are not vulnerable.
The vulnerability is only exposed to HVM guests.
MITIGATION
==========
Running only PV guests, or ensuring that HVM guests only use trusted
kernels, will avoid this vulnerability.
Patch contents:
x86/physdev: Range check pirq parameter from guests
Otherwise Xen will read beyond either end of the struct
domain.arch.pirq_emuirq array, usually resulting in a fatal page fault.
This vulnerability was introduced by c/s 23241:d21100f1d00e, which adds
a call to domain_pirq_to_emuirq() which uses the guest provided pirq
value before range checking it, and was fixed by c/s 23573:584c2e5e03d9
which changed the behaviour of the domain_pirq_to_emuirq() macro to use
radix trees instead of a flat array.
This is XSA-21 / CVE-2012-4536.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.3-8]
- Xen Security Advisory CVE-2012-4535 / XSA-20
Timer overflow DoS vulnerability
*** EMBARGOED UNTIL Tuesday 2012-11-13 12:00:00 UTC ***
ISSUE DESCRIPTION
=================
A guest which sets a VCPU with an inappropriate deadline can cause an
infinite loop in Xen, blocking the affected physical CPU
indefinitely.
IMPACT
======
A malicious guest administrator can trigger the bug. If the Xen
watchdog is enabled, the whole system will crash. Otherwise the guest
can cause the system to become completely unresponsive.
VULNERABLE SYSTEMS
==================
All versions of Xen from at least 3.4 onwards are vulnerable, to every
kind of guest.
Systems with only trusted guest kernels are not vulnerable.
MITIGATION
==========
There is no mitigation available other than to use a trusted guest
kernel.
Patch writeup:
VCPU/timers: Prevent overflow in calculations, leading to DoS
vulnerability
The timer action for a vcpu periodic timer is to calculate the next
expiry time, and to reinsert itself into the timer queue. If the
deadline ends up in the past, Xen never leaves __do_softirq(). The
affected PCPU will stay in an infinite loop until Xen is killed by the
watchdog (if enabled).
This is a security problem, XSA-20 / CVE-2012-4535.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Ian Campbell <ian.campbell at citrix.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.3-7]
- patch from chien.yen at oracle.com to fix XEN msixtbl_write() so that MLX
driver can be
loaded, unloaded successfull [bug 14787687]
[4.1.3-6]
- fix empty xml for state
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Chuang Cao <chuang.cao at oracle.com> [bug 14776605]
[4.1.3-5]
- Comment out if,fi.
[4.1.3-4]
- Added support for openvswitch
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com>
[4.1.3-3]
- tmem: Back-port xen cs/23266 up to cs/23377 tmem related fixes.
[in the Xen-unstable tree they are: 23850->25860 and 25929]
This is a combination of all those changesets together. The
patch descriptions are as follow:
tmem: only allow tmem control operations from privileged domains
This is part of XSA-15 / CVE-2012-3497.
Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
Acked-by: Dan Magenheimer <dan.magenheimer at oracle.com>
Acked-by: Jan Beulich <jbeulich at suse.com>
xen-unstable changeset: 25850:0dba5a888655
xen-unstable date: Tue Sep 11 12:06:30 UTC 2012
tmem: consistently make pool_id a uint32_t
Treating it as an int could allow a malicious guest to provide a
negative pool_Id, by passing the MAX_POOLS_PER_DOMAIN limit check and
allowing access to the negative offsets of the pool array.
This is part of XSA-15 / CVE-2012-3497.
Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
Acked-by: Dan Magenheimer <dan.magenheimer at oracle.com>
Acked-by: Jan Beulich <jbeulich at suse.com>
xen-unstable changeset: 25851:fcf567acc92a
xen-unstable date: Tue Sep 11 12:06:43 UTC 2012
tmem: check the pool_id is valid when destroying a tmem pool
This is part of XSA-15 / CVE-2012-3497.
Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
Acked-by: Dan Magenheimer <dan.magenheimer at oracle.com>
Acked-by: Jan Beulich <jbeulich at suse.com>
xen-unstable changeset: 25852:d189d99ef00c
xen-unstable date: Tue Sep 11 12:06:54 UTC 2012
tmem: check for a valid client ("domain") in the save subops
This is part of XSA-15 / CVE-2012-3497.
Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
Acked-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Dan Magenheimer <dan.magenheimer at oracle.com>
xen-unstable changeset: 25853:f53c5aadbba9
xen-unstable date: Tue Sep 11 12:17:27 UTC 2012
tmem: don't access guest memory without using the accessors intended
for this
This is not permitted, not even for buffers coming from Dom0 (and it
would also break the moment Dom0 runs in HVM mode). An implication from
the changes here is that tmh_copy_page() can't be used anymore for
control operations calling tmh_copy_{from,to}_client() (as those pass
the buffer by virtual address rather than MFN).
Note that tmemc_save_get_next_page() previously didn't set the returned
handle's pool_id field, while the new code does. It need to be
confirmed that this is not a problem (otherwise the copy-out operation
will require further tmh_...() abstractions to be added).
Further note that the patch removes (rather than adjusts) an invalid
call to unmap_domain_page() (no matching map_domain_page()) from
tmh_compress_from_client() and adds a missing one to an error return
path in tmh_copy_from_client().
Finally note that the patch adds a previously missing return statement
to cli_get_page() (without which that function could de-reference a
NULL pointer, triggerable from guest mode).
This is part of XSA-15 / CVE-2012-3497.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Dan Magenheimer <dan.magenheimer at oracle.com>
xen-unstable changeset: 25854:ccd60ed6c555
xen-unstable date: Tue Sep 11 12:17:49 UTC 2012
tmem: detect arithmetic overflow in tmh_copy_{from,to}_client()
This implies adjusting callers to deal with errors other than -EFAULT
and removing some comments which would otherwise become stale.
Reported-by: Tim Deegan <tim at xen.org>
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Dan Magenheimer <dan.magenheimer at oracle.com>
xen-unstable changeset: 25855:33b8c42a87ec
xen-unstable date: Tue Sep 11 12:17:59 UTC 2012
tmem: properly drop lock on error path in do_tmem_get()
Also remove a bogus assertion.
Reported-by: Tim Deegan <tim at xen.org>
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Dan Magenheimer <dan.magenheimer at oracle.com>
xen-unstable changeset: 25856:83b97a59888b
xen-unstable date: Tue Sep 11 12:18:08 UTC 2012
tmem: properly drop lock on error path in do_tmem_op()
Reported-by: Tim Deegan <tim at xen.org>
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Dan Magenheimer <dan.magenheimer at oracle.com>
xen-unstable changeset: 25857:109ea6a0c23a
xen-unstable date: Tue Sep 11 12:18:26 UTC 2012
tmem: reduce severity of log messages
Otherwise they can be used by a guest to spam the hypervisor log with
all settings at their defaults.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
xen-unstable changeset: 25858:0520982a602a
xen-unstable date: Tue Sep 11 12:18:36 UTC 2012
tmem: fixup 2010 cleanup patch that breaks tmem save/restore
20918:a3fa6d444b25 "Fix domain reference leaks" (in Feb 2010, by Jan)
does some cleanup in addition to the leak fixes. Unfortunately, that
cleanup inadvertently resulted in an incorrect fallthrough in a switch
statement which breaks tmem save/restore.
That broken patch was apparently applied to 4.0-testing and 4.1-testing
so those are broken as well.
What is the process now for requesting back-patches to 4.0 and 4.1?
(Side note: This does not by itself entirely fix save/restore in 4.2.)
Signed-off-by: Dan Magenheimer <dan.magenheimer at oracle.com>
Signed-off-by: Jan Beulich <jbeulich at suse.com>
xen-unstable changeset: 25859:16e0392c6594
xen-unstable date: Tue Sep 11 12:19:03 UTC 2012
tmem: cleanup
- one more case of checking for a specific rather than any error
- drop redundant casts
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Dan Magenheimer <dan.magenheimer at oracle.com>
xen-unstable changeset: 25860:e4cb84111610
xen-unstable date: Tue Sep 11 12:19:29 UTC 2012
tmem: bump pool version to 1 to fix restore issue when tmem enabled
Restore fails when tmem is enabled both in hypervisor and guest. This
is due to spec version mismatch when restoring a pool.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Acked-by: Dan Magenheimer <dan.magenheimer at oracle.com>
xen-unstable changeset: 25929:fee83ac77d8c
xen-unstable date: Wed Sep 19 15:38:47 UTC 2012
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.3-2]
- rebase tarball
[4.1.2-53]
- always release vm running lock on VM shutdown
Before this patch, when xend restarted, the VM running lock will not
be released
on shutdown, so the VM could never start again.
Talked with Junjie, we recommend always releasing the lock on VM
shutdown. So
even when xend restarted, there should be no stale lock leaving there.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Signed-off-by: Junjie Wei <junjie.wei at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com> [bug 14663406]
[4.1.2-52]
- Update Xen and QEMU from 4.1.2 to 4.1.3.
Signed-off-by: Junjie Wei <junjie.wei at oracle.com>
[4.1.2-51]
- hvmload: Revert bison files that were accidently checked in.
The "hvmloader: Only clear relevant parts, not the whole page"
accidently checked in the bison generated files. This
removes it.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.2-50]
- hvmloader: Only clear relevant parts, not the whole page.
The hvmloader interacts with the XenBus and when its done it
calls tools/firmware/hvmloader/xenbus.c:xenbus_shutdown()
which zero's the entire shared_info page.
It doesn't affect 64-bit guest because Xen has to rewrite the
wc fields on transition from 32 to 64 (mm/hvm.c:hvm_latch_shinfo_size)
while on 32-bit it detects no transition (so does nothing).
This patch resets relevant parts of the shared_info page.
[Note: This patch is not yet upstream, but Keir is going
to post it for Xen 4.2.1).
Signed-off-by: Keir Fraser <keir at xen.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
14519356]
[4.1.2-49]
- Disable iptables when adding a VIF to a Bridge [bug 14611657]
[4.1.2-48]
- xend bootloader: read pending data when bootloader exits
When dom0 under heavy pressure, the pipe read in xen bootloader may
return
-EAGAIN. This may result in no data read or partial data read.
With this patch, bootloader will read again when that happens.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com> [bug
14527250] [bug 14268749]
[4.1.2-47]
- qemu: Disable qemu monitor by default.
Xen Security Advisory XSA-19
guest administrator can access qemu monitor console
ISSUE DESCRIPTION
=================
A guest administrator who is granted access to the graphical console
of a Xen guest can access the qemu monitor. The monitor can be used
to access host resources.
IMPACT
======
A malicious guest administrator can access host resources (perhaps
belonging to other guests or the underlying system) and may be able to
escalate their privilege to that of the host.
VULNERABLE SYSTEMS
==================
Installations where guest administrators do not have access to a
domain's graphical console, or containing only PV domains configured
without a graphical console, are not vulnerable.
Installations where all guest administrators are trustworthy are not
vulnerable, even if the guest operating systems themselves are
untrusted.
Systems using xend/xm: At least all versions since Xen 4.0 are
affected. Systems are vulnerable even if "monitor=no" is specified in
the xm domain configuration file - this configuration option is not
properly honoured in the vulnerable versions.
Systems using libxl/xl: All versions are affected. The "monitor="
option is not understood, and is therefore ignored, by xl. However,
systems using the experimental device model version based on upstream
qemu are NOT vulnerable; that is, Xen 4.2 RC systems with
device_model_version="qemu_xen" specified in the xl domain config
file.
Systems using libvirt are vulnerable. For "xen:" URIs, see xend/xm,
above. For "libxl:" URIs, all versions are affected.
Systems based on the Xen Cloud Platform are NOT vulnerable.
CONFIRMING VULNERABILITY
========================
Connect to the guest's VNC (or SDL) graphical display and make sure
your focus is in that window. Hold down CTRL and ALT and press 2.
You will see a black screen showing one of "serial0", "parallel0" or
"QEMU <version> monitor". Repeat this exercise for other digits 3 to
6. CTRL+ALT+1 is the domain's normal graphical console. Not all
numbers will have screens attached, but note that you must release and
re-press CTRL and ALT each time.
If one of the accessible screens shows "QEMU <version> monitor" then
you are vulnerable. Otherwise you are not.
MITIGATION
==========
With xl in Xen 4.1 and later, supplying the following config
option in the VM configuration file will disable the monitor:
device_model_args=["-monitor","null"]
With xend the following config option will disable the monitor:
monitor_path="null"
Note that with a vulnerable version of the software specifying
"monitor=0" will NOT disable the monitor.
We are not currently aware of the availability of mitigation for
systems using libvirt.
NOTE REGARDING EMBARGO
======================
This issue was publicly discussed online by its discoverer.
There is therefore no embargo.
NOTE REGARDING CVE
==================
This issue was previously reported in a different context, not to Xen
upstream, and assigned CVE-2007-0998 and fixed in a different way. We
have requested a new CVE for XSA-19 but it is not yet available.
== PATCH ==
The qemu monitor is an overly
powerful feature which must be protected from untrusted (guest)
administrators.
Neither xl nor xend expect qemu to produce this monitor unless it is
explicitly requested.
This is a security problem, XSA-19. Previously it was CVE-2007-0998
in Red Hat but we haven't dealt with it in upstream. We hope to have
a new CVE for it here but we don't have one yet.
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.2-46]
- VMs with more than 64 VCPUs cannot be saved. This patch fixes the bug by
extending the VCPU map. (From Keir Fraser <keir.xen at gmail.com>)
Signed-off-by: Junjie Wei <junjie.wei at oracle.com>
Oracle-bug: 13587669
[4.1.2-45]
- xend: disable SCSI device discover during xend start
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com> [bug 14538564]
[4.1.2-44]
- x86/pvhvm: properly range-check PHYSDEVOP_map_pirq/MAP_PIRQ_TYPE_GSI
Xen Security Advisory CVE-2012-3498 / XSA-16
PHYSDEVOP_map_pirq index vulnerability
ISSUE DESCRIPTION
=================
PHYSDEVOP_map_pirq with MAP_PIRQ_TYPE_GSI does not range check
map->index.
IMPACT
======
A malicious HVM guest kernel can crash the host. It might also be
able to read hypervisor or guest memory.
VULNERABLE SYSTEMS
==================
All Xen systems running HVM guests. PV guests are not vulnerable.
The vulnerability dates back to Xen 4.1. Xen 4.0 is not vulnerable.
4.1, the 4.2 RCs, and xen-unstable.hg are vulnerable.
MITIGATION
==========
This issue can be mitigated by ensuring that the guest kernel is
trustworthy, or by running only PV guests.
Patch:
This is being used as a array index, and hence must be validated before
use.
This is XSA-16 / CVE-2012-3498.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.2-43]
- console: bounds check whenever changing the cursor due to an escape code
Xen Security Advisory CVE-2012-3515 / XSA-17
Qemu VT100 emulation vulnerability
ISSUE DESCRIPTION
=================
The device model used by fully virtualised (HVM) domains, qemu, does
not properly handle escape VT100 sequences when emulating certain
devices with a virtual console backend.
IMPACT
======
An attacker who has sufficient privilege to access a vulnerable device
within a guest can overwrite portions of the device model's address
space. This can allow them to escalate their privileges to that of the
device model process.
VULNERABLE SYSTEMS
==================
All Xen systems running HVM guests are potentially vulnerable to this
depending on the specific guest configuration. The default
configuration is vulnerable.
Guests using either the traditional "qemu-xen" or upstream qemu device
models are vulnerable.
This is XSA-17 / CVE-2012-3515
Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.2-42]
- xen: Don't BUG_ON() PoD operations on a non-translated guest.
Xen Security Advisory CVE-2012-3496 / XSA-14
XENMEM_populate_physmap DoS vulnerability
ISSUE DESCRIPTION
=================
XENMEM_populate_physmap can be called with invalid flags. By calling
it with MEMF_populate_on_demand flag set, a BUG can be triggered if a
translating paging mode is not being used.
IMPACT
======
A malicious guest kernel can crash the host.
VULNERABLE SYSTEMS
==================
All Xen systems running PV guests. Systems running only HVM guests
are not vulnerable.
The vulnerability dates back to at least Xen 4.0. 4.0, 4.1, the 4.2
RCs, and xen-unstable.hg are all vulnerable.
MITIGATION
==========
This issue can be mitigated by ensuring that the guest kernel is
trustworthy or by running only HVM guests.
This is XSA-14 / CVE-2012-3496
Signed-off-by: Tim Deegan <tim at xen.org>
Reviewed-by: Ian Campbell <ian.campbell at citrix.com>
Tested-by: Ian Campbell <ian.campbell at citrix.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.2-41]
- xen: handle out-of-pirq condition correctly in PHYSDEVOP_get_free_pirq
Xen Security Advisory CVE-2012-3495 / XSA-13
hypercall physdev_get_free_pirq vulnerability
ISSUE DESCRIPTION
=================
PHYSDEVOP_get_free_pirq does not check that its call to get_free_pirq
succeeded, and if it fails will use the error code as an array index.
IMPACT
======
A malicious guest might be able to cause the host to crash, leading to
a DoS, depending on the exact memory layout. Privilege escalation is
a theoretical possibility which cannot be ruled out, but is considered
unlikely.
VULNERABLE SYSTEMS
==================
All Xen systems.
Xen 4.1 is vulnerable. Other versions of Xen are not vulnerable.
MITIGATION
==========
This issue can be mitigated by ensuring (inside the guest) that the
kernel is trustworthy and avoiding situations where something might
repeatedly cause the attempted allocation of a physical irq. XXXX?
This is XSA-13 / CVE-2012-3495
Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
Signed-off-by: Jan Beulich <JBeulich at suse.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.2-40]
- xen: prevent a 64 bit guest setting reserved bits in DR7
XSA-12: Xen Security Advisory CVE-2012-3494 / XSA-12
hypercall set_debugreg vulnerability
ISSUE DESCRIPTION
=================
set_debugreg allows writes to reserved bits of the DR7 debug control
register on x86-64.
IMPACT
======
A malicious guest can cause the host to crash, leading to a DoS.
If the vulnerable hypervisor is run on future hardware, the impact of
the vulnerability might be widened depending on the future assignment
of the currently-reserved debug register bits.
VULNERABLE SYSTEMS
==================
All systems running 64-bit paravirtualised guests.
from the patch file:
The upper 32 bits of this register are reserved and should be written as
zero.
This is XSA-12 / CVE-2012-3494
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Ian Campbell <ian.campbell at citrix.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.2-39]
- fix xm create vcpu_avail exceeds XMLRPC int limits
If maxvcpus = vcpus = 40, (1<<40 -1) will exceed XMLRPC int limit.
Change it to
str will work. Then in the xend side, it will converted back to int.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com> [bug 14473041]
[4.1.2-38]
- In bootloader(), domains_lock is first released to avoid a stunk
bootloder from
denying service to the other xend clients. It is re-acquired before
returning
to domain creation to cover the changes to be made. But if something
goes wrong
and domains_lock is not re-acquired, we may hit an error when
releasing it one
more time. This patch makes sure that the released domains_lock is
re-acquired
before returning.
Signed-off-by: Junjie Wei <junjie.wei at oracle.com>
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Oracle-bug: 14407719
[4.1.2-37]
- x86-64/MMCFG: correct base address computation for regions not
starting at bus 0
As per the specification, the base address reported by ACPI is the one
that would be used if the region started at bus 0. Hence the
start_bus_number offset needs to be added not only to the virtual
address, but also the physical one when establishing the mapping, and
it then needs to be subtracted when obtaining the virtual address for
doing accesses.
Signed-off-by: Jan Beulich <jbeulich at novell.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Oracle-Bugzilla: 13674 [bug None]
[4.1.2-36]
- Revert partially "x86/cpuidle: do not flush cache unless entering C3"
(r3399)
I had two patches in my tree when committing the above mentioned
patch. So the c3399 ended up having parts of another patch. Backing
that out.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug None]
[4.1.2-35]
- x86/cpuidle: do not flush cache unless entering C3
Nor is there a need to disable bus master arbitration in that case.
Signed-off-by: Wei Wang <wei.wang2 at amd.com>
Modified-by: Zhang, Yang Z <yang.z.zhang at intel.com>
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Committed-by: Jan Beulich <jbeulich at suse.com>
[and in OVS]:
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
xen-unstable changeset: 25195:a06e6cdeafe3
xen-unstable date: Mon Apr 16 13:05:28 2012 +0200
Fedora Bug: 841330 [bug None]
[4.1.2-34]
- Xen Security Advisory CVE-2012-3433 / XSA-11
HVM guest destroy p2m teardown host DoS vulnerability
An HVM guest is able to manipulate its physical address space such
that tearing down the guest takes an extended period amount of
time searching for shared pages.
This causes the domain 0 VCPU which tears down the domain to be
blocked in the destroy hypercall. This causes that domain 0 VCPU to
become unavailable and may cause the domain 0 kernel to panic.
There is no requirement for memory sharing to be in use.
From the patch description:
xen: only check for shared pages while any exist on teardown
Avoids worst case behavour when guest has a large p2m.
This is XSA-11 / CVE-2012-nnn
Signed-off-by: Tim Deegan <tim at xen.org>
Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
Tested-by: Olaf Hering <olaf at aepfle.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
[4.1.2-33]
- x86: fix off-by-one in nr_irqs_gsi calculation
Upstream change: 25688:e6266fc76d08
highest_gsi() returns the last valid GSI, not a count.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Joe Jin <joe.jin at oracle.com>
Acked-by: Keir Fraser <keir at xen.org>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com> [bug 14137461]
[4.1.2-32]
- Xen Security Advisory XSA-10
HVM guest user mode MMIO emulation DoS vulnerability
ISSUE DESCRIPTION
=================
Internal data of the emulator for MMIO operations may, under
certain rare conditions, at the end of one emulation cycle be left
in a state affecting a subsequent emulation such that this second
emulation would fail, causing an exception to be reported to the
guest kernel where none is expected.
NOTE: No CVE number!
The patch description is as follow:
x86/hvm: don't leave emulator in inconsistent state
The fact that handle_mmio(), and thus the instruction emulator, is
being run through twice for emulations that require involvement of the
device model, allows for the second run to see a different guest state
than the first one. Since only the MMIO-specific emulation routines
update the vCPU's io_state, if they get invoked on the second pass,
internal state (and particularly this variable) can be left in a state
making successful emulation of a subsequent MMIO operation impossible.
Consequently, whenever the emulator invocation returns without
requesting a retry of the guest instruction, reset io_state.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Keir Fraser <keir at xen.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
[4.1.2-31]
- pygrub: log to syslog
pygrub: add syslog support to pygrub
Currently, when pygrub failed, we don't know the reason because
xend/xl will
not capture the stderr message.
This patch will log the error message to syslog.
We choosing syslog because pygrub could be called concurrently. If we
want
dedicated log file for pygrub, we need a log server. Using syslog is
simple.
Example /var/log/messages log:
Jul 19 11:59:53 ovs030 [2012-07-19 11:59:53,504 7112] ERROR
(pygrub:848) [Errno 95] Operation not supported Traceback (most recent
call last): File "/share/repos/xen-unstable/tools/pygrub/src/pygrub",
line 828, in ? fs = fsimage.open(file, offset, bootfsoptions)
IOError: [Errno 95] Operation not supported
Jul 19 11:59:53 ovs030 [2012-07-19 11:59:53,508 7112] ERROR
(pygrub:892) Unable to find partition containing kernel
'7112' is the pygrub PID, so we can distinguish each process.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com> [bug 14268749]
[4.1.2-30]
- Add restore (and migrate) functionality back in for PV
superpage-enabled guests.
Signed-off-by: Dave McCracken <dave.mccracken at oracle.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug 14005957]
[4.1.2-29]
- Add "allowhugepage" flag as a synonym for "allowsuperpage"
for compatibility with previous releases.
Signed-off-by: Dave McCracken <dave.mccracken at oracle.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Patch_name: ovs-xen-4.1-fspage-1.patch [bug 13821795]
[4.1.2-28]
- add more logs for bootloader diagnostic
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com> [bug
14325570&14268749]
[4.1.2-27]
- fix bootloader hang/crash xend on wrong bootargs.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Signed-off-by: Steve Prochniak <steve.prochniak at oracle.com> [bug
14195864]
[4.1.2-26]
- gnttab: don't use domain lock for serialization
Instead use the affected domain's grant table lock, at once reducing
the scopes during which locks are being held and hence allowing
significantly better parallelism.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Tested-by: Andrew Thomas <andrew.thomas at oracle.com>
[This is backport of cs 25419]
Committed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
[4.1.2-25]
- fix hotplug script locking using flock
We already has a fix there, but this one is better:
1. No timeout: in the old one, if one process holding the lock more
than 100
seconds, other processes could steal it.
2. No leftovers: if a process holding this lock is dead, it will
close the lock
file, so it will not affect other processes.
This patch is from OL5U8 Red Hat xen.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com> [bug 13979094]
[4.1.2-24]
- Xen Security Advisory CVE-2012-2934 / XSA-9
*** EMBARGOED UNTIL Tuesday 2012-06-12 12:00:00 UTC ***
[4.1.2-23]
- tools/hotplug: fix locking
The current locking implementation would allow two processes get the lock
simultaneously:
++ echo 16741: /etc/xen/scripts/block
++ cut -d : -f 1
+ local pid=16741
+ '[' -n 16741 -a 16741 '!=' unknown -a '!' -f /proc/16741/status ']'
+ '[' 5 -gt 5 ']'
+ sleep 0
+ retries=6
+ '[' 6 -lt 100 ']'
+ mkdir /var/run/xen-hotplug/block
++ _lock_owner /var/run/xen-hotplug/block
++ cat /var/run/xen-hotplug/block/owner
+ local 'new_owner=16741: /etc/xen/scripts/block'
+ '[' '16741: /etc/xen/scripts/block' '!=' '16741:
/etc/xen/scripts/block' ']'
++ echo 16741: /etc/xen/scripts/block
++ cut -d : -f 1
+ local pid=16741
+ '[' -n 16741 -a 16741 '!=' unknown -a '!' -f /proc/16741/status ']'
+ '[' 6 -gt 5 ']'
+ sleep 1
+ do_or_die losetup -r /dev/loop27
/OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
+ losetup -r /dev/loop27
/OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
+ do_or_die losetup -r /dev/loop27
/OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img
+ losetup -r /dev/loop27
/OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img
+ xenstore_write backend/vbd/33/51920/node /dev/loop27
+ _xenstore_write backend/vbd/33/51920/node /dev/loop27
+ log debug 'Writing backend/vbd/33/51920/node' '/dev/loop27 to
xenstore.'
+ local level=debug
+ shift
+ logger -p daemon.debug -- /etc/xen/scripts/block: 'Writing
backend/vbd/33/51920/node' '/dev/loop27 to xenstore.'
ioctl: LOOP_SET_FD: Device or resource busy
+ xenstore-write backend/vbd/33/51920/node /dev/loop27
+ fatal losetup -r /dev/loop27
'/OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img
failed'
This patch removes the ownner support and fixed this issue per my test.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com> [bug 13979094]
[4.1.2-22]
- block: use -b instead of -a for file exist testing
it will be interpreted as: expr1 -a expr2
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Signed-off-by: Junjie Wei <junjie.wei at oracle.com>
[4.1.2-21]
- remove unecessary balloon retries on vm create
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com> [bug 14143327]
[4.1.2-20]
- get host uuid from sysfs
Expose host uuid works on 3.0.3, but not 3.1.1:
error: libhal_device_get_property_type:
org.freedesktop.Hal.NoSuchProperty: No
property system.hardware.uuid on device with id
/org/freedesktop/Hal/devices/computer
hal-get-peroperty doesn't work with UEK2.
This patch will get host uuid from sysfs, it works on 3.0.3+.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com>
[4.1.2-19]
- Xen Security Advisory 8 v2 - guest DoS on syscall/sysenter exception
*** EMBARGOED UNTIL Tuesday 2012-05-01 12:00:00 UTC ***
[4.1.2-18]
- his patch will create a loop device node if it is not exist when VM start.
After this patch, Kernel max_loop could be 8.
I tested it could create 1025 loop device nodes within 1 minutes.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com>
[4.1.2-17]
- Set max cstate to 1.
We have several bugs that cstate made system unstable, both for ovm2
and ovm3:
For OVM3.x:
Bug 13703504 - unexplained network disconnect causes ocfs to fence
the server
https://forums.oracle.com/forums/thread.jspa?threadID=2347014&tstart=0
For OVM2.x
https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=10631565
https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=13494054
[bug 13703504]
[4.1.2-16]
- revert xen unstable changeset 22315: it breaks SSL live migration.
Original change set:
Do not wait for memory teardown when live migrate
When trying to live migrate guest with great memory (e.g. 20 GB),
there's delay caused by destroying source copy of domain. To speed up
this process we can close socket before starting guest destroy, as
source guest is not running anymore.
Signed-off-by: Miroslav Rezanina <mrezanin at redhat.com>
Signed-off-by: Ian Jackson <ian.jackson at eu.citrix.com> [bug
13808326&13874471]
[4.1.2-15]
- Backport of c/s 24013 of the 32-bit compat layer, which states: "
pvhvm running with more than 32 vcpus and pv_irq/pv_time enabled
need vcpu placement to work, or else it will softlockup.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Committed-by: Keir Fraser <keir at xen.org>
"
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
13073337]
[4.1.2-14]
- Backport of c/s 24013, which states: "
pvhvm running with more than 32 vcpus and pv_irq/pv_time enabled
need vcpu placement to work, or else it will softlockup.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Committed-by: Keir Fraser <keir at xen.org>
"
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
13073337]
[4.1.2-13]
- From Message-ID:
<1332267691-13179-1-git-send-email-david.vrabel at citrix.com>
If a maximum reservation for dom0 is not explictly given (i.e., no
dom0_mem=max:MMM command line option), then set the maximum
reservation to the initial number of pages. This is what most people
seem to expect when they specify dom0_mem=512M (i.e., exactly 512 MB
and no more).
This change means that with Linux 3.0.5 and later kernels,
dom0_mem=512M has the same result as older, 'classic Xen' kernels. The
older kernels used the initial number of pages to set the maximum
number of pages and did not query the hypervisor for the maximum
reservation.
It is still possible to have a larger reservation by explicitly
specifying dom0_mem=max:MMM.
Signed-off-by: David Vrabel <david.vrabel at citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
NOTE: This behaviour should also be implemented in the Linux kernel.
[bug 13860516]
[4.1.2-12]
- Correct stop xend return status [bug 13845552]
[4.1.2-11]
- We don't support PCI segmented domains yet, so for right now
just ignore the hypercall with that type. Dom0 is smart enough
to fallback to the old type. If need to back-port the support
then revisit:
23855:e2bd50b0843a
user: Jan Beulich <jbeulich at suse.com>
date: Sun Sep 18 00:12:19 2011 +0100
summary: PCI multi-seg: add new physdevop-s
changeset: 23854:e5263921c85e
user: Jan Beulich <jbeulich at suse.com>
date: Sun Sep 18 00:10:03 2011 +0100
summary: PCI multi-seg: introduce notion of PCI segments
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
13727499]
[4.1.2-10]
- If bridge MTU != 1500, then set tap MTU to bridge MTU [bug 13773039]
[4.1.2-9]
- Version numbering, CVE-2012-0029 and upstream fixes
Xen: 23263:b01091775dd9
qemu: 3cf61880
[4.1.2-8]
- If needed; Change the VIF MTU before connecting it to the bridge. [bug
13773039]
[4.1.2-7]
- Fix bug 12861822(VM fails to resume automatically in WHQL test)
[4.1.2-6]
- Put back the patch that prevent older guest that uses kudzu from hanging
on a reboot. Fixed the patch to prevent excessive watcher writes which
causes xend, xenstored to run at a 100% cpu usage. Now the watch is
written
only if console in Initialising, InitWait, Initialised states which
happen
once at boot time. [bug 13523487]
[4.1.2-5]
- The ACPI compiler/dsdt.asl table generates nodes for S3/S4 which are
now 12 bytes (rather than 14). Update the sizes of the chunks to be
excised.
Fixes windows boot/install and linux shutdown issues. [bug 13772650]
[4.1.2-4]
- set max_phys_cpus=160 [bug 13727780]
[4.1.2-3]
- PLE can cause problems
With PLE enabled, 2.6.32 guests will crash early on with:
..MP-BIOS bug: 8254 timer not connected to IO-APIC
Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot
with apic=debug
The patch to vpt.c is the suggested fix from: xiantao.zhang at intel.com.
patch to vmcs.c was the prioir workaround.
[4.1.2-2]
- Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com>
Signed-off-by: Gary Grebus <gary.grebus at oracle.com>
[4.1.2-1]
- rebase patches to 4.1.2 tree
remove dm-nfs
update insmod
disable PLE temporarily
stop building/install documentation - it can't be read on OVM server.
[4.0.0-81]
- re-enable dm-nfs support.
Signed-off-by: Andrew Thomas <andrew.thomas at oracle.com>
Signed-off-by: kurt.hackel at oracle.com
Approved-by: steve.noyes at oracle.com
[4.0.0-80]
- Make performance the default governor like we did for 2.2.X series.
Signed-off-by: Andrew Thomas <andrew.thomas at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com>
[4.0.0-79]
- KDB: enhance dgdt. hvm set single_step. gdbsx, add trace print.
[4.0.0-78]
- fix solaris domU detection
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com> [bug 12718579]
[4.0.0-77]
- tools/pygrub: fix solaris kernel sniff
Solaris 11 build 163+ removes '/platform/i86xpv/kernel/unix' and only the
64-bit PV kernel file '/platform/i86xpv/kernel/amd64/unix' exists.
This patch fixes the detection.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com> [bug 12718579]
[4.0.0-76]
- tools/hotplug/Linux/block: fix shared loop device detection
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com> [bug 12316734]
[4.0.0-75]
- AMD Bulldozer cpu's require some fixes to get them working.
We do NOT provide the support for these features:
- SVM perfmance enhancements ("clean bits").
- AVX
- LWP
We expect Xen to be started with xsave=0 for AMD bulldozer systems in
order
to disable AVX.
Xen-4.1-testing: 22462:98eb4a334b77
Xen-4.1-testing: 23027:2dde81ed2e3d
xen-unstable.hg: 23290:1ac7336b6298
xen-unstable.hg: 23511:450f1d198e1e
Signed-off-by: Andrew Thomas <andrew.thomas at oracle.com>
[4.0.0-74]
- This is a Xen cumulative patch from c/s 21458 to 21511 (in the 4.0
testing tree.) It includes an important VT-d related CVE and necessary
updates for AMD (Bulldozer in particular).
Signed-off-by: Andrew Thomas <andrew.thomas at oracle.com>
[4.0.0-73]
- fix xendomains to shutdown vms on stop
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com> [bug 11907918]
[4.0.0-72]
- make non-ssl vnc listen on localhost only.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com>
[4.0.0-71]
- KDB: Handle support for MTF flag for hvm guest single step. Set
single_step in
case of HVM guest so that MTF flag is set.
[4.0.0-70]
- enable domain lock callout.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com>
Signed-off-by: Junjie Wei <junjie.wei at oracle.com>
[4.0.0-69]
- fix to avoid ballooning when dom0-min-mem is set and
enable-dom0-ballooning
is enabled. [bug 12404026]
[4.0.0-68]
- Changes to parameters passed to ovs-agent-dlm.
Signed-off-by: Junjie Wei <junjie.wei at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com>
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
[4.0.0-67]
- Revert to r2515.
[4.0.0-66]
- Change parameters passed to ovs-agent-dlm.
Signed-off-by: Junjie Wei <junjie.wei at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com>
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
[4.0.0-65]
- Fix Bug 10238928 - XEND CONFIG LAYER FAILS TO REFRESH GUEST DEVICE
INFO WHEN CHANGED DYNAMICALLY.
1. Add deleteDevice in XendDomainInfo.py.
2. Call deleteDevice in deviceDestroyCallback of DevController.py.
3. set event after wait timeout.
[4.0.0-64]
- KDB: print longs for page struct fields.
[4.0.0-63]
- Add -OVM to version information. This is visible through smbios/dmidecode
information for HVM (ie Solaris) guests. [bug 11792774]
[4.0.0-62]
- Important security fix.
x86_64: fix error checking in arch_set_info_guest()
Cannot specify user mode execution without specifying user-mode
pagetables.
Signed-off-by: Tim Deegan <Tim.Deegan at citrix.com>
Acked-by: Keir Fraser <keir at xen.org>
xen-unstable changeset: 23034:c79aae866ad8
xen-unstable date: Mon Mar 14 16:59:49 2011 +0000
[4.0.0-61]
- Cumulative updates from upstream (mostly HVM related).
Changesets 21423-21457 [inclusive, but removing mercurial repo changes.]
Includes 21440 which addresses Orabug: 10255006 [bug 10255006]
[4.0.0-60]
- xmstat: fix type in README.
[4.0.0-59]
- KDB: clear watchpoints on all cpus.
[4.0.0-58]
- When a VIF connect to a bridge change its MTU (1500 | 9000) if needed.
[4.0.0-57]
- KDB: Do detailed display of VMCS on Intel upon dvmc cmd.
[4.0.0-56]
- KDB: enhance dgdt again. check for valid mfn in m2p command.
[4.0.0-55]
- A hack to disable dm-nfs support prioir to Junjie's clean up.
Signed-off-by: kurt.hackel at oracle.com :-)
[4.0.0-54]
- KDB: refresh disassembler library, udis, to 1.7.
[4.0.0-53]
- KDB: changes related to refreshing upstream ext tree to latest unstable"
[4.0.0-52]
- Import 2.2 patch for Solaris PXE boot. Also update eb-roms.h file to
prebuilt version (a minor annoyance with srpm repos). [bug
11076422&10135669]
[4.0.0-51]
- gdbsx: update README. kdb: update README with btp cmd. xmstat: Update
tools/Makefile and add perf/Makefile to always build and install it.
[4.0.0-50]
- KDB: add new cmd btp, to trace upon breakpoints. Add display of timer
structs
and vlapic structs.
[4.0.0-49]
- XMSTAT: initial checkin.
[4.0.0-48]
- Cumulative patch from 21327 to 21422; as we already had some of these
applied, this cumulative patch omits: 21336, 21337, 21344.
This patch contains some minor changes for IDLE_DOMAIN_ID to
DOMID_IDLE changes affecting:
kdb_cmds.c
x86/udis86-1.6/kdb_dis.c
[4.0.0-47]
- Fix xend service stop status: return 0 on success.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Acked-by: Kurt Hackel <kurt.hackel at oracle.com> [bug 10334816]
[4.0.0-46]
- Add dependency on pciutils-devel for xen-tools package
[4.0.0-45]
- KDB: Redo gdt display command. Add commands to display MSRs and cpuid
outputs.
[4.0.0-44]
- Remove SDL-devel, gtk2-devel, and libX11-devel from BuildRequires
[4.0.0-43]
- Fix a descriptor leak in xenstore. The function xs_daemon_close() was
not closing descriptors.
orabug:10155532
[4.0.0-42]
- Add rule to create /dev/xen/gntdev
[4.0.0-41]
- Disable ballooning of dom0 - this is from 2.2.1 (see bug 8604766
and 9485681). Not an orabug on this release though.
[4.0.0-40]
- 2.6.32 kernel uses gntdev as a module, so load it at runtime
[4.0.0-39]
- x2apic related fixes from Yinghai Lu. Increase MAX_LOCAL_APIC to 512,
change apic_id to u32, etc...
[4.0.0-38]
- Disable intel xsave. Changeset 21336 in unstable. See
http://www.gossamer-threads.com/lists/xen/devel/184099, or search xen
devel archives for "xen trouble while guest excute float app".
[4.0.0-37]
- gdbsx: Try the MTF flag first during HVM guest single step, reverting to
manually setting the TF flag if that fails.
[4.0.0-36]
- Apply patches from Yinghai: mparse_pass_32bit_apicid, 256_cpus,
x2apic_preenable, x2apic-acpi, and remove_warning.patch.
[4.0.0-35]
- Stage qemu-dm in /usr/lib64
[4.0.0-34]
- Refresh xen to xen RELEASE-4.0.1, C/S 21326. Refresh QEMU to TAG
xen-4.0.1.
[4.0.0-33]
- xend: acpi s3/s4 code clean up.
[4.0.0-32]
- Backport xen unstable cs 21839:
hvmloader: clear the whole shared-info page when shutting down xenbus
since the contents might be in the wrong word-size for later users.
Signed-off-by: Tim Deegan <Tim.Deegan at citrix.com>
[4.0.0-31]
- xend: add acpi s3/s4 configuration options.
[4.0.0-30]
- hvmloader: enable dynamic acpi s3/s4 change.
[4.0.0-29]
- Backport xen-unstable-cs-21831:
hvmloader: clear the xenbus event-channel when we're done with it.
Otherwise a later xenbus client that naively waits for the rising edge
could get stuck.
Signed-off-by: Tim Deegan <Tim.Deegan at citrix.com>
[4.0.0-28]
- Backport xen-unstable-cs-21767:
hvmloader: Add a xenbus frontend so it can read values from xenstore
Signed-off-by: Tim Deegan <Tim.Deegan at citrix.com>
[4.0.0-27]
- display more cpu data info. sync with ext tree c/s 20376, unst c/s 21811.
[4.0.0-26]
- Make gdbsx part of normal xen to align with upstream.
[4.0.0-25]
- Remove space from qThreadInfo packet because newer gdb version 7* has
a bug in parsing thread list. Also, another gdb bug in printf.
[4.0.0-24]
- Stage hvmloader and qemu-dm in /usr/lib and /usr/lib64 for backward
compatibility with vm.cfg files from OVM 2.x [bug 9348075]
[4.0.0-23]
- back port xen-unstable change set 21684:
tools/python: sxp parser: show empty string
This patch makes the sxp parser show empty string.
Test case:
import sxp
sxp.show(sxp.from_string('(a "")'))
sxp.show(sxp.from_string("(a '')"))
Without this patch:
(a )(a )
With this patch:
(a '')(a '')
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
[4.0.0-22]
- Improve xend service to give better status report. [bug 9882998]
[4.0.0-21]
- tmem page dedup and tmem bug fixes through xen-unstable cs21658
[4.0.0-20]
- Add ext4 support for pygrub: use the shipped ext2 library.
[4.0.0-19]
- Alter xen/Makefile to install the debug hypervisor when built with the
gdbsx flag.
Oracle-bug:9817500
[4.0.0-18]
- KDB: Add new cmd to display loaded modules in a guest. Add barrier() in
kdb_trap_immed().
[4.0.0-17]
- 1) NEW: conditional breakpoints. 2) Redo dirq cmd. 3) NEW: cmd dvit
(display per cpu vector irq table).
[4.0.0-16]
- Add workarounds for timer interrupt routing crashes on some Supermicro
systems.
The MP BIOS tables on some systems incorrectly route the timer interrupt.
Try to automatically set the kernel parameter
"acpi_skip_timer_override" on
these systems. Add kernel parameter "acpi_use_timer_override" to disable
automatic application.
Signed-off-by: kurt.hackel at oracle.com [bug 9694370]
[4.0.0-15]
- expose host uuid to guest via xenstore.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com>
[4.0.0-14]
- Set VM vnc server listen everywhere.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com>
[4.0.0-13]
- Enables xend ssl relocation server.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com>
[4.0.0-12]
- Enable dm-nfs block setup.
Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com>
Signed-off-by: Gary Grebus <gary.grebus at oracle.com>
[4.0.0-11]
- disable network-script
[4.0.0-10]
- Load backend modules at xend start.
[4.0.0-9]
- Put xenstored tdb to tmpfs.
[4.0.0-8]
- Add long cmdline support.
[4.0.0-7]
- Add domain running lock callout hook.
[4.0.0-6]
- Add vbd/vif qos support.
[4.0.0-5]
- Enable building of debug pkgs.
[4.0.0-4]
- DEBUG PKG: Enable build of gdbsx so it can be included in our debug pkg.
[4.0.0-3]
- KDB: merge kdb patch.
[4.0.0-2]
- Add dummy-null.patch so the autopatch can be turned on. The autopatch will
fail if there are no patches in the spec file.
[4.0.0-1]
- Initial spec file for xen 4.0 in ovm3.0 release. The initial tar file
for Source0 is tar of the base expanded tree. Basically, xen 4.0 c/s
21088
with qemu copied locally, and iasl compiled and put in the acpi
directory.
More information about the Oraclevm-errata
mailing list