-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

     Xen Security Advisory CVE-2016-3158,CVE-2016-3159 / XSA-172
                              version 3

              broken AMD FPU FIP/FDP/FOP leak workaround

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

There is a workaround in Xen to deal with the fact that AMD CPUs don't
load the x86 registers FIP (and possibly FCS), FDP (and possibly FDS),
and FOP from memory (via XRSTOR or FXRSTOR) when there is no pending
unmasked exception.  (See XSA-52.)

However, this workaround does not cover all possible input cases.
This is because writes to the hardware FSW.ES bit, which the current
workaround is based on, are ignored; instead, the CPU calculates
FSW.ES from the pending exception and exception mask bits.  Xen
therefore needs to do the same.

Note that part of said workaround was the subject of XSA-52.

This can leak register contents from one guest to another.  The
registers in question are the FPU instruction and data pointers and
opcode.

IMPACT
======

A malicious domain is able to obtain address space usage and timing
information, about another domain, at a fairly low rate.

The leaked address information might be used to help defeat address
space randomisation in order to enable another attack.  The leaked
address and timing information forms a low-bandwidth covert channel
which might be used to gain information about the operation of a
target guest.

The affected FPU facility would not normally be used by cryptographic
operations, as it does not provide cryptographically-relevant SIMD
functions.

It appears to us very unlikely that the leak might directly compromise
sensitive information such as cryptographic keys, although (without
knowledge of the guest software) this cannot be ruled out.  (This is
notwithstanding the contrary statement in `Impact' in XSA-52.)

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

Xen versions 4.0 and onwards are vulnerable.  Any kind of guest can
exploit the vulnerability.

The vulnerability is exposed only on AMD x86 systems.  Intel and ARM
systems do not expose this vulnerability.

Both PV and HVM guests are affected.

MITIGATION
==========

The vulnerability can be avoided if the guest kernel is controlled by
the host rather than guest administrator, provided that further steps
are taken to prevent the guest administrator from loading code into
the kernel (e.g. by disabling loadable modules etc) or from using
other mechanisms which allow them to run code at kernel privilege.

On Xen versions 4.3 and earlier, turning off XSAVE support via the
"no-xsave" hypervisor command line option will avoid the vulnerability.

On Xen versions 4.4 and onwards there is no other known mitigation.

CREDITS
=======

This issue was discovered by Jan Beulich from SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa172.patch           xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x
xsa172-4.3.patch       Xen 4.3.x

$ sha256sum xsa172*
f18282fcb794b8772bc3af51d56860050071bd62a5a909b8f2fc2018e2958154  xsa172.patch
6aac179620afcdbdab041163239019bc35b0e243f3bd16673caaec7d5a4d97ec  xsa172-4.3.patch
$

NOTE REGARDING CVE
==================

CVE-2016-3158 is for the code change which is required for all
versions (but which is sufficient only on Xen 4.3.x, and insufficient
on later versions).  Ie for the second hunk in xsa172.patch (the only
hunk in xsa172-4.3.patch), which patches the function xrstor.

CVE-2016-3159 is for the code change which is applicable for later
versions only, but which must always be combined with the code change
for CVE-2016-3158.  Ie for the first hunk in xsa172.patch, which
patches the function fpu_fxrstor.

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the PATCH or the TRUSTED KERNEL MITIGATION (or others
which are substantially similar) is permitted during the embargo, even
on public-facing systems with untrusted guest users and
administrators.

However deployment of the "no-xsave" MITIGATION is NOT permitted
(except where all the affected systems and VMs are administered and
used only by organisations which are members of the Xen Project
Security Issues Predisclosure List).  Specifically, deployment on
public cloud systems is NOT permitted.

This is because such a host configuration change would be guest-visible
which could lead to the rediscovery of the vulnerability.

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


(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:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJW9BUjAAoJEIP+FMlX6CvZh0sH/RMRw5mKOjz4IPUFVlxXvJYr
4BYbJyitDX6uX6Hdp8XosqrMfTqpDWNYzTPS4UMOmSZq0JSSSeRDB5esM3otQSzl
Vnq8toyl2IeDZAZ7KhLTOUGF1libSGyE32MCLP32XOwbAaWRD01ld71M4P2+Cmuz
JFqgfRQxgqzcrfZP74CqfbAdU9sxIq5Py6BHBdSOlKuZMF7RPZbIpy2KwdAmIUZJ
IXnwlWvXvg5Uq3RfzRPJ10EaaQhIajgSxGGOViVXEVObY48jbcXFB3xTTT49CMB2
GqNK+CjUTVvfTFe2jFYu1Uscwot85tgsu09zui3Jleml1dhs6eIM4vKcLG96g1E=
=ojN8
-----END PGP SIGNATURE-----