|Public release ||2016-10-04 12:00|
|Updated ||2016-10-04 12:50|
|Title ||CR0.TS and CR0.EM not always honored for x86 HVM guests|
Filesadvisory-190.txt (signed advisory file)
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2016-7777 / XSA-190
CR0.TS and CR0.EM not always honored for x86 HVM guests
UPDATES IN VERSION 5
Instructions touching FPU, MMX, or XMM registers are required to raise
a Device Not Available Exception (#NM) when either CR0.EM or CR0.TS are
set. (Their AVX or AVX-512 extensions would consider only CR0.TS.)
While during normal operation this is ensured by the hardware, if a
guest modifies instructions while the hypervisor is preparing to
emulate them, the #NM delivery could be missed.
Guest code in one task may thus (unintentionally or maliciously) read
or modify register state belonging to another task in the same VM.
A malicious unprivileged guest user may be able to obtain or corrupt
sensitive information (including cryptographic material) in other
programs in the same guest.
All versions of Xen expose the vulnerabilty to their x86 HVM guests.
In order to exploit the vulnerability, the attacker needs to be able to
trigger the Xen instruction emulator.
On Xen 4.7 the emulator can only be triggered: by user mode tasks which
have been given access to memory-mapped IO; in guests which have been
migrated between systems with CPUs from different vendors; or in guests
which have been configured with a CPU vendor different from the host's.
On Xen 4.6 and earlier, all HVM guests can trigger the emulator by
attempting to execute an invalid opcode, exposing the vulnerability.
The vulnerability is only exposed to x86 HVM guests.
The vulnerability is not exposed to x86 PV or ARM guests.
On Xen 4.7, not migrating across CPU vendors will avoid this
vulnerability. (Unless the guest grants mmio access to unprivileged
tasks, or has been configured with a specific CPU vendor, eg using the
xl "cpuid" configuraton option.)
This issue was discovered by Jan Beulich from SUSE.
Applying the appropriate attached patch resolves this issue.
xsa190.patch xen-unstable, Xen 4.7.x
xsa190-4.6.patch Xen 4.6.x
xsa190-4.5.patch Xen 4.5.x, Xen 4.4.x
$ sha256sum xsa190*
DEPLOYMENT DURING EMBARGO
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
Xenproject.org Security Team