Discussion:
Xen Security Advisory 254 (CVE-2017-5753,CVE-2017-5715,CVE-2017-5754) - Information leak via side effects of speculative execution
(too old to reply)
Xen.org security team
2018-01-11 20:09:11 UTC
Permalink
Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
version 4

Information leak via side effects of speculative execution

UPDATES IN VERSION 4
====================

Added README for determining which shim to use, as well as
instructions for using "Vixen" (HVM shim) and the required
conversion script

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

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):

"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim 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.

"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
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 is
executable by the victim (eg, anywhere in the hypervisor).

"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
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:
https://meltdownattack.com/
https://spectreattack.com/
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

Additional Xen-specific background:

Xen hypervisors on most systems 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. (x86 HVM and PVH guests, and ARM 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.

IMPACT
======

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, an attacker is limited to windows of code after bound checks of
user-supplied indexes. For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.

Additionally, in general, attacks within a guest (from guest user to
guest kernel) will be the same as on real hardware. Consult your
operating system provider for more information.

NOTE ON TIMING
==============

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.

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

Systems running all versions of Xen are affected.

For SP1 and SP2, both Intel and AMD are vulnerable. Vulnerability of
ARM processors to SP1 and SP2 varies by model and manufacturer. ARM
has information on affected models on the following website:
https://developer.arm.com/support/security-update

For SP3, only Intel processors are vulnerable. (The hypervisor cannot
be attacked using SP3 on any ARM processors, even those that are
listed as affected by SP3.)

Furthermore, only 64-bit PV guests can exploit SP3 against Xen. PVH,
HVM, and 32-bit PV guests cannot exploit SP3.

MITIGATION
==========

There is no mitigation for SP1 and SP2.

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

RESOLUTION
==========

There is no available resolution for SP1. A solution may be available
in the future.

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
xen-devel.

For guests with legacy PV kernels which cannot be run in HVM or PVH
mode directly, we have developed two "shim" hypervisors that allow PV
guests to run in HVM mode or PVH mode. The HVM shim (codenamed
"Vixen") is available now. We expect to have the PVH shim (codenamed
"Comet") available within a few days. Please read README.which-shim
to determine which shim is suitable for you.

$ sha256sum xsa254*/*
2df6b811ec7a377a9cc717f7a8ed497f3a90928c21cba81182eb4a802e32ecd7 xsa254/README.vixen
bc04385fd3ec899e1b8c1c001b6169587a8a8b20d5d0d584ff749b7ed67d7e70 xsa254/README.which-shim
36e825118fa8fca30158e50607580ddf64f6c62e5c5127d87d0042fbe2ff37b2 xsa254/pvshim-converter.pl
$


NOTE ON LACK OF EMBARGO
=======================

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.
Xen.org security team
2018-01-12 12:15:59 UTC
Permalink
Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
version 5

Information leak via side effects of speculative execution

UPDATES IN VERSION 5
====================

PV-in-PVH/HVM shim approach leaves *guest* vulnerable to Meltdown
attacks from its unprivileged users, even if the guest has KPTI
patches. That is, guest userspace can use Meltdown to read all memory
in the same guest.

In Vixen shim sidecar creator script, look for qemu in some more
places, and provide a command line option to specify the
qemu-system-i386 to use in case the default doesn't find it.

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

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):

"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim 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.

"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
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 is
executable by the victim (eg, anywhere in the hypervisor).

"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
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:
https://meltdownattack.com/
https://spectreattack.com/
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

Additional Xen-specific background:

Xen hypervisors on most systems 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. (x86 HVM and PVH guests, and ARM 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.

IMPACT
======

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, an attacker is limited to windows of code after bound checks of
user-supplied indexes. For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.

Additionally, in general, attacks within a guest (from guest user to
guest kernel) will be the same as on real hardware. Consult your
operating system provider for more information.

NOTE ON TIMING
==============

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.

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

Systems running all versions of Xen are affected.

For SP1 and SP2, both Intel and AMD are vulnerable. Vulnerability of
ARM processors to SP1 and SP2 varies by model and manufacturer. ARM
has information on affected models on the following website:
https://developer.arm.com/support/security-update

For SP3, only Intel processors are vulnerable. (The hypervisor cannot
be attacked using SP3 on any ARM processors, even those that are
listed as affected by SP3.)

Furthermore, only 64-bit PV guests can exploit SP3 against Xen. PVH,
HVM, and 32-bit PV guests cannot exploit SP3.

MITIGATION
==========

There is no mitigation for SP1 and SP2.

SP3 can be mitigated by running guests in HVM or PVH mode.
(Within-guest attacks are still possible unless the guest OS has also
been updated with an SP3 mitigation series such as KPTI/Kaiser.)

For guests with legacy PV kernels which cannot be run in HVM or PVH
mode directly, we have developed two "shim" hypervisors that allow PV
guests to run in HVM mode or PVH mode. This prevents attacks on the
host, but it leaves the guest vulnerable to Meltdown attacks by its
own unprivileged processes, even if the guest OS has KPTI or similar
Meltdown mitigation.

The HVM shim (codenamed "Vixen") is available now. We expect to have
the PVH shim (codenamed "Comet") available within a few days. Please
read README.which-shim to determine which shim is suitable for you.

$ sha256sum xsa254*/*
2df6b811ec7a377a9cc717f7a8ed497f3a90928c21cba81182eb4a802e32ecd7 xsa254/README.vixen
4c30295513ad82debe04845248b5baac0b3d0c151b80fdca32f2df8b9aa0b541 xsa254/README.which-shim
6210615c1384e13da953452e6f47066f8837e2b2c7f671280902e32e96763b54 xsa254/pvshim-converter.pl
$

RESOLUTION
==========

There is no available resolution for SP1. A solution may be available
in the future.

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
xen-devel.


NOTE ON LACK OF EMBARGO
=======================

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.
Xen.org security team
2018-01-12 17:36:32 UTC
Permalink
Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
version 6

Information leak via side effects of speculative execution

UPDATES IN VERSION 6
====================

PVH shim ("Comet") for 4.10 is available.

Mention within-guest attack in README.vixen as well as
README.which-shim.

Vixen shim converter script "exec"s qemu, avoiding stale qemu
processes (and, therefore, avoiding stale domains).

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

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):

"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim 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.

"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
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 is
executable by the victim (eg, anywhere in the hypervisor).

"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
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:
https://meltdownattack.com/
https://spectreattack.com/
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

Additional Xen-specific background:

Xen hypervisors on most systems 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. (x86 HVM and PVH guests, and ARM 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.

IMPACT
======

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, an attacker is limited to windows of code after bound checks of
user-supplied indexes. For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.

Additionally, in general, attacks within a guest (from guest user to
guest kernel) will be the same as on real hardware. Consult your
operating system provider for more information.

NOTE ON TIMING
==============

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.

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

Systems running all versions of Xen are affected.

For SP1 and SP2, both Intel and AMD are vulnerable. Vulnerability of
ARM processors to SP1 and SP2 varies by model and manufacturer. ARM
has information on affected models on the following website:
https://developer.arm.com/support/security-update

For SP3, only Intel processors are vulnerable. (The hypervisor cannot
be attacked using SP3 on any ARM processors, even those that are
listed as affected by SP3.)

Furthermore, only 64-bit PV guests can exploit SP3 against Xen. PVH,
HVM, and 32-bit PV guests cannot exploit SP3.

MITIGATION
==========

There is no mitigation for SP1 and SP2.

SP3 can be mitigated by running guests in HVM or PVH mode.
(Within-guest attacks are still possible unless the guest OS has also
been updated with an SP3 mitigation series such as KPTI/Kaiser.)

For guests with legacy PV kernels which cannot be run in HVM or PVH
mode directly, we have developed two "shim" hypervisors that allow PV
guests to run in HVM mode or PVH mode. This prevents attacks on the
host, but it leaves the guest vulnerable to Meltdown attacks by its
own unprivileged processes, even if the guest OS has KPTI or similar
Meltdown mitigation.

The HVM shim (codenamed "Vixen") is available now, as is the PVH shim
(codenamed "Comet") for Xen 4.10. We expect to have Comet for 4.8 and
4.9 within a few days. Please read README.which-shim to determine
which shim is suitable for you.

$ sha256sum xsa254*/*
f81c4624f8b188a2c33efa8687d3442bbd17c476e1a10761ef70c0aa99f6c659 xsa254/README.comet
1c594822dbd95998951203f6094bc77586d5720788de15897784d20bacb2ef08 xsa254/README.vixen
7e816160c1c1d1cd93ec3c3dd9753c8f3957fefe86b7aa967e9e77833828f849 xsa254/README.which-shim
1d2098ad3890a5be49444560406f8f271c716e9f80e7dfe11ff5c818277f33f8 xsa254/pvshim-converter.pl
$

RESOLUTION
==========

There is no available resolution for SP1. A solution may be available
in the future.

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
xen-devel.


NOTE ON LACK OF EMBARGO
=======================

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.
Xen.org security team
2018-01-12 17:46:54 UTC
Permalink
Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
version 7

Information leak via side effects of speculative execution

UPDATES IN VERSION 7
====================

PVH shim ("Comet") for 4.10 tag correction: please use tag
4.10.0-shim-comet-1.1.

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

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):

"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim 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.

"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
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 is
executable by the victim (eg, anywhere in the hypervisor).

"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
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:
https://meltdownattack.com/
https://spectreattack.com/
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

Additional Xen-specific background:

Xen hypervisors on most systems 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. (x86 HVM and PVH guests, and ARM 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.

IMPACT
======

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, an attacker is limited to windows of code after bound checks of
user-supplied indexes. For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.

Additionally, in general, attacks within a guest (from guest user to
guest kernel) will be the same as on real hardware. Consult your
operating system provider for more information.

NOTE ON TIMING
==============

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.

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

Systems running all versions of Xen are affected.

For SP1 and SP2, both Intel and AMD are vulnerable. Vulnerability of
ARM processors to SP1 and SP2 varies by model and manufacturer. ARM
has information on affected models on the following website:
https://developer.arm.com/support/security-update

For SP3, only Intel processors are vulnerable. (The hypervisor cannot
be attacked using SP3 on any ARM processors, even those that are
listed as affected by SP3.)

Furthermore, only 64-bit PV guests can exploit SP3 against Xen. PVH,
HVM, and 32-bit PV guests cannot exploit SP3.

MITIGATION
==========

There is no mitigation for SP1 and SP2.

SP3 can be mitigated by running guests in HVM or PVH mode.
(Within-guest attacks are still possible unless the guest OS has also
been updated with an SP3 mitigation series such as KPTI/Kaiser.)

For guests with legacy PV kernels which cannot be run in HVM or PVH
mode directly, we have developed two "shim" hypervisors that allow PV
guests to run in HVM mode or PVH mode. This prevents attacks on the
host, but it leaves the guest vulnerable to Meltdown attacks by its
own unprivileged processes, even if the guest OS has KPTI or similar
Meltdown mitigation.

The HVM shim (codenamed "Vixen") is available now, as is the PVH shim
(codenamed "Comet") for Xen 4.10. We expect to have Comet for 4.8 and
4.9 within a few days. Please read README.which-shim to determine
which shim is suitable for you.

$ sha256sum xsa254*/*
34749c1169c5c8a1c0f7457184998e17ae54d5b262984150286db74ac1a82d22 xsa254/README.comet
1c594822dbd95998951203f6094bc77586d5720788de15897784d20bacb2ef08 xsa254/README.vixen
7e816160c1c1d1cd93ec3c3dd9753c8f3957fefe86b7aa967e9e77833828f849 xsa254/README.which-shim
1d2098ad3890a5be49444560406f8f271c716e9f80e7dfe11ff5c818277f33f8 xsa254/pvshim-converter.pl
$

RESOLUTION
==========

There is no available resolution for SP1. A solution may be available
in the future.

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
xen-devel.


NOTE ON LACK OF EMBARGO
=======================

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.
Xen.org security team
2018-01-16 17:43:34 UTC
Permalink
Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
version 8

Information leak via side effects of speculative execution

UPDATES IN VERSION 8
====================

PVH shim ("Comet") is now available for Xen 4.8.

Fixes for two bugs in PVH shim "Comet": one relating to shim
initialisation, which can cause hangs during guest boot shortly after
host boot(!), and one to make qemu PV backends work in PVH mode.
Thanks to the respective contributors.

We are longer inclined to port the "Comet" patches to Xen 4.9. If
this causes you a problem please let us know by contacting us:
To: ***@xenproject.org; CC: xen-***@lists.xenproject.org

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

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):

"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim 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.

"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
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 is
executable by the victim (eg, anywhere in the hypervisor).

"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
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:
https://meltdownattack.com/
https://spectreattack.com/
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

Additional Xen-specific background:

Xen hypervisors on most systems 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. (x86 HVM and PVH guests, and ARM 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.

IMPACT
======

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, an attacker is limited to windows of code after bound checks of
user-supplied indexes. For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.

Additionally, in general, attacks within a guest (from guest user to
guest kernel) will be the same as on real hardware. Consult your
operating system provider for more information.

NOTE ON TIMING
==============

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.

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

Systems running all versions of Xen are affected.

For SP1 and SP2, both Intel and AMD are vulnerable. Vulnerability of
ARM processors to SP1 and SP2 varies by model and manufacturer. ARM
has information on affected models on the following website:
https://developer.arm.com/support/security-update

For SP3, only Intel processors are vulnerable. (The hypervisor cannot
be attacked using SP3 on any ARM processors, even those that are
listed as affected by SP3.)

Furthermore, only 64-bit PV guests can exploit SP3 against Xen. PVH,
HVM, and 32-bit PV guests cannot exploit SP3.

MITIGATION
==========

There is no mitigation for SP1 and SP2.

SP3 can be mitigated by running guests in HVM or PVH mode.
(Within-guest attacks are still possible unless the guest OS has also
been updated with an SP3 mitigation series such as KPTI/Kaiser.)

For guests with legacy PV kernels which cannot be run in HVM or PVH
mode directly, we have developed two "shim" hypervisors that allow PV
guests to run in HVM mode or PVH mode. This prevents attacks on the
host, but it leaves the guest vulnerable to Meltdown attacks by its
own unprivileged processes, even if the guest OS has KPTI or similar
Meltdown mitigation.

The HVM shim (codenamed "Vixen") is available now, as is the PVH shim
(codenamed "Comet") for Xen 4.10 and Xen 4.8. Please read
README.which-shim to determine which shim is suitable for you.

$ sha256sum xsa254*/*
2f830fede5d58d3d90fe942ec2d8c4ef65cd14c4d565f9a1b9817847662ebba1 xsa254/README.comet
1c594822dbd95998951203f6094bc77586d5720788de15897784d20bacb2ef08 xsa254/README.vixen
7e816160c1c1d1cd93ec3c3dd9753c8f3957fefe86b7aa967e9e77833828f849 xsa254/README.which-shim
1d2098ad3890a5be49444560406f8f271c716e9f80e7dfe11ff5c818277f33f8 xsa254/pvshim-converter.pl
$

RESOLUTION
==========

There is no available resolution for SP1. A solution may be available
in the future.

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
xen-devel.


NOTE ON LACK OF EMBARGO
=======================

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.
Xen.org security team
2018-01-17 17:13:00 UTC
Permalink
Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
version 9

Information leak via side effects of speculative execution

UPDATES IN VERSION 9
====================

"Stage 1" pagetable isolation (PTI) Meltdown fixes for Xen are
available.

"Comet" updates to shim code (4.10 branch):
* Include >32vcpu workaround in shim branch so that all shim
guests can boot without hypervisor changes.
* Fix shim build on systems whose find(1) lacks -printf
* Place shim trampoline at page 0x1 to avoid having 0 mapped
(4.8 "Comet" users are using the 4.10 shim and may want to update.)

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

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):

"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim 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.

"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
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 is
executable by the victim (eg, anywhere in the hypervisor).

"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
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:
https://meltdownattack.com/
https://spectreattack.com/
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

Additional Xen-specific background:

Xen hypervisors on most systems 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. (x86 HVM and PVH guests, and ARM 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.

IMPACT
======

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, an attacker is limited to windows of code after bound checks of
user-supplied indexes. For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.

Additionally, in general, attacks within a guest (from guest user to
guest kernel) will be the same as on real hardware. Consult your
operating system provider for more information.

NOTE ON TIMING
==============

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.

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

Systems running all versions of Xen are affected.

For SP1 and SP2, both Intel and AMD are vulnerable. Vulnerability of
ARM processors to SP1 and SP2 varies by model and manufacturer. ARM
has information on affected models on the following website:
https://developer.arm.com/support/security-update

For SP3, only Intel processors are vulnerable. (The hypervisor cannot
be attacked using SP3 on any ARM processors, even those that are
listed as affected by SP3.)

Furthermore, only 64-bit PV guests can exploit SP3 against Xen. PVH,
HVM, and 32-bit PV guests cannot exploit SP3.

MITIGATION
==========

There is no mitigation for SP1 and SP2.

SP3 can be mitigated by page-table isolation ("PTI").
See Resolution below.

SP3 can be mitigated by running guests in HVM or PVH mode.
(Within-guest attacks are still possible unless the guest OS has also
been updated with an SP3 mitigation series such as KPTI/Kaiser.)

For guests with legacy PV kernels which cannot be run in HVM or PVH
mode directly, we have developed two "shim" hypervisors that allow PV
guests to run in HVM mode or PVH mode. This prevents attacks on the
host, but it leaves the guest vulnerable to Meltdown attacks by its
own unprivileged processes, even if the guest OS has KPTI or similar
Meltdown mitigation.

The HVM shim (codenamed "Vixen") is available now, as is the PVH shim
(codenamed "Comet") for Xen 4.10 and Xen 4.8. Please read
README.which-shim to determine which shim is suitable for you.


$ sha256sum xsa254*/*
1cba14ff83844d001d6c8a74afc3f764f49182cc7a06bb4463548450ac96cc2f xsa254/README.comet
cddd78cd7a00df9fa254156993f0309cea825d600f5ad8b36243148cf686bc9b xsa254/README.pti
3ef42381879befc84aa78b67d3a9b7b0cd862a2ffa445810466e90be6c6a5e86 xsa254/README.vixen
7e816160c1c1d1cd93ec3c3dd9753c8f3957fefe86b7aa967e9e77833828f849 xsa254/README.which-shim
1d2098ad3890a5be49444560406f8f271c716e9f80e7dfe11ff5c818277f33f8 xsa254/pvshim-converter.pl
$

RESOLUTION
==========

These are hardware bugs, so technically speaking they cannot be
properly fixed in software. However, it is possible in many cases to
provide patches to software to work around the problems.


There is no available resolution for SP1. A solution may be available
in the future.

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
xen-devel.


SP3 can be mitigated by page-table isolation ("PTI").

We have a "stage 1" implementation. It allows 64-bit PV guests to be
run natively while restricting what can be accessed via SP3 to the Xen
stack of the current pcpu (which may contain remnants of information
from other guests, but should be much more difficult to attack
reliably).

Unfortunately these "stage 1" patches incur a non-negligible
performance overhead; about equivalent to the "PV shim" approaches
above. Moving to plain HVM or PVH guests is recommended where
possible. For more information on that, see below.

Patches for the "stage-1" PTI implementation are available in the Xen
staging-NN branches for each Xen revision. See README.pti for
specific revisons.


NOTE ON LACK OF EMBARGO
=======================

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.
Xen.org security team
2018-01-18 18:38:41 UTC
Permalink
Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
version 10

Information leak via side effects of speculative execution

UPDATES IN VERSION 10
=====================

Provided summary table for the varous Meltdown options.

Note that in XSA-254 v9's Updates section we said
* Include >32vcpu workaround in shim branch ...
but this workaround is for guests with 32 or *fewer* vcpus; guests
with more will still need the L0 hypervisor patched and rebooted.

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

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):

"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim 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.

"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
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 is
executable by the victim (eg, anywhere in the hypervisor).

"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
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:
https://meltdownattack.com/
https://spectreattack.com/
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

Additional Xen-specific background:

Xen hypervisors on most systems 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. (x86 HVM and PVH guests, and ARM 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.

IMPACT
======

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, an attacker is limited to windows of code after bound checks of
user-supplied indexes. For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.

Additionally, in general, attacks within a guest (from guest user to
guest kernel) will be the same as on real hardware. Consult your
operating system provider for more information.

NOTE ON TIMING
==============

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.

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

Systems running all versions of Xen are affected.

For SP1 and SP2, both Intel and AMD are vulnerable. Vulnerability of
ARM processors to SP1 and SP2 varies by model and manufacturer. ARM
has information on affected models on the following website:
https://developer.arm.com/support/security-update

For SP3, only Intel processors are vulnerable. (The hypervisor cannot
be attacked using SP3 on any ARM processors, even those that are
listed as affected by SP3.)

Furthermore, only 64-bit PV guests can exploit SP3 against Xen. PVH,
HVM, and 32-bit PV guests cannot exploit SP3.

MITIGATION
==========

There is no mitigation for SP1 and SP2.

SP3 can be mitigated by page-table isolation ("PTI").
See Resolution below.

SP3 can, alternatively, be mitigated by running guests in HVM or PVH
mode. (Within-guest attacks are still possible unless the guest OS
has also been updated with an SP3 mitigation series such as
KPTI/Kaiser.)

For guests with legacy PV kernels which cannot be run in HVM or PVH
mode directly, we have developed two "shim" hypervisors that allow PV
guests to run in HVM mode or PVH mode. This prevents attacks on the
host, but it leaves the guest vulnerable to Meltdown attacks by its
own unprivileged processes, even if the guest OS has KPTI or similar
Meltdown mitigation.

The HVM shim (codenamed "Vixen") is available now, as is the PVH shim
(codenamed "Comet") for Xen 4.10 and Xen 4.8. Please read
README.which-shim to determine which shim is suitable for you.


RESOLUTION
==========

These are hardware bugs, so technically speaking they cannot be
properly fixed in software. However, it is possible in many cases to
provide patches to software to work around the problems.


There is no available resolution for SP1. A solution may be available
in the future.

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
xen-devel.


SP3 can be mitigated by page-table isolation ("PTI").

We have a "stage 1" implementation. It allows 64-bit PV guests to be
run natively while restricting what can be accessed via SP3 to the Xen
stack of the current pcpu (which may contain remnants of information
from other guests, but should be much more difficult to attack
reliably).

Unfortunately these "stage 1" patches incur a non-negligible
performance overhead; about equivalent to the "PV shim" approaches
above. Moving to plain HVM or PVH guests is recommended where
possible. For more information on that, see below.

Patches for the "stage-1" PTI implementation are available in the Xen
staging-NN branches for each Xen revision. See README.pti for
specific revisons.


SP3 MITIGATION OPTIONS SUMMARY TABLE FOR 64-bit X86 PV GUESTS
=============================================================

Everything in this section applies to 64-bit PV x86 guests only.

Xen PTI Use PVH Use HVM PVH shim HVM shim
"stage 1" "Comet" "Vixen"

How to use README.pti type="pvh" type="hvm" README.comet README.vixen

Guest All Linux 4.11+ Most[4] All All
support ?unikernels?[3]

Xen 4.6+ 4.10+ All 4.10, 4.8 All
versions 4.8-comet[1]

Testing Limited 4.10: Good Very good Moderate Very good
status Very new 4.8: Moderate

Performance Fair Excellent Varies[4] Fair Fair

Hypervisor Needed No need No need No need No need
changes

SP3 guest Substantially Protected Protected Protected Protected
to host protected

SP3 within Protected Guest Guest Vulnerable Vulnerable
guest patches patches [5] [5]

SP3 from Protected n/a; vuln. n/a; vuln. n/a; vuln. n/a; vuln.
dom0 user [9] [9] [9] [9]

Device model No dm No dm Qemu No dm Qemu

Config change None type="pvh" type="hvm"/ type="pvh" Tool to rewrite
builder="hvm" pvshim=1 Needs "sidecar"

Within-guest None Should be Disks+net None None
changes? none may change

Extra RAM use V. slight None ~9Mb/guest >=~20Mb/guest >=~29Mb/guest

Migration OK OK OK[4] OK Unsupported[2]
Guest mem adj OK OK OK Broken[2] Unsupported[2]
vcpu hotplug OK OK OK OK Unsupported[2]

Solution Indefinite Indefinite Indefinite Indefinite Limited
lifetime [7] [6]

[1] PVH is supported in Xen 4.8 only with the 4.8 "Comet" security
release branch.

[2] Some features in PVH/HVM shim guests are not inherently broken,
but buggy in the currently available versions. These may be fixed in
future proper releases of the same feature.

[3] Most unikernels have Xen support based on a version of mini-os.
mini-os master can boot PVH. But this is very recent.

[4] Some guests which have support for Xen PV fail to boot properly in
Xen HVM. Some such guests can made to boot HVM by disabling the
PV-on-HVM support entirely in the guest or in Xen; in that case the
guest may work but IO performance will be poor. Some PV-supporting
guests can boot as HVM, with PV drivers, but fail when migrated.

[5] The Comet and Vixen shim hypervisors direct-map all of their
"physical" memory, and that direct-map can be accessed using Meltdown
by unprivileged processes in the guest. So the guest is vulnerable to
within-guest Meltdown attacks and the guest operating system cannot
protect itself.

[6] "Vixen" HVM shim is not expected to be incorporated in future Xen
stable releases. At some point, support for it will be withdrawn.
However, HVM shim functionality may be available in a future Xen 4.10
stable point release and would then probably be useable with the
existing conversion script provided in this advisory.

[7] The lifetime of the special Comet branches is limited, but we will
not desupport them until some time after the same functionality is in
appropriate Xen stable point releases.

[8] The 64-bit x86 PV guest ABI precludes a guest from mapping its
kernel and userspace in the same address space. So these guests are
inherently immune to within-guest Meltdown attacks, without
within-guest patching. (This applies to 64-bit x86 PV guests only.)

[9] It is not possible to run dom0 as HVM. dom0 PVH is a planned
enhancement which is not yet available even in preview form.


ATTACHMENTS
===========

$ sha256sum xsa254*/*
1cba14ff83844d001d6c8a74afc3f764f49182cc7a06bb4463548450ac96cc2f xsa254/README.comet
cddd78cd7a00df9fa254156993f0309cea825d600f5ad8b36243148cf686bc9b xsa254/README.pti
3ef42381879befc84aa78b67d3a9b7b0cd862a2ffa445810466e90be6c6a5e86 xsa254/README.vixen
7e816160c1c1d1cd93ec3c3dd9753c8f3957fefe86b7aa967e9e77833828f849 xsa254/README.which-shim
1d2098ad3890a5be49444560406f8f271c716e9f80e7dfe11ff5c818277f33f8 xsa254/pvshim-converter.pl
$


NOTE ON LACK OF EMBARGO
=======================

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.

Loading...