gnttab: Fix handling of dev_bus_addr during unmap

If a grant has been mapped with the GNTTAB_device_map flag, calling
grant_unmap_ref() with dev_bus_addr set to zero should cause the
GNTTAB_device_map part of the mapping to be left alone.

Unfortunately, at the moment, op->dev_bus_addr is implicitly checked
before clearing the map and adjusting the pin count, but only the bits
above 12; and it is not checked at all before dropping page
references.  This means a guest can repeatedly make such a call to
cause the reference count to drop to zero, causing the page to be
freed and re-used, even though it's still mapped in its pagetables.

To fix this, always check op->dev_bus_addr explicitly for being
non-zero, as well as op->flag & GNTMAP_device_map, before doing
operations on the device_map.

While we're here, make the logic a bit cleaner:

* Always initialize op->frame to zero and set it from act->frame, to reduce the
chance of untrusted input being used

* Explicitly check the full dev_bus_addr against act->frame <<
  PAGE_SHIFT, rather than ignoring the lower 12 bits

This is part of XSA-224.

Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Gbp-Pq: Name gnttab-fix-handling-of-dev_bus_addr-duri

arm: vgic: Don't update the LR when the IRQ is not enabled

gic_raise_inflight_irq will be called if the IRQ is already inflight
(i.e the IRQ is injected to the guest). If the IRQ is already already in
the LRs, then the associated LR will be updated.

To know if the interrupt is already in the LR, the function check if the
interrupt is queued. However, if the interrupt is not enabled then the
interrupt may not be queued nor in the LR. So gic_update_one_lr may be
called (if we inject on the current vCPU) and read the LR.

Because the interrupt is not in the LR, Xen will either read:
    * LR 0 if the interrupt was never injected before
    * LR 255 (GIC_INVALID_LR) if the interrupt was injected once. This
    is because gic_update_one_lr will reset p->lr.

Reading LR 0 will result to potentially update the wrong interrupt and
not keep the LRs in sync with Xen.

Reading LR 255 will result to:
    * Crash Xen on GICv3 as the LR index is bigger than supported (see
    gicv3_ich_read_lr).
    * Read/write always GICH_LR + 255 * 4 that is not part of the memory
    mapped.

The problem can be prevented by checking whether the interrupt is
enabled in gic_raise_inflight_irq before calling gic_update_one_lr.

A follow-up of this patch is expected to mitigate the issue in the
future.

This is XSA-223.

Reported-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Gbp-Pq: Name arm-vgic-dont-update-the-lr-when-the-irq

guest_physmap_remove_page() needs its return value checked

Callers, namely such subsequently freeing the page, must not blindly
assume success - the function may namely fail when needing to shatter a
super page, but there not being memory available for the then needed
intermediate page table.

As it happens, guest_remove_page() callers now also all check the
return value.

Furthermore a missed put_gfn() on an error path in gnttab_transfer() is
also being taken care of.

This is part of XSA-222.

Reported-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Gbp-Pq: Name guest_physmap_remove_page-needs-its-retu

xen/memory: Fix return value handing of guest_remove_page()

Despite the description in mm.h, guest_remove_page() previously returned 0 for
paging errors.

Switch guest_remove_page() to having regular 0/-error semantics, and propagate
the return values from clear_mmio_p2m_entry() and mem_sharing_unshare_page()
to the callers (although decrease_reservation() is the only caller which
currently cares).

This is part of XSA-222.

Reported-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Gbp-Pq: Name xenmemory-fix-return-value-handing-of-gu

evtchn: avoid NULL derefs

Commit fbbd5009e6 ("evtchn: refactor low-level event channel port ops")
added a de-reference of the struct evtchn pointer for a port without
first making sure the bucket pointer is non-NULL. This de-reference is
actually entirely unnecessary, as all relevant callers (beyond the
problematic do_poll()) already hold the port number in their hands, and
the actual leaf functions need nothing else.

For FIFO event channels there's a second problem in that the ordering
of reads and updates to ->num_evtchns and ->event_array[] was so far
undefined (the read side isn't always holding the domain's event lock).
Add respective barriers.

This is XSA-221.

Reported-by: Ankur Arora <ankur.a.arora@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Gbp-Pq: Name evtchn-avoid-null-derefs

x86: avoid leaking PKRU and BND* between vCPU-s

PKRU is explicitly "XSAVE-managed but not XSAVE-enabled", so guests
might access the register (via {RD,WR}PKRU) without setting XCR0.PKRU.
Force context switching as well as migrating the register as soon as
CR4.PKE is being set the first time.

For MPX (BND<n>, BNDCFGU, and BNDSTATUS) the situation is less clear,
and the SDM has not entirely consistent information for that case.
While experimentally the instructions don't change register state as
long as the two XCR0 bits aren't both 1, be on the safe side and enable
both if BNDCFGS.EN is being set the first time.

This is XSA-220.

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Gbp-Pq: Name x86-avoid-leaking-pkru-and-bnd-between-v

x86/shadow: Hold references for the duration of emulated writes

The (misnamed) emulate_gva_to_mfn() function translates a linear address to an
mfn, but releases its page reference before returning the mfn to its caller.

sh_emulate_map_dest() uses the results of one or two translations to construct
a virtual mapping to the underlying frames, completes an emulated
write/cmpxchg, then unmaps the virtual mappings.

The page references need holding until the mappings are unmapped, or the
frames can change ownership before the writes occurs.

This is XSA-219

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Gbp-Pq: Name x86shadow-hold-references-for-the-durati

gnttab: correct maptrack table accesses

In order to observe a consistent (limit,pointer-table) pair, the reader
needs to either hold the maptrack lock (in line with documentation) or
both sides need to order their accesses suitably (the writer side
barrier was removed by commit dff515dfea ["gnttab: use per-VCPU
maptrack free lists"], and a read side barrier has never been there).

Make the writer publish a new table page before limit (for bounds
checks to work), and new list head last (for racing maptrack_entry()
invocations to work). At the same time add read barriers to lockless
readers.

Additionally get_maptrack_handle() must not assume ->maptrack_head to
not change behind its back: Another handle may be put (updating only
->maptrack_tail) and then got or stolen (updating ->maptrack_head).

This is part of XSA-218.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Gbp-Pq: Name gnttab-correct-maptrack-table-accesses

gnttab: Avoid potential double-put of maptrack entry

Each grant mapping for a particular domain is tracked by an in-Xen
"maptrack" entry.  This entry is is referenced by a "handle", which is
given to the guest when it calls gnttab_map_grant_ref().

There are two types of mapping a particular handle can refer to:
GNTMAP_host_map and GNTMAP_device_map.  A given
gnttab_unmap_grant_ref() call can remove either only one or both of
these entries.  When a particular handle has no entries left, it must
be freed.

gnttab_unmap_grant_ref() loops through its grant unmap request list
twice.  It first removes entries from any host pagetables and (if
appropraite) iommus; then it does a single domain TLB flush; then it
does the clean-up, including telling the granter that entries are no
longer being used (if appropriate).

At the moment, it's during the first pass that the maptrack flags are
cleared, but the second pass that the maptrack entry is freed.

Unfortunately this allows the following race, which results in a
double-free:

 A: (pass 1) clear host_map
 B: (pass 1) clear device_map
 A: (pass 2) See that maptrack entry has no mappings, free it
 B: (pass 2) See that maptrack entry has no mappings, free it #

Unfortunately, unlike the active entry pinning update, we can't simply
move the maptrack flag changes to the second half, because the
maptrack flags are used to determine if iommu entries need to be
added: a domain's iommu must never have fewer permissions than the
maptrack flags indicate, or a subsequent map_grant_ref() might fail to
add the necessary iommu entries.

Instead, free the maptrack entry in the first pass if there are no
further mappings.

This is part of XSA-218.

Reported-by: Jan Beulich <jbeulich.com>
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Gbp-Pq: Name gnttab-avoid-potential-double-put-of-map

gnttab: fix unmap pin accounting race

Once all {writable} mappings of a grant entry have been unmapped, the
hypervisor informs the guest that the grant entry has been released by
clearing the _GTF_{reading,writing} usage flags in the guest's grant
table as appropriate.

Unfortunately, at the moment, the code that updates the accounting
happens in a different critical section than the one which updates the
usage flags; this means that under the right circumstances, there may be
a window in time after the hypervisor reported the grant as being free
during which the grant referee still had access to the page.

Move the grant accounting code into the same critical section as the
reporting code to make sure this kind of race can't happen.

This is part of XSA-218.

Reported-by: Jann Horn <jannh.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Gbp-Pq: Name gnttab-fix-unmap-pin-accounting-race

x86/mm: disallow page stealing from HVM domains

The operation's success can't be controlled by the guest, as the device
model may have an active mapping of the page. If we nevertheless
permitted this operation, we'd have to add further TLB flushing to
prevent scenarios like

"Domains A (HVM), B (PV), C (PV); B->target==A
 Steps:
 1. B maps page X from A as writable
 2. B unmaps page X without a TLB flush
 3. A sends page X to C via GNTTABOP_transfer
 4. C maps page X as pagetable (potentially causing a TLB flush in C,
 but not in B)

 At this point, X would be mapped as a pagetable in C while being
 writable through a stale TLB entry in B."

A similar scenario could be constructed for A using XENMEM_exchange and
some arbitrary PV domain C then having this page allocated.

This is XSA-217.

Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Gbp-Pq: Name x86mm-disallow-page-stealing-from-hvm-do

x86: discard type information when stealing pages

While a page having just a single general reference left necessarily
has a zero type reference count too, its type may still be valid (and
in validated state; at present this is only possible and relevant for
PGT_seg_desc_page, as page tables have their type forcibly zapped when
their type reference count drops to zero, and
PGT_{writable,shared}_page pages don't require any validation). In
such a case when the page is being re-used with the same type again,
validation is being skipped. As validation criteria differ between
32- and 64-bit guests, pages to be transferred between guests need to
have their validation indicator zapped (and with it we zap all other
type information at once).

This is XSA-214.

Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Gbp-Pq: Name x86-discard-type-information-when-steali

multicall: deal with early exit conditions

In particular changes to guest privilege level require the multicall
sequence to be aborted, as hypercalls are permitted from kernel mode
only. While likely not very useful in a multicall, also properly handle
the return value in the HYPERVISOR_iret case (which should be the guest
specified value).

This is XSA-213.

Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Gbp-Pq: Name multicall-deal-with-early-exit-condition

tools/tests/x86_emulator: Pass -no-pie -fno-pic to gcc on x86_32

The current build fails with GCC6 on Debian sid i386 (unstable):

 /tmp/ccqjaueF.s: Assembler messages:
 /tmp/ccqjaueF.s:3713: Error: missing or invalid displacement expression `vmovd_to_reg_len@GOT'

This is due to the combination of GCC6, and Debian's decision to
enable some hardening flags by default (to try to make runtime
addresses less predictable):
  https://wiki.debian.org/Hardening/PIEByDefaultTransition

This is of no benefit for the x86 instruction emulator test, which is
a rebuild of the emulator code for testing purposes only.  So pass
options to disable this.

These options will be no-ops if they are the same as the compiler
default.

On amd64, the -fno-pic breaks the build in a different way.  So do
this only on i386.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
squash! tools/tests/x86_emulator: Pass -no-pie -fno-pic to gcc

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Gbp-Pq: Name toolstestsx86_emulator-pass--no-pie--fno

ubuntu-tools-libs-abiname

Gbp-Pq: Name ubuntu-tools-libs-abiname.diff

tools-xenstore-compatibility.diff

Patch-Name: tools-xenstore-compatibility.diff

Gbp-Pq: Name tools-xenstore-compatibility.diff

tools-xenmon-install.diff

Patch-Name: tools-xenmon-install.diff

Gbp-Pq: Name tools-xenmon-install.diff

tools-include-install.diff

Patch-Name: tools-include-install.diff

Gbp-Pq: Name tools-include-install.diff

Remove static solaris support from pygrub

Patch-Name: tools-pygrub-remove-static-solaris-support

Gbp-Pq: Name tools-pygrub-remove-static-solaris-support

tools-xentrace-prefix.diff

Patch-Name: tools-xentrace-prefix.diff

Gbp-Pq: Name tools-xentrace-prefix.diff

tools-xenstore-prefix.diff

Patch-Name: tools-xenstore-prefix.diff

Gbp-Pq: Name tools-xenstore-prefix.diff

tools-xenstat-prefix.diff

Patch-Name: tools-xenstat-prefix.diff

Gbp-Pq: Name tools-xenstat-prefix.diff

tools-xenpmd-prefix.diff

Patch-Name: tools-xenpmd-prefix.diff

Gbp-Pq: Name tools-xenpmd-prefix.diff

tools-xenpaging-prefix.diff

Patch-Name: tools-xenpaging-prefix.diff

Gbp-Pq: Name tools-xenpaging-prefix.diff

tools-xenmon-prefix.diff

Patch-Name: tools-xenmon-prefix.diff

Gbp-Pq: Name tools-xenmon-prefix.diff

tools-xcutils-rpath.diff

Patch-Name: tools-xcutils-rpath.diff

Gbp-Pq: Name tools-xcutils-rpath.diff

tools-python-prefix.diff

Patch-Name: tools-python-prefix.diff

Gbp-Pq: Name tools-python-prefix.diff

tools-pygrub-prefix.diff

Patch-Name: tools-pygrub-prefix.diff

Gbp-Pq: Name tools-pygrub-prefix.diff

tools-misc-prefix.diff

Patch-Name: tools-misc-prefix.diff

Gbp-Pq: Name tools-misc-prefix.diff

tools-libxl-prefix.diff

Patch-Name: tools-libxl-prefix.diff

Gbp-Pq: Name tools-libxl-prefix.diff

tools-libfsimage-prefix.diff

Patch-Name: tools-libfsimage-prefix.diff

Gbp-Pq: Name tools-libfsimage-prefix.diff

tools-console-prefix.diff

Patch-Name: tools-console-prefix.diff

Gbp-Pq: Name tools-console-prefix.diff

tools-blktap2-prefix.diff

Patch-Name: tools-blktap2-prefix.diff

Gbp-Pq: Name tools-blktap2-prefix.diff

tools-rpath.diff

Patch-Name: tools-rpath.diff

Gbp-Pq: Name tools-rpath.diff

tools-xenstat-abiname.diff

Patch-Name: tools-xenstat-abiname.diff

Gbp-Pq: Name tools-xenstat-abiname.diff

tools-libxl-abiname.diff

Patch-Name: tools-libxl-abiname.diff

Gbp-Pq: Name tools-libxl-abiname.diff

tools-libxc-abiname.diff

Patch-Name: tools-libxc-abiname.diff

Gbp-Pq: Name tools-libxc-abiname.diff

tools-libfsimage-abiname.diff

Patch-Name: tools-libfsimage-abiname.diff

Gbp-Pq: Name tools-libfsimage-abiname.diff

config-prefix.diff

Patch-Name: config-prefix.diff

Gbp-Pq: Name config-prefix.diff

version

Patch-Name: version.diff

Gbp-Pq: Name version.diff

Rerun autogen.sh (stretch)

Using autoconf 2.69-10 (amd64)

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Gbp-Pq: Name rerun-autogen.sh-stretch

xen (4.8.1-1+deb9u3) stretch-security; urgency=high

  * Security fixes for
      XSA-226 CVE-2017-12135
      XSA-227 CVE-2017-12137
      XSA-228 CVE-2017-12136
      XSA-230 CVE-2017-12855
      XSA-235 (no CVE yet)
  * Adjust changelog entry for 4.8.1-1+deb9u2 to record
    that XSA-225 fix was indeed included.
  * Security fix for XSA-229 not included as that bug is in Linux, not Xen.
  * Security fixes for XSA-231..234 inc. not inclued as still embargoed.

[dgit import unpatched xen 4.8.1-1+deb9u3]

Import xen_4.8.1-1+deb9u3.debian.tar.xz

[dgit import tarball xen 4.8.1-1+deb9u3 xen_4.8.1-1+deb9u3.debian.tar.xz]

Import xen_4.8.1.orig.tar.gz

[dgit import orig xen_4.8.1.orig.tar.gz]