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: email@example.com 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.
(Comments are closed)