Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 643350 (XSA-254) - <app-emulation/xen-4.9.2: Information leak via side effects of speculative execution (XSA-254)
Summary: <app-emulation/xen-4.9.2: Information leak via side effects of speculative ex...
Alias: XSA-254
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
Whiteboard: B4 [glsa+ cve]
Depends on:
Blocks: CVE-2017-5715 CVE-2017-5753 CVE-2017-5754
  Show dependency tree
Reported: 2018-01-04 01:25 UTC by GLSAMaker/CVETool Bot
Modified: 2018-10-30 21:06 UTC (History)
8 users (show)

See Also:
Package list:
app-emulation/xen-4.9.2 app-emulation/xen-tools-4.9.2-r1 app-emulation/xen-pvgrub-4.9.2
Runtime testing required: ---
stable-bot: sanity-check+


Note You need to log in before you can comment on or make changes to this bug.
Description GLSAMaker/CVETool Bot gentoo-dev 2018-01-04 01:25:39 UTC
Incoming details.
Comment 1 Thomas Deutschmann (RETIRED) gentoo-dev 2018-01-04 01:31:59 UTC
Hash: SHA256

 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
                              version 2

        Information leak via side effects of speculative execution


Added CVEs.


Processors give the illusion of a sequence of instructions executed
one-by-one.  However, in order to most efficiently use cpu resources,
modern superscalar processors actually begin executing many
instructions in parallel.  In cases where instructions depend on the
result of previous instructions or checks which have not yet
completed, execution happens based on guesses about what the outcome
will be.  If the guess is correct, execution has been sped up.  If the
guess is incorrect, partially-executed instructions are cancelled and
architectural state changes (to registers, memory, and so on)
reverted; but the whole process is no slower than if no guess had been
made at all.  This is sometimes called "speculative execution".

Unfortunately, although architectural state is rolled back, there are
other side effects, such as changes to TLB or cache state, which are
not rolled back.  These side effects can subsequently be detected by
an attacker to determine information about what happened during the
speculative execution phase.  If an attacker can cause speculative
execution to access sensitive memory areas, they may be able to infer
what that sensitive memory contained.

Furthermore, these guesses can often be 'poisoned', such that attacker
can cause logic to reliably 'guess' the way the attacker chooses.
This advisory discusses three ways to cause speculative execution to
access sensitive memory areas (named here according to the
discoverer's naming scheme):

SP1, "Bounds-check bypass": Poison the branch predictor, such that
operating system or hypervisor code is speculatively executed past
boundary and security checks.  This would allow an attacker to, for
instance, cause speculative code in the normal hypercall / emulation
path to execute with wild array indexes.

SP2, "Branch Target Injection": Poison the branch predictor.
Well-abstracted code often involves calling function pointers via
indirect branches; reading these function pointers may involve a
(slow) memory access, so the CPU attempts to guess where indirect
branches will lead.  Poisoning this enables an attacker to
speculatively branch to any code that exists in the hypervisor.

SP3, "Rogue Data Load": On some processors, certain pagetable
permission checks only happen when the instruction is retired;
effectively meaning that speculative execution is not subject to
pagetable permission checks.  On such processors, an attacker can
speculatively execute arbitrary code in userspace with, effectively,
the highest privilege level.

More information is available here:

Additional Xen-specific background:

64-bit Xen hypervisors on systems with less than 5TiB of RAM map all
of physical RAM, so code speculatively executed in a hypervisor
context can read all of system RAM.

When running PV guests, the guest and the hypervisor share the address
space; guest kernels run in a lower privilege level, and Xen runs in
the highest privilege level.  (HVM and PVH guests run in a separate
address space to the hypervisor.)  However, only 64-bit PV guests can
generate addresses large enough to point to hypervisor memory.


Xen guests may be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.

An attacker's choice of code to speculatively execute (and thus the
ease of extracting useful information) goes up with the numbers.  For
SP1, or SP2 on systems where SMEP (supervisor mode execute protection)
is enabled: an attacker is limited to windows of code after bound
checks of user-supplied indexes.  For SP2 without SMEP, or SP3, an
attacker can write arbitrary code to speculatively execute.


This vulnerability was originally scheduled to be made public on 9
January.  It was accelerated at the request of the discloser due to
one of the issues being made public.


Systems running all versions of Xen are affected.

For SP1 and SP2, both Intel and AMD are vulnerable.

For SP3, only Intel processors are vulnerable. Furthermore, only
64-bit PV guests can exploit SP3 against Xen.  PVH and 32-bit PV
guests cannot exploit SP3.

We believe that ARM is affected, but unfortunately due to the
accelerated schedule, we haven't been able to get concrete input from
ARM.  We are asking ARM and will publish more information when it is


There is no mitigation for SP1 and SP2.

SP3 can be mitigated by running guests in HVM or PVH mode.

For guests with legacy PV kernels which cannot be run in HVM mode, we
have developed a "shim" hypervisor that allows PV guests to run in PVH
mode.  Unfortunately, due to the accelerated schedule, this is not yet
ready to release.  We expect to have it ready for 4.10, as well as PVH
backports to 4.9 and 4.8, available over the next few days.


There is no available resolution for SP1 or SP3.

We are working on patches which mitigate SP2 but these are not
currently available.  Given that the vulnerabilities are now public,
these will be developed and published in public, initially via

When we have useful information we will send an update.


The timetable and process were set by the discloser.

After the intensive initial response period for these vulnerabilities
is over, we will prepare and publish a full timeline, as we have done
in a handful of other cases of significant public interest where we
saw opportunities for process improvement.
Version: GnuPG v1

Comment 2 Tomáš Mózes 2018-01-17 18:08:11 UTC
Xen page-table isolation patches are now available in staging branches:;a=shortlog;h=refs/heads/staging-4.9

dc7d46580d9c633a59be1c3776f79c01dd0cb98b x86: allow Meltdown band-aid to be disabled
1e0974638d65d9b8acf9ac7511d747188f38bcc3 x86: Meltdown band-aid against malicious 64-bit PV guests
87ea7816247090e8e5bc5653b16c412943a058b5 x86/mm: Always set _PAGE_ACCESSED on L4e updates
2213ffe1a2d82c3c9c4a154ea6ee252395aa8693 x86/entry: Remove support for partial cpu_user_regs frames
Comment 3 Aaron Bauman (RETIRED) gentoo-dev 2018-04-08 23:54:52 UTC
@maintainer(s), fix is in upstream 4.9.2 release.
Comment 4 Tomáš Mózes 2018-04-20 07:15:18 UTC
(In reply to Aaron Bauman from comment #3)
> @maintainer(s), fix is in upstream 4.9.2 release.

In tree now.
Comment 5 Mikle Kolyada (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2018-04-26 21:07:56 UTC
amd64 stable
Comment 6 Michael Boyle 2018-06-17 02:39:51 UTC
@maintainer(s), please drop vulnerable.

Michael Boyle
Security Padawan
Comment 7 Thomas Deutschmann (RETIRED) gentoo-dev 2018-09-10 09:37:49 UTC
Cleanup via commit 28d592b1c8dc9b24b3dfd923288c58f8e4ed27e6 and ff.

New GLSA request filed.
Comment 8 GLSAMaker/CVETool Bot gentoo-dev 2018-10-30 21:06:13 UTC
This issue was resolved and addressed in
 GLSA 201810-06 at
by GLSA coordinator Thomas Deutschmann (whissi).