xen/Makefile | 11 5 + 6 - 0 !
xen/common/kernel.c | 4 2 + 2 - 0 !
xen/common/version.c | 21 11 + 10 - 0 !
xen/drivers/char/console.c | 9 3 + 6 - 0 !
xen/include/xen/compile.h.in | 8 4 + 4 - 0 !
xen/include/xen/version.h | 8 4 + 4 - 0 !
6 files changed, 29 insertions(+), 32 deletions(-)

 version

@DPATCH@

Config.mk | 2 1 + 1 - 0 !
config/StdGNU.mk | 11 8 + 3 - 0 !
2 files changed, 9 insertions(+), 4 deletions(-)

 config-prefix.diff

tools/libfsimage/common/Makefile | 18 4 + 14 - 0 !
1 file changed, 4 insertions(+), 14 deletions(-)

 tools-libfsimage-abiname.diff

tools/libxc/Makefile | 35 13 + 22 - 0 !
1 file changed, 13 insertions(+), 22 deletions(-)

 tools-libxc-abiname.diff

tools/libxl/Makefile | 34 10 + 24 - 0 !
1 file changed, 10 insertions(+), 24 deletions(-)

 tools-libxl-abiname.diff

tools/xenstat/libxenstat/Makefile | 20 4 + 16 - 0 !
1 file changed, 4 insertions(+), 16 deletions(-)

 tools-xenstat-abiname.diff

tools/Rules.mk | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 tools-rpath.diff

tools/blktap2/control/Makefile | 26 8 + 18 - 0 !
tools/blktap2/vhd/Makefile | 1 1 + 0 - 0 !
tools/blktap2/vhd/lib/Makefile | 29 9 + 20 - 0 !
3 files changed, 18 insertions(+), 38 deletions(-)

 tools-blktap2-prefix.diff

tools/console/Makefile | 5 2 + 3 - 0 !
1 file changed, 2 insertions(+), 3 deletions(-)

 tools-console-prefix.diff

tools/libfsimage/Rules.mk | 3 2 + 1 - 0 !
tools/libfsimage/common/Makefile | 6 4 + 2 - 0 !
2 files changed, 6 insertions(+), 3 deletions(-)

 tools-libfsimage-prefix.diff

tools/libxl/Makefile | 9 5 + 4 - 0 !
tools/xenstat/libxenstat/Makefile | 2 1 + 1 - 0 !
2 files changed, 6 insertions(+), 5 deletions(-)

 tools-libxl-prefix.diff

tools/misc/Makefile | 8 3 + 5 - 0 !
tools/python/xen/xend/xend | 2 2 + 0 - 0 !
2 files changed, 5 insertions(+), 5 deletions(-)

 tools-misc-prefix.diff

tools/pygrub/setup.py | 2 2 + 0 - 0 !
tools/pygrub/src/pygrub | 2 2 + 0 - 0 !
2 files changed, 4 insertions(+)

 tools-pygrub-prefix.diff

tools/python/setup.py | 10 10 + 0 - 0 !
tools/python/xen/util/auxbin.py | 36 19 + 17 - 0 !
2 files changed, 29 insertions(+), 17 deletions(-)

 tools-python-prefix.diff

tools/xcutils/Makefile | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 tools-xcutils-rpath.diff

tools/xenmon/Makefile | 9 5 + 4 - 0 !
1 file changed, 5 insertions(+), 4 deletions(-)

 tools-xenmon-prefix.diff

tools/xenpaging/Makefile | 6 3 + 3 - 0 !
1 file changed, 3 insertions(+), 3 deletions(-)

 tools-xenpaging-prefix.diff

tools/xenstat/libxenstat/Makefile | 1 1 + 0 - 0 !
tools/xenstat/xentop/Makefile | 6 4 + 2 - 0 !
2 files changed, 5 insertions(+), 2 deletions(-)

 tools-xenstat-prefix.diff

tools/xenstore/Makefile | 16 9 + 7 - 0 !
1 file changed, 9 insertions(+), 7 deletions(-)

 tools-xenstore-prefix.diff

tools/xentrace/Makefile | 9 4 + 5 - 0 !
1 file changed, 4 insertions(+), 5 deletions(-)

 tools-xentrace-prefix.diff

tools/python/xen/xend/XendCheckpoint.py | 4 2 + 2 - 0 !
tools/python/xen/xend/XendConfig.py | 12 6 + 6 - 0 !
tools/python/xen/xend/XendDomainInfo.py | 2 1 + 1 - 0 !
tools/python/xen/xm/create.py | 35 15 + 20 - 0 !
4 files changed, 24 insertions(+), 29 deletions(-)

 tools-python-xen-relative-path.diff

tools/python/xen/xend/xend | 11 0 + 11 - 0 !
1 file changed, 11 deletions(-)

 tools-misc-xend-startup.diff

tools/Makefile | 2 0 + 2 - 0 !
tools/Rules.mk | 4 0 + 4 - 0 !
2 files changed, 6 deletions(-)

 tools-disable.diff

tools/examples/xend-config.sxp | 6 5 + 1 - 0 !
1 file changed, 5 insertions(+), 1 deletion(-)

 tools-examples-xend-disable-network.diff

tools/examples/xend-config.sxp | 2 0 + 2 - 0 !
1 file changed, 2 deletions(-)

 tools-examples-xend-disable-relocation.diff

tools/pygrub/src/pygrub | 51 1 + 50 - 0 !
1 file changed, 1 insertion(+), 50 deletions(-)

 tools-pygrub-remove-static-solaris-support

tools/include/Makefile | 2 0 + 2 - 0 !
1 file changed, 2 deletions(-)

 tools-include-install.diff

tools/xenmon/Makefile | 6 5 + 1 - 0 !
1 file changed, 5 insertions(+), 1 deletion(-)

 tools-xenmon-install.diff

tools/hotplug/Linux/xen-backend.rules | 7 0 + 7 - 0 !
1 file changed, 7 deletions(-)

 tools-hotplug-udevrules.diff

tools/python/xen/remus/save.py | 2 0 + 2 - 0 !
tools/python/xen/remus/vm.py | 2 0 + 2 - 0 !
tools/python/xen/util/bugtool.py | 2 0 + 2 - 0 !
tools/python/xen/util/pci.py | 2 0 + 2 - 0 !
tools/python/xen/util/vscsi_util.py | 1 0 + 1 - 0 !
tools/python/xen/xend/XendBase.py | 1 0 + 1 - 0 !
tools/python/xen/xend/XendClient.py | 1 0 + 1 - 0 !
tools/python/xen/xend/XendLocalStorageRepo.py | 1 0 + 1 - 0 !
tools/python/xen/xend/XendQCoWStorageRepo.py | 1 0 + 1 - 0 !
tools/python/xen/xend/XendSXPDev.py | 2 0 + 2 - 0 !
tools/python/xen/xend/XendStorageRepository.py | 1 0 + 1 - 0 !
tools/python/xen/xend/XendVDI.py | 1 0 + 1 - 0 !
tools/python/xen/xend/arch.py | 2 0 + 2 - 0 !
tools/python/xen/xend/osdep.py | 2 0 + 2 - 0 !
tools/python/xen/xend/sxp.py | 1 0 + 1 - 0 !
tools/python/xen/xm/xenapi_create.py | 1 0 + 1 - 0 !
16 files changed, 23 deletions(-)

 tools-python-shebang.diff

tools/xenstore/xenstore.h | 1 1 + 0 - 0 !
tools/xenstore/xenstore_client.c | 2 1 + 1 - 0 !
tools/xenstore/xs.c | 4 3 + 1 - 0 !
3 files changed, 5 insertions(+), 2 deletions(-)

 tools-xenstore-compatibility.diff

docs/man/xl.cfg.pod.5 | 4 2 + 2 - 0 !
tools/Makefile | 2 1 + 1 - 0 !
tools/libxl/xl_cmdimpl.c | 2 1 + 1 - 0 !
tools/python/xen/xend/XendDomainInfo.py | 4 2 + 2 - 0 !
4 files changed, 6 insertions(+), 6 deletions(-)

 send xl coredumps /var/lib/xen/dump/name

xen/common/event_fifo.c | 82 58 + 24 - 0 !
1 file changed, 58 insertions(+), 24 deletions(-)

 evtchn: check control block exists when using fifo-based events

When using the FIFO-based event channels, there are no checks for the
existance of a control block when binding an event or moving it to a

xen/arch/x86/mm/shadow/common.c | 4 3 + 1 - 0 !
xen/include/asm-x86/hvm/domain.h | 2 1 + 1 - 0 !
2 files changed, 4 insertions(+), 2 deletions(-)

 x86/shadow: fix race condition sampling the dirty vram state

d->arch.hvm_domain.dirty_vram must be read with the domain's paging lock held.

If not, two concurrent hypercalls could both end up attempting to free
dirty_vram (the second of which will free a wild pointer), or both end up
allocating a new dirty_vram structure (the first of which will be leaked).

This is XSA-104.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

xen/arch/x86/x86_emulate/x86_emulate.c | 3 3 + 0 - 0 !
1 file changed, 3 insertions(+)

 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@bitdefender.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Andrei LUTAS <vlutas@bitdefender.com>

xen/arch/x86/x86_emulate/x86_emulate.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 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@bitdefender.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

xen/arch/x86/hvm/hvm.c | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 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 CVE-2014-7188 / XSA-108.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
master commit: 61fdda7acf3de11f3d50d50e5b4f4ecfac7e0d04
master date: 2014-10-01 14:54:47 +0200

xen/drivers/passthrough/vtd/quirks.c | 10 6 + 4 - 0 !
1 file changed, 6 insertions(+), 4 deletions(-)

 vt-d: suppress ur signaling for further desktop chipsets

This extends commit d6cb14b34f ("VT-d: suppress UR signaling for
desktop chipsets") as per the finally obtained list of affected
chipsets from Intel.

Also pad the IDs we had listed there before to full 4 hex digits.

This is CVE-2013-3495 / XSA-59.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

xen/arch/x86/domain.c | 4 3 + 1 - 0 !
xen/arch/x86/domctl.c | 8 5 + 3 - 0 !
xen/arch/x86/hvm/hvm.c | 9 6 + 3 - 0 !
xen/arch/x86/mm/paging.c | 261 215 + 46 - 0 !
xen/arch/x86/x86_64/compat/entry.S | 2 2 + 0 - 0 !
xen/arch/x86/x86_64/entry.S | 2 2 + 0 - 0 !
xen/common/domain.c | 1 0 + 1 - 0 !
xen/include/asm-x86/domain.h | 14 14 + 0 - 0 !
xen/include/asm-x86/paging.h | 13 5 + 8 - 0 !
9 files changed, 252 insertions(+), 62 deletions(-)

 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@suse.com>

xen/arch/x86/mm.c | 4 4 + 0 - 0 !
1 file changed, 4 insertions(+)

 x86: don't allow page table updates on non-pv page tables in
 do_mmu_update()

paging_write_guest_entry() and paging_cmpxchg_guest_entry() aren't
consistently supported for non-PV guests (they'd deref NULL for PVH or
non-HAP HVM ones). Don't allow respective MMU_* operations on the
page tables of such domains.

This is CVE-2014-8594 / XSA-109.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

xen/arch/x86/x86_emulate/x86_emulate.c | 42 28 + 14 - 0 !
1 file changed, 28 insertions(+), 14 deletions(-)

 x86emul: enforce privilege level restrictions when loading cs

Privilege level checks were basically missing for the CS case, the
only check that was done (RPL == DPL for nonconforming segments)
was solely covering a single special case (return to non-conforming
segment).

Additionally in long mode the L bit set requires the D bit to be clear,
as was recently pointed out for KVM by Nadav Amit
<namit@cs.technion.ac.il>.

Finally we also need to force the loaded selector's RPL to CPL (at
least as long as lret/retf emulation doesn't support privilege level
changes).

This is CVE-2014-8595 / XSA-110.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

xen/arch/x86/mm.c | 13 6 + 7 - 0 !
1 file changed, 6 insertions(+), 7 deletions(-)

 x86/mm: fix a reference counting error in mmu_machphys_update

Any domain which can pass the XSM check against a translated guest can cause a
page reference to be leaked.

While shuffling the order of checks, drop the quite-pointless MEM_LOG().  This
brings the check in line with similar checks in the vicinity.

Discovered while reviewing the XSA-109/110 followup series.

This is XSA-113.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

tools/libxl/libxl_internal.c | 4 3 + 1 - 0 !
1 file changed, 3 insertions(+), 1 deletion(-)

 tools: libxl: do not overrun input buffer in libxl__parse_mac

Valgrind reports:
==7971== Invalid read of size 1
==7971==    at 0x40877BE: libxl__parse_mac (libxl_internal.c:288)
==7971==    by 0x405C5F8: libxl__device_nic_from_xs_be (libxl.c:3405)
==7971==    by 0x4065542: libxl__append_nic_list_of_type (libxl.c:3484)
==7971==    by 0x4065542: libxl_device_nic_list (libxl.c:3504)
==7971==    by 0x406F561: libxl_retrieve_domain_configuration (libxl.c:6661)
==7971==    by 0x805671C: reload_domain_config (xl_cmdimpl.c:2037)
==7971==    by 0x8057F30: handle_domain_death (xl_cmdimpl.c:2116)
==7971==    by 0x8057F30: create_domain (xl_cmdimpl.c:2580)
==7971==    by 0x805B4B2: main_create (xl_cmdimpl.c:4652)
==7971==    by 0x804EAB2: main (xl.c:378)

This is because on the final iteration the tok += 3 skips over the terminating
NUL to the next byte, and then *tok reads it. Fix this by using endptr as the
iterator.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

xen/arch/x86/domain.c | 12 8 + 4 - 0 !
xen/arch/x86/x86_64/compat/mm.c | 6 3 + 3 - 0 !
xen/common/compat/memory.c | 2 1 + 1 - 0 !
xen/include/xen/compat.h | 5 4 + 1 - 0 !
4 files changed, 16 insertions(+), 9 deletions(-)

 x86: limit checks in hypercall_xlat_continuation() to actual
 arguments

HVM/PVH guests can otherwise trigger the final BUG_ON() in that
function by entering 64-bit mode, setting the high halves of affected
registers to non-zero values, leaving 64-bit mode, and issuing a
hypercall that might get preempted and hence become subject to
continuation argument translation (HYPERVISOR_memory_op being the only
one possible for HVM, PVH also having the option of using
HYPERVISOR_mmuext_op). This issue got introduced when HVM code was
switched to use compat_memory_op() - neither that nor
hypercall_xlat_continuation() were originally intended to be used by
other than PV guests (which can't enter 64-bit mode and hence have no
way to alter the high halves of 64-bit registers).

This is CVE-2014-8866 / XSA-111.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

xen/arch/x86/hvm/intercept.c | 22 21 + 1 - 0 !
xen/arch/x86/hvm/vmsi.c | 4 4 + 0 - 0 !
2 files changed, 25 insertions(+), 1 deletion(-)

 x86/hvm: confine internally handled mmio to solitary regions

While it is generally wrong to cross region boundaries when dealing
with MMIO accesses of repeated string instructions (currently only
MOVS) as that would do things a guest doesn't expect (leaving aside
that none of these regions would normally be accessed with repeated
string instructions in the first place), this is even more of a problem
for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
made dereference NULL "entry" pointers this way) as well as undersized
(1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
space beyond the one memory page set up for holding LAPIC register
values).

Since those functions validly assume to be called only with addresses
their respective checking functions indicated to be okay, it is generic
code that needs to be fixed to clip the repetition count.

To be on the safe side (and consistent), also do the same for buffered
I/O intercepts, even if their only client (stdvga) doesn't put the
hypervisor at risk (i.e. "only" guest misbehavior would result).

This is CVE-2014-8867 / XSA-112.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

tools/libxc/xc_dom.h | 10 8 + 2 - 0 !
tools/libxc/xc_dom_bzimageloader.c | 20 20 + 0 - 0 !
tools/libxc/xc_dom_core.c | 61 47 + 14 - 0 !
tools/libxc/xc_dom_decompress_lz4.c | 5 5 + 0 - 0 !
4 files changed, 80 insertions(+), 16 deletions(-)

 libxc: don't leak buffer containing the uncompressed pv kernel

The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
is freed by xc_dom_release. However the various xc_try_*_decode routines (other
than the gzip one) just use plain malloc/realloc and therefore the buffer ends
up leaked.

The memory pool currently supports mmap'd buffers as well as a directly
allocated buffers, however the try decode routines make use of realloc and do
not fit well into this model. Introduce a concept of an external memory block
to the memory pool and provide an interface to register such memory.

The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
mmap_ prefix since they are now also used for external memory blocks.

We are only seeing this now because the gzip decoder doesn't leak and it's only
relatively recently that kernels in the wild have switched to better
compression.

This is https://bugs.debian.org/767295

Reported by: Gedalya <gedalya@gedalya.net>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

tools/libxl/libxl.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 tools: libxl: do not leak diskpath during local disk attach

libxl__device_disk_local_initiate_attach is assigning dls->diskpath with a
strdup of the device path. This is then passed to the callback, e.g.
parse_bootloader_result but bootloader_cleanup will not free it.

Since the callback is within the scope of the (e)gc and therefore doesn't need
to be malloc'd, a gc'd alloc will do. All other assignments to this field use
the gc.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295

Reported-by: Gedalya <gedalya@gedalya.net>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

xen/common/spinlock.c | 136 89 + 47 - 0 !
xen/include/asm-arm/arm32/spinlock.h | 78 0 + 78 - 0 !
xen/include/asm-arm/arm64/spinlock.h | 63 0 + 63 - 0 !
xen/include/asm-x86/spinlock.h | 54 0 + 54 - 0 !
xen/include/xen/spinlock.h | 6 4 + 2 - 0 !
5 files changed, 93 insertions(+), 244 deletions(-)

 switch to write-biased r/w locks

This is to improve fairness: A permanent flow of read acquires can
otherwise lock out eventual writers indefinitely.

This is CVE-2014-9065 / XSA-114.

Signed-off-by: Keir Fraser <keir@xen.org>

xen/arch/x86/hvm/hvm.c | 6 3 + 3 - 0 !
1 file changed, 3 insertions(+), 3 deletions(-)

 x86/hvm: prevent use-after-free when destroying a domain
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

hvm_domain_relinquish_resources() can free certain domain resources
which can still be accessed, e.g. by HVMOP_set_param, while the domain
is being cleaned up.

This is CVE-2015-0361 / XSA-116.

Signed-off-by: Mihai Donu <mdontu@bitdefender.com>
Tested-by: Rzvan Cojocaru <rcojocaru@bitdefender.com>

xen/arch/arm/vgic.c | 40 23 + 17 - 0 !
1 file changed, 23 insertions(+), 17 deletions(-)

 xen/arm: vgic: message in the emulation code should be rate-limited

printk is not rated-limited by default. Therefore a malicious guest may
be able to flood the Xen console.

If we use gdprintk, unecessary information will be printed such as the
filename and the line. Instead use XENLOG_G_ERR combine with %pv.

This is XSA-118.

Signed-off-by: Julien Grall <julien.grall@linaro.org>

xen/arch/x86/hvm/i8254.c | 1 1 + 0 - 0 !
xen/arch/x86/hvm/pmtimer.c | 1 1 + 0 - 0 !
xen/arch/x86/hvm/rtc.c | 3 2 + 1 - 0 !
xen/arch/x86/hvm/vpic.c | 1 1 + 0 - 0 !
4 files changed, 5 insertions(+), 1 deletion(-)

 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 CVE-2015-2044 / XSA-121.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

xen/common/kernel.c | 6 6 + 0 - 0 !
1 file changed, 6 insertions(+)

 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 CVE-2015-2045 / XSA-122.

Signed-off-by: Aaron Adams <Aaron.Adams@nccgroup.com>

xen/arch/x86/x86_emulate/x86_emulate.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 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.

Reported-by: Felix Wilhelm <fwilhelm@ernw.de>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

tools/libxl/libxl_dm.c | 21 19 + 2 - 0 !
1 file changed, 19 insertions(+), 2 deletions(-)

 tools: libxl: explicitly disable graphics backends on qemu cmdline

By default qemu will try to create some sort of backend for the
emulated VGA device, either SDL or VNC.

However when the user specifies sdl=0 and vnc=0 in their configuration
libxl was not explicitly disabling either backend, which could lead to
one unexpectedly running.

If either sdl=1 or vnc=1 is configured then both before and after this
change only the backends which are explicitly enabled are configured,
i.e. this issue only occurs when all backends are supposed to have
been disabled.

xen/include/asm-arm/arm64/page.h | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 xen: arm: correct arm64 version of gva_to_ma_par

The implementation was backwards and checked that the guest could
read when asked about write and vice versa.

This is an update to the fix for XSA-98.

Reported-by: Tamas K Lengyel <tklengyel@sec.in.tum.de>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
(cherry picked from commit c1245e9d5bf311b5a3267ea4b077a16561fcf439)
(cherry picked from commit 04ac29f0c38236840ed852b4fc0933d388a0e776)

tools/libxc/xc_domain.c | 55 50 + 5 - 0 !
xen/arch/x86/domctl.c | 5 5 + 0 - 0 !
xen/include/public/domctl.h | 1 1 + 0 - 0 !
3 files changed, 56 insertions(+), 5 deletions(-)

 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.

This is XSA-125 / CVE-2015-2752.

Suggested-by: Jan Beulich <jbeulich@suse.com>

xen/arch/x86/domctl.c | 8 8 + 0 - 0 !
xen/common/domctl.c | 6 4 + 2 - 0 !
2 files changed, 12 insertions(+), 2 deletions(-)

 domctl: don't allow a toolstack domain to call domain_pause() on
 itself

These DOMCTL subops were accidentally declared safe for disaggregation
in the wake of XSA-77.

This is XSA-127 / CVE-2015-2751.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

xen/common/grant_table.c | 3 3 + 0 - 0 !
1 file changed, 3 insertions(+)

---

xen/arch/x86/x86_64/compat/traps.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

---

xen/arch/x86/mm.c | 10 8 + 2 - 0 !
1 file changed, 8 insertions(+), 2 deletions(-)

---