Date: Fri, 5 Jan 2018 11:22:25 -0600 From: Doug Goldstein <cardoe@...doe.com> To: "Xen.org security team" <security@....org>, xen-announce@...ts.xen.org, xen-devel@...ts.xen.org, xen-users@...ts.xen.org, oss-security@...ts.openwall.com Cc: "Xen.org security team" <security-team-members@....org> Subject: Re: [Xen-devel] Xen Security Advisory 254 - Information leak via side effects of speculative execution 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 Download attachment "signature.asc" of type "application/pgp-signature" (982 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ