5 ms·
Researchers discover seven new Meltdown and Spectre attacks
- EE84M3i 8y agoDirect link to paper: https://arxiv.org/abs/1811.05441 https://arxiv.org/abs/1811.05441
- the_clarence 8y agoMvp
- travisoneill1 8y agoI don't know much about low level stuff, but from what I have read: - these issues are inherent in speculative execution - speculative execution is critical for performance - therefore these issues are really hard to eliminate - these attacks can break out of VM's Are these points correct? Because if they are, it seems like a safe conclusion that most of the cloud will be compromised.
- ndiscussion 8y agoI think you're right on everything but "critical for performance". Some chips (mostly Intel) have seen pretty big performance drops. But nothing like 50%+. Cloud could cost 50% more. We will bear it.
- MaxBarraclough 8y ago> Cloud could cost 50% more. We will bear it. Likely far less impact than this, as much of the cloud isn't CPU-bound, right?
- smitherfield 8y agoI think that's his point; cloud is often network-bound, which can be orders of magnitude more costly.
- holstvoogd 8y agoGood point. I wonder what the real world impact is, I can imagine all the task switching that happens (at least on my VMs) could have a big impact somehow. Either bad, as in more waiting on memory for instance, or good, as in there wasn't much speculation going on anyway because of it.
- craftyguy 8y agoNone of the fixes have completely eliminated speculative execution, they have only eliminated speculative execution in a few specific cases. Wiping it out across the board would likely have a massive impact on performance.
- holstvoogd 8y agoI think that is a safe conclusion. I'm not sure on if and how well these things can be mitigated in the hypervisor, but given that current mitigations don't seem to work in all cases, I'm not hopeful for the x86 speculative execution.
- gpderetta 8y agoI'm hopeful that the insanity of running untrusted code in the same network, machine or even process will be over.
- Symmetry 8y agoEliminating speculation entirely would be an utter disaster for performance, more than a factor of 10. Eliminating speculation across certain security boundaries seems to be viable and not too horrible from a performance standpoint, though you have to be careful to get the boundaries and I imagine this'll be something like buffer overflow attacks where we occasionally find new ones that have to be patched. Also, as far as I'm aware the sort of shallow speculation used by most in order processors doesn't tend to provide enough of a window for an attacker to exfiltrate data after loading it, though it's possible that I'm unaware of one that does.
- StreamBright 8y agoGiven the CPU architectures we are currently using yes. There are other architectures not affected by it like Mill.
- pkaye 8y agoHow does the Mill architecture handle branch prediction?
- Symmetry 8y agoIt speculates of course but because the speculation is so shallow it can't read then pass on privileged information before the mis-speculation is caught. EDIT: Oh, I should also point out that it isn't just branches. A pipelined processor is also speculating if it continues issuing institutions before memory accesses are fully resolved, because those accesses might result in exceptions that render the following instructions invalid.
- pkaye 8y agoWhat about it terms of performance given this limited speculation?
- Symmetry 8y agoI was counting those under shallow in order processors. The ARM A8 was vulnerable and I'd guess the POWER 6 was as well. But the A53s you've got in a modern phone are safe. I don't know of any VLIW design that's vulnerable to these whether they're open pipeline like the Mill or Transmeta lineage or closed like the Itanium. Or the Hexagon which uses round robin multi-threading to make every operation look like 1 cycle so it can be both ;)
- 0x0 8y agoMeltdown in particular is worse than that, I believe. It would allow user-space programs - even regular sandboxed javascript in a browser - to read memory from the kernel and maybe other processes within the same OS?
- pkaye 8y agoChandler Carruth has a good talk with an example of why speculative execution is critical for performance. https://www.youtube.com/watch?v=2EWejmkKlxs https://www.youtube.com/watch?v=2EWejmkKlxs It starts around 36m13s time frame.
- dnautics 8y agoconceivably this could be all put into the compiler.
- pkaye 8y agoYou mean speculative execution? Do you know of an sample implementation?
- twtw 8y agoConceivable, yes. Practical? Not so much. This is an idea that I personally love, but that hasn't fared well so far. Compilers are not as good as assigning instruction schedules statically as hardware can do dynamically.
- dnautics 8y agocurious as to why hardware can do it dynamically while software can't. It's all logic in the end. I can understand "not being able to statically compile it because every architecture is different" but, presuming our compiler compiled to a specific platform - why wouldn't it be able to dynamically rearrange in, say, a JITted fashion using exactly whatever logic is available in the hardware.
- twtw 8y agoHopefully I'll put together a more technical answer in a while, but for now I'll just point out that when talking about performance, reducing things to "it's all logic in the end" makes little sense. We could emulate a modern CPU on an 8-bit micro controller, but the performance would be bad.
- 8y ago
- sebazzz 8y agoSounds like the only solution would be to enable speculative execution on a per-process basis. Something like Visual Studio and it's child processes, core Windows processes and the kernel may fully use branch prediction. "Trusted processes" so to speak. The Web browser, not so much, so no branch prediction, no side channel. Perhaps new cpu instructions? - nspex - No SPeculative EXecution from here - espex - Enable SPeculative EXecution from here
- jlebar 8y ago> Something like Visual Studio and it's child processes, core Windows processes and the kernel may fully use branch prediction. Even that does not work. If the kernel can do speculative execution and user code can cause the kernel to do work (that's kind of the kernel's job), then user code can cause the kernel to leak secret data. This was one of the first set of attacks.
- lostmsu 8y agoAre these already patched?