x86: populate-on-demand balloon size inaccuracy can crash guests

ISSUE DESCRIPTION

The design of the memory populate-on-demand (PoD) system requires that a guest’s memory ballooning driver reach its memory reduction target. The target is not entirely well-defined in terms of the information visible to the appropriate parts of the system, so some unknown set of guests (but probably most guests) will fail this criterion.
If the guest memory balloon driver does not free sufficient memory to reach its target, the guest will proceed to run with a nonzero number of outstanding PoD pages. When the guest or management toolstack touches such a page, the hypervisor would search the guest memory for a page containing only zeroes.
If no such page is found, the guest crashes. Prior to the patch for XSA-150, the search might lock up the relevant physical cpu for a while. After the patch to XSA-150, it might crash the guest even if a suitable zero page is available.
This means that in the current arrangements toolstack software must apply an adjustment to a guest’s PoD target as supplied to Xen. Neither xend nor libxl do this.

IMPACT

Guests configured with PoD might be unstable, especially under load.
In an affected guest, an unprivileged guest user might be able to cause a guest crash, perhaps simply by applying load so as to cause heavy memory pressure within the guest.
This problem also allows an unprivileged guest user to exercise the separate vulnerability described in XSA-150: an unprivileged guest user might be able to cause a denial of service affecting the host.

VULNERABLE SYSTEMS

The vulnerability is restricted to HVM guests which have been constructed in Populate-on-Demand mode (ie, with memory < maxmem).
ARM is not vulnerable. x86 PV VMs are not vulnerable. x86 HVM domains without PoD (ie started with memory==maxmem, or without mentioning “maxmem” in the guest config file) are not vulnerable.
Systems using libxl (whether via xl, or libvirt, or another higher layer) or xend (whether via xm, or libvirt, or another higher layer) are vulnerable.
If the system has been stress-tested (by imposing memory load on the guest) and found to be stable, it is less likely that the guest is vulnerable.
Combinations of Xen, guest, guest balloon driver, and toolstack software, which have an empirical adjustment as described in the Description, and which have been formally stress-tested in PoD mode, are less likely to be vulnerable.
Migration is not capable of creating a guest with outstanding PoD. So migrating a guest which is vulnerable might crash it. However, if a guest has been migrated successfully since it booted, it is no longer vulnerable.
Xen versions back to 3.4.x are affected.
Vulnerability of a particular guest can be tested by the host administrator using the utility `xsa153-check.c’, attached to this advisory.