5 ms·
Notes from the Intelpocalypse
- Game_Ender 9y agoThis is the best succinct explanation of the vulnerabilities I have seen to date.
- j_s 9y agoIIRC, the GCE security white paper mentioned alarms triggered by ROWHAMMER, another hardware design defect. Is it possible to reliably detect any of this year's new attacks?
- dzdt 9y agoI wonder if it would be possible to peg the kernel to one processor core (or a subset of the cores) and userspace to the remainder of the cores. As I understand it, all of the memory caches that are being exploited to leak information are per-core, so that would give a blanket guard against kernel->userspace leaks via cache timing.
- kindfellow92 9y agoSyscall performance would suffer but otherwise this could work.
- gaius 9y agoYes this is easy to do with cpu shields. But it means a system call might need to go onto another board... this would work only for the apps that ran mainly in user space and wouldn’t be very impacted anyway...
- j_s 9y agoThis is the first time I've seen this suggestion; it is something that could be done relatively easily for systems that otherwise have no updates/mitigations. If performance is better some variant of this (auto-scaling dedicated cores) may even become the default solution rather than all the other workarounds! Bare metal hypervisors should get their own core(s) too. Is anyone already doing this? (Qubes, etc.)
- terminalcommand 9y agoI remember seeing this suggestion earlier. If I'm not mistaken a commentor stated that a) this would come with a huge performance penalty b) there would be synchronization problems in multithreaded scenarios. Don't take my word for it though, I might have understood it wrong. I imagine concurrent/parallel execution involving system calls could maybe suffer from synchronization issues if processes/threads run on different physical cores with separate caches?
- angersock 9y agoAs memory serves that was exactly how the hypervisor on the PS3 Cell setup worked.
- mcross 9y agoThis is a great writeup. This article is labelled as subscriber-only content, yet I am not a subscriber and can see it fine by following this link. Is it as simple as having the right URL to get to LWN subscriber-only content, or is there some other reason it can be accessed by non-subscribers?
- kindfellow92 9y agoThis post seems to indicate that there is no kernel-level workaround for variant 1, that contradicts AMD’s statement: https://www.amd.com/en/corporate/speculative-execution https://www.amd.com/en/corporate/speculative-execution LWN seems right on this one, that makes me question AMD’s honesty and knowledge of the issue.
- evilantnie 9y agoI'm not 100% sure here, but I believe this is the specific kernel level fix that also addresses variant 1 https://lkml.org/lkml/2017/12/27/2 https://lkml.org/lkml/2017/12/27/2
- kindfellow92 9y agoNo KPTI does not address variant 1.
- manyoso 9y agoAt this point, both Intel and AMD press releases should be treated as highly, highly suspect. They are both jockeying to mitigate money loss or take advantage to make money. The truth is a secondary concern. I'd believe CERT, project zero and the independent linux kernal devs if you want the truth.
- userbinator 9y agoFor the owners of vast numbers of systems that cannot be updated, the consequences will be worse: they will remain vulnerable to a set of vulnerabilities with known exploits. Fortunately, chances are that those systems are stable, isolated environments which won't be running any new and untrusted code either. That means they will just remain vulnerable in the same way that everyone knows their houses can always be broken into by a determined-enough attacker; to try to achieve 100% security, to close all the side-channels, may be impossible and have plenty of other negative effects. Sometimes, just knowing is enough because it leads to more informed risk analysis and decisions. That saying about "known knowns, known unknowns, and unknown unknowns" comes to mind.
- VikingCoder 9y agoBut if a system had known exploits that let you execute arbitrary code in user space, now there's a path to do way worse damage. It's like it's a multiplicative effect.
- cmurf 9y agoSee the comments. FSMark with mitigation showed a 50% performance loss. So that immediately makes me wonder about any file system intensive operation, like databases, getting hit far worse than the 5-30% hit that's been floated thus far.
- crimsonalucard 9y agoSo is this article implying that only code executed on branch predictions is readable? What about normally executed code? What are the exact differences? How is normally executed code protected and how is branch predicted code not protected? Any experts care to chime in?
- guelo 9y agoNot sure what you mean by normally executed code. Speculative execution happens in normal everyday conditional code such as if/switch statements, and most loops unless the compiler unrolls them.
- crimsonalucard 9y agoBy normal I mean code that wasn't predicted. Predicted code execution is "abnormal" because it might not contribute to the final result. My question is why is predicted code exploitable and why is unpredicted code not exploitable? Both are executed, both have values written to registers, what's going on? Apologies for the noobness of this question.
- mikeash 9y agoImagine some code running in some walled-off privileged space (like the kernel) that looks something like this: if(i < length) { value = data[i] doStuff(lookupTable[value]) } Let's say you can run this code with an arbitrary value for `i` (maybe it's the parameter to a system call). From a high-level view, this code is perfectly safe. If `i` is out of bounds, nothing happens. If it's in bounds, the system does something with the data at i, presumably something you're allowed to do. But what really happens on a modern CPU when `i` is out of bounds? It's possible that the value for `length` is not available and has to be loaded from memory, which can take several hundred CPU cycles in the worst case. It's also possible that the CPU will make a guess that the `if` branch will be taken. If that happens, then execution looks something like this: try to compare i < length can't, because length is not yet available guess the branch will be taken, begin speculatively executing it: initiate the loading of length load data[i] load lookupTable[value] ...possibly some more stuff... eventually, the load of length completes oops, turns out i >= length roll back all of the speculative stuff above Normally none of this is visible. But, the memory loads have side effects. Namely, they modify the CPU's caches. By attempting to load different locations in memory and looking at how long it takes, you can figure out which locations got cached during that speculative execution phase. Since one of those locations was determined by an out-of-bounds load of data[i], that means you can use this to figure out the data stored at an arbitrary location in this privileged space. It requires speculative execution of a branch that ends up not being taken, because if the speculative execution was correct then you haven't gained access to anything you're not supposed to know, and if there was no speculative execution then you never load anything out of bounds. This is simplified and probably wrong in some aspects, but that's the rough idea.
- combomambo 9y agoJust waiting for the class action lawyers to jump on this one, and the courts ultimately approving us all to get only a rebate coupon for a new processor