XSA-216 Issue Description:

The block interface response structure has some discontiguous fields.
Certain backends populate the structure fields of an otherwise
uninitialized instance of this structure on their stacks, leaking
data through the (internal or trailing) padding field.

More: https://xenbits.xen.org/xsa/advisory-216.html

XSA-217 Issue Description:

Domains controlling other domains are permitted to map pages owned by
the domain being controlled. If the controlling domain unmaps such a
page without flushing the TLB, and if soon after the domain being
controlled transfers this page to another PV domain (via
GNTTABOP_transfer or, indirectly, XENMEM_exchange), and that third
domain uses the page as a page table, the controlling domain will have
write access to a live page table until the applicable TLB entry is
flushed or evicted. Note that the domain being controlled is
necessarily HVM, while the controlling domain is PV.

More: https://xenbits.xen.org/xsa/advisory-217.html

XSA-218 Issue Description:

We have discovered two bugs in the code unmapping grant references.

• When a grant had been mapped twice by a backend domain, and then
  unmapped by two concurrent unmap calls, the frontend may be informed
  that the page had no further mappings when the first call completed rather
  than when the second call completed.

• A race triggerable by an unprivileged guest could cause a grant
  maptrack entry for grants to be "freed" twice. The ultimate effect of
  this would be for maptrack entries for a single domain to be re-used.

More: https://xenbits.xen.org/xsa/advisory-218.html

XSA-219 Issue Description:

When using shadow paging, writes to guest pagetables must be trapped and
emulated, so the shadows can be suitably adjusted as well.

When emulating the write, Xen maps the guests pagetable(s) to make the final
adjustment and leave the guest's view of its state consistent.

However, when mapping the frame, Xen drops the page reference before
performing the write. This is a race window where the underlying frame can
change ownership.

One possible attack scenario is for the frame to change ownership and to be
inserted into a PV guest's pagetables. At that point, the emulated write will
be an unaudited modification to the PV pagetables whose value is under guest
control.

More: https://xenbits.xen.org/xsa/advisory-219.html

XSA-220 Issue Description:

Memory Protection Extensions (MPX) and Protection Key (PKU) are features in
newer processors, whose state is intended to be per-thread and context
switched along with all other XSAVE state.

Xen's vCPU context switch code would save and restore the state only
if the guest had set the relevant XSTATE enable bits. However,
surprisingly, the use of these features is not dependent (PKU) or may
not be dependent (MPX) on having the relevant XSTATE bits enabled.

VMs which use MPX or PKU, and context switch the state manually rather
than via XSAVE, will have the state leak between vCPUs (possibly,
between vCPUs in different guests). This in turn corrupts state in
the destination vCPU, and hence may lead to weakened protections

Experimentally, MPX appears not to make any interaction with BND*
state if BNDCFGS.EN is set but XCR0.BND{CSR,REGS} are clear. However,
the SDM is not clear in this case; therefore MPX is included in this
advisory as a precaution.

More: https://xenbits.xen.org/xsa/advisory-220.html

XSA-221 Issue Description:

When polling event channels, in general arbitrary port numbers can be
specified. Specifically, there is no requirement that a polled event
channel ports has ever been created. When the code was generalised
from an earlier implementation, introducing some intermediate
pointers, a check should have been made that these intermediate
pointers are non-NULL. However, that check was omitted.

More: https://xenbits.xen.org/xsa/advisory-221.html

XSA-222 Issue Description:

Certain actions require removing pages from a guest's P2M
(Physical-to-Machine) mapping. When large pages are in use to map
guest pages in the 2nd-stage page tables, such a removal operation may
incur a memory allocation (to replace a large mapping with individual
smaller ones). If this allocation fails, these errors are ignored by
the callers, which would then continue and (for example) free the
referenced page for reuse. This leaves the guest with a mapping to a
page it shouldn't have access to.

The allocation involved comes from a separate pool of memory created
when the domain is created; under normal operating conditions it never
fails, but a malicious guest may be able to engineer situations where
this pool is exhausted.

More: https://xenbits.xen.org/xsa/advisory-222.html

XSA-224 Issue Description:

We have discovered a number of bugs in the code mapping and unmapping
grant references.

• If a grant is mapped with both the GNTMAP_device_map and
  GNTMAP_host_map flags, but unmapped only with host_map, the device_map
  portion remains but the page reference counts are lowered as though it
  had been removed. This bug can be leveraged cause a page's reference
  counts and type counts to fall to zero while retaining writeable
  mappings to the page.

• Under some specific conditions, if a grant is mapped with both the
  GNTMAP_device_map and GNTMAP_host_map flags, the operation may not
  grab sufficient type counts. When the grant is then unmapped, the
  type count will be erroneously reduced. This bug can be leveraged
  cause a page's reference counts and type counts to fall to zero while
  retaining writeable mappings to the page.

• When a grant reference is given to an MMIO region (as opposed to a
  normal guest page), if the grant is mapped with only the
  GNTMAP_device_map flag set, a mapping is created at host_addr anyway.
  This does not cause reference counts to change, but there will be no
  record of this mapping, so it will not be considered when reporting
  whether the grant is still in use.

More: https://xenbits.xen.org/xsa/advisory-224.html

(cherry picked and adapted from commit 80e0cda)

Motivation for this change

Xen has released a new batch of security patches. This is a PR against release-17.03. Corresponding PR agains master can be found in #26867.

Things done

• Tested using sandboxing
  (nix.useSandbox on NixOS,
  or option build-use-sandbox in nix.conf
  on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • Linux
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.