Major Intel design flaw compromises most current consumer CPUs 2018-01-03 20:48:08 Recently disclosed ("KAISER") patches to the Linux kernel as well as "Windows Insider" exclusive patches have demonstrated that essentially all Intel CPUs made in the last decade (at least!) have a critical flaw in their speculative execution functionality that likely enables some execution of code from ring 3 (user mode) writing to ring 0 (kernel mode) memory with potentially serious consequences. At least one compsec researcher has claimed that this does not require a page fault in order to occur. This is a hardware flaw, so all systems running an Intel x86 processor, (including the cult of MacOS and *BSDs) are affected, irrespective of OS.Depending upon load, the patches can apparently reduce performance substantially or almost not at all. This first appears to have been discovered by CS researchers at the University of Graz (Austria). The register article links to an interesting blog post from last year by Anders Fogh who runs bits of specific code on his Broadwell-core i3 demonstrating part of the issue. He concludes by writing:Quote from: Anders Fogh @ CyberWTFThe first is that Intel’s implementation of Tomasulo’s algorithm is not side channel safe. Consequently we have access to results of speculative execution despite the results never being committed. Secondly, my results demonstrate that speculative execution does indeed continue despite violations of the isolation between kernel mode and user mode.This is truly bad news for the security. First it gives microarchitecture side channel attacks additional leverage – we can deduct not only information from is actually executed but also from what is speculatively executed. It also seems likely that we can influence what is speculative executed and what is not through influencing caches like the BTB, see Dmitry Evtyushkin and Dmitry Ponomarev  for instance. It thus add another possibility to increase the expressiveness of microarchitecture side channel attacks and thus potentially allow an attacker even more leverage through the CPU. This of cause makes writing constant time code even more complex and thus it is definitely bad news.Also it draws into doubt mitigations that rely on retirement of instructions. I cannot say I know how far that stretches, but my immediate guess would be that vmexit’s is handled on instruction retirement. Further we see that speculative execution does not consistently abide by isolation mechanism, thus it’s a haunting question what we can actually do with speculative execution.AMD CPUs are apparently not affected by this bug, and AMD has already submitted patches to the Linux kernel which disable the Intel-specific patch upon detection of an AMD CPU. The arstechnia writer suggests that in contrast, ARM chips may very well be affected, suggesting essentially all smartphones in circulation might well have the same problem.Edit: I've not seen specific demonstrations (yet) that Intel's (s)low-end "Atom" processors are affected, but these are typically so pitifully slow that they are only found on extremely inexpensive systems. Perhaps the single most major concern here is the massive Microsoft/Amazon/Google/FBook/Your Bank cloud computing/storage centers are overwhelmingly running Intel CPUs that contain this bug. The remaining AMD Opteron and new Epyc servers of course do not have this issue. Last Edit: 2018-01-03 20:54:55 by Audible!