XSA-206 Issue Description:

xenstored supports transactions, such that if writes which would
invalidate assumptions of a transaction occur, the entire transaction
fails. Typical response on a failed transaction is to simply retry
the transaction until it succeeds.

Unprivileged domains may issue writes to xenstore which conflict with
transactions either of the toolstack or of backends such as the driver
domain. Depending on the exact timing, repeated writes may cause
transactions made by these entities to fail indefinitely.

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

XSA-211 Issue Description:

When a graphics update command gets passed to the VGA emulator, there
are 3 possible modes that can be used to update the display:

• blank - Clears the display
• text - Treats the display as showing text
• graph - Treats the display as showing graphics

After the display geometry gets changed (i.e., after the CIRRUS VGA
emulation has resized the display), the VGA emulator will resize the
console during the next update command. However, when a blank mode is
also selected during an update, this resize doesn't happen. The resize
will be properly handled during the next time a non-blank mode is
selected during an update.

However, other console components - such as the VNC emulation - will
operate as though this resize had happened. When the display is
resized to be larger than before, this can result in a heap overflow
as console components will expect the display buffer to be larger than
it is currently allocated.

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

XSA-212 Issue Description:

The XSA-29 fix introduced an insufficient check on XENMEM_exchange
input, allowing the caller to drive hypervisor memory accesses outside
of the guest provided input/output arrays.

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

XSA-213 Issue Description:

64-bit PV guests typically use separate (root) page tables for their
kernel and user modes. Hypercalls are accessible to guest kernel
context only, which certain hypercall handlers make assumptions on.
The IRET hypercall (replacing the identically name CPU instruction)
is used by guest kernels to transfer control from kernel mode to user
mode. If such an IRET hypercall is placed in the middle of a multicall
batch, subsequent operations invoked by the same multicall batch may
wrongly assume the guest to still be in kernel mode. If one or more of
these subsequent operations involve operations on page tables, they may
be using the wrong root page table, confusing internal accounting. As
a result the guest may gain writable access to some of its page tables.

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

XSA-214 Issue Description:

The GNTTABOP_transfer operation allows one guest to transfer a page to
another guest. The internal processing of this, however, does not
include zapping the previous type of the page being transferred. This
makes it possible for a PV guest to transfer a page previously used as
part of a segment descriptor table to another guest while retaining the
"contains segment descriptors" property.

If the destination guest is a PV one of different bitness, it may gain
access to segment descriptors it is not normally allowed to have, like
64-bit code segments in a 32-bit PV guest.

If the destination guest is a HVM one, that guest may freely alter the
page contents and then hand the page back to the same or another PV
guest.

In either case, if the destination PV guest then inserts that page into
one of its own descriptor tables, the page still having the designated
type results in validation of its contents being skipped.

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

XSA-215 Issue Description:

Under certain special conditions Xen reports an exception resulting
from returning to guest mode not via ordinary exception entry points,
but via a so call failsafe callback. This callback, unlike exception
handlers, takes 4 extra arguments on the stack (the saved data
selectors DS, ES, FS, and GS). Prior to placing exception or failsafe
callback frames on the guest kernel stack, Xen checks the linear
address range to not overlap with hypervisor space. The range spanned
by that check was mistakenly not covering these extra 4 slots.

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

Motivation for this change

Latest security fixes for Xen 4.5.5.

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 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.