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.

IMPACT
======

A malicious guest may be able to access memory it doesn't own,
potentially allowing privilege escalation, host crashes, or
information leakage.

VULNERABLE SYSTEMS
==================

Xen versions from at least 3.2 onwards are vulnerable.  Older versions
have not been inspected.

Both x86 and ARM systems are vulnerable.

On x86 systems, only HVM guests can leverage the vulnerability.

Mitigation:

On x86, specifying "hap_1gb=0 hap_2mb=0" on the hypervisor command
line will avoid the vulnerability.

Alternatively, running all x86 HVM guests in shadow mode will also
avoid this vulnerability.  (For example, by specifying "hap=0" in the
xl domain configuration file.)

There is no known mitigation on ARM systems.

External References:

http://xenbits.xen.org/xsa/advisory-222.html

Acknowledgements:

Name: the Xen project
Upstream: Julien Grall (ARM)