Re: [Xen-devel] Xen Security Advisory 254 - Information leak via side effects of speculative execution

[Doug Goldstein <cardoe () cardoe com>]

I'm just adding some comments below on some updates that might be
helpful to add to help clarify things for interested parties. These
comments are driven purely based on the questions that I've had to field
from others.

- Since this advisory talks about 3 CVEs and then breaks the issue into
3 items SP1, SP2 and SP3 it would be helpful to directly map them to
their CVEs.
- There has been some confusion around mitigation and resolution where
people misunderstand the terms and therefore there might be some value
in providing some updates to provide some more clarity.

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

please add CVE-2017-5753

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

please add CVE-2017-5715


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

please add CVE-2017-5754 and/or reference this is meltdown.

> MITIGATION
> ==========
>
> 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.
>
> RESOLUTION
> ==========
>
> There is no available resolution for SP1 or SP3.

I believe there has been some confusion among some people about the
terms here. There are some people that understand "mitigation" as "what
can I do now to avoid this" and "resolution" as "what updates can I
apply". As a result they are misunderstanding here what the net result
is. Some clarifications could be that the PVH shim is the resolution for
the SP3 issue. However its not a fix for PV itself but instead changes
the very nature of how PV guests are started up.


-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature