Contributed by Paul 'WEiRD' de Weerd on from the the gift that keeps on giving dept.
Theo de Raadt (deraadt@) posted to the tech@ mailing list with some background on how the latest discovered Intel CPU issues relate to OpenBSD.
Date: Wed, 15 Aug 2018 00:31:16 -0600 From: Theo de Raadt [elided] To: tech@openbsd.org Subject: CVE-2018-3615, CVE-2018-3620, CVE-2018-3646 These 3 issues all relate to a bug in Intel cpus The cpu will speculatively honour invalid PTE against data in the on-core L1 cache. Memory disclosure occurs into the wrong context. These 3 issues (CVE-2018-3615, CVE-2018-3620, CVE-2018-3646) together are the currently public artifacts of this one bug.
There may be more artifacts of this on the way, perhaps combined with other past and not yet known mistakes. CVE-2018-3620 matters for the host OS. We have reviewed our pmap module and it appears like we never invalidate a PTE by clearing the 'valid' bit alone, we always clear the PTE to 0 entirely. Page 0 of physical memory is unused. As well, we don't support Wine (which has VA 0 / PA 0 issues); we don't support 32-bit emulation in 64-bit mode which makes things trickier, and we have SMT disabled by default which reduces the risk patterns further. CVE-2018-3646 relates to the same bug, but considers the cross-domain impact upon entering VMs, which obviously run in different security domains. A patch should arrive soon to flush the L1 cache before vmenter, so that an incorrectly accessed PTE can't read data from another domain. Another aspect of the risk in this area goes away if SMT is disabled, so keep it disabled! CVE-2018-3615 (Foreshadow) is by receiving the most press which is amazing considering it is by far the most boring of the 3, since very few few people give a rats ass about SGX -- who cares if SGX is broken when the cpu can't run your OS safely? Some convincing press agencies were hired I guess, and have performed a masterful job of distracting. We had some idea this class of problem was coming, through hints we received from others and an extremely cynical perspective that has developed. We believe Intel cpus do almost no security checks up-front, but defer checks until instruction retire. As a result we believe similar issues will be coming in the future. We asked repeatedly, but Intel provided no advance notice. We did not even receive replies to our requests for dialogue. On a side note, AMD cpus are not vulnerable to this problem. Currently it is believed their address translation layer works according to spec.
Further reading here (foreshadowattack.eu), and here (intel.com).
(Comments are closed)
By Janne Johansson (jj) jj@stacken.kth.se on http://www.inet6.se
Why, why, miss dyn-linkable PIE,
drove my intel to the socket but the socket was dry,
and the good old old admins were drinking and cryi'n,
singing "this'll be the day that it dies..
This'll be the day security dies.."
By chas (chas) chas@syro.org on
On a related note, the AMD Athon X4 845 and 950 top these price/performance ratings:
https://www.cpubenchmark.net/cpu_value_available.html
The FX-9590 was at the top of the list when I checked last month. I'm thinking that it's time to upgrade to something more secure.
Comments
By Chris Cappuccio (chriscappuccio) chris@nmedia.net on http://www.nmedia.net/chris/
There's no guarantee that AMD is better
Comments
By Daniel Cizinsky (d.c.) on
at least you would have a kind of diversity. But what's worse, where can you buy a (hw) supported server with AMD? Well, importing server to EU via USA and pay 10 times price of an Intel for no service support is not really an option.