Earlier quoted context omitted.
> Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh. Here's the synchronized announcement from Chrome/Chromium: https://sites.google.com/a/chromium.org/dev/Home/chromium-se... "Chrome's JavaScript engine, V8, will include mitigations starting with Chrome 64, which will be released on or around January 23rd 2018. Future Chrome releases will include additional…
The mitigations are to disable SharedArrayBuffer and severely round performance.now(). Not good that there aren’t other less intrusive ways to mitigate.
Reading privileged memory with a side-channel
541–550 of 639 posts
Re: Reading privileged memory with a side-channel
#542Earlier quoted context omitted.
> New CPU microcode is enough What would that entail? Disabling speculation completely? Disabling memory accesses during speculation?
Disabling indirect branch prediction (and thus speculation after indirect branches) while in kernel mode, or flushing the indirect branch predictor on kernel mode entry. Both need OS support in addition to the microcode, but the change is less invasive than PTI.
The "out of bounds" Spectre variant is still feasible.
Also: What about hyperthreads? It seems to be many people's assumption that the BTB is shared within a physical core.
Re: Reading privileged memory with a side-channel
#543Earlier quoted context omitted.
Only if your speculative reads do cause irreversible side-effects on those caches. You could implement them in a way that doesn't modify the caches... but that would be complicated and probably use more power and have lower performance.
There does not need to be a performance hit, but cache complexity must rise: speculative execution must use a separate cache for any data that was fetched speculatively. Only when that branch is truly accepted must that data enter the "real" cache. As long as speculative execution does not go on for too long, these secondary caches can stay really tiny (a handful of cache lines maybe).
More broadly, potential counter- measures limited to the memory cache are likely to be insufficient, since there are other ways that speculative execution can leak information. For example, timing ef- fects from memory bus contention, DRAM row address selection status, availability of virtual registers, ALU ac- tivity, and the state of the branch predictor itself need to be considered.
... also ...
Of course, speculative execution will also affect conventional side channels, such as power and EM
Historically I think it's been assumed that you can't extract much useful information from a modern speculating CPU via EM radiation, but these attacks constantly seem to be surprising people. Re-programming a wifi chip to monitor interference generated by the CPU to spy on speculation? It would have sounded like a pie in the sky fantasy ... yesterday.
Re: Reading privileged memory with a side-channel
#544So, is AMD effected or not? This seems fairly important. The Google blog post sort of goes against itself in this regard. AMD itself has said: "The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time." So either AMD is lying or Goog…
From the Spectre paper- We have empirically verified the vulnerability of several Intel processors to Spectre attacks, including Ivy Bridge, aswell and Skylake based processors. We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones. So in ot…
Re: Reading privileged memory with a side-channel
#545Earlier quoted context omitted.
> I would think that any sane implementation would not transmit privileged data to waiting instructions. The point of VIPT caches is exactly to use data before all the checks are completed. It's easy to judge the sanity of things ex post, but maybe it's not that easy if it took 20 years to find the issue.
I don't believe for a second that nobody came up with this idea before. I believe that nobody until now had the motivation to spend the time actually trying to confirm that it's a problem by developing a PoC. Most people would have given up on the idea simply because CPU vendors are not expected to make such a fundamental mistake.
Previously side channel attacks like this have been seen by the security community as unreliable things which only work in very specific cases and have to be averaged over millions of runs.
This attack shows a side channel which is general purpose, reliable, and fast.
Re: Reading privileged memory with a side-channel
#546Earlier quoted context omitted.
Not that we currently know about. RISC instead of CISC is better here as it shortens the pipeline, but even RISC processors do speculative predictions due to the cost of waiting till a branch is fully decided.
What about more radically different designs? E.g Mill or others?
https://millcomputing.com/docs/prediction/
It has to. The problem is the speed of light here, not a simple slipup by a CPU designer.
Re: Reading privileged memory with a side-channel
#547Reading over this.... it sounds like ultimately the exploit in Linux still only works thanks to being able to run stuff in the kernel context through eBPF? The first section states that even with the branch prediction you still need to be in the same memory context to be able to read other process's memory through this. But eBPF lets you run JIT'd code in the kernel context. I guess this JITing is also the issue with…
It's also possible to use existing code in the target context as the speculative execution path if it has the right form (and this is what P0's Variant 2 POC does, in that case by poisoning the branch predictor in order to make it speculatively execute a gadget that has the right form).
Re: Reading privileged memory with a side-channel
#548Earlier quoted context omitted.
There's no mitigation. We'll need new CPUs. Meanwhile, don't ever run untrusted code in the same process as any kind of secret. Better yet, don't ever run untrusted code.
I wonder what fraction of data inside a kernel is really ‘private’. Obviously we want 100% of the data in the kernel not to be writeable, but if only a small amount shouldn’t be accessible at all then maybe the long term solution is to handle that data in a special way. Something that makes using it slower but doesn’t make every other syscall suffer as much as a consequence. Or maybe the solution is to prioritize mov…
Consider:
• Network packet buffers? Yes.
• Graphics driver command buffers? Yes.
• Disk caches? Yes.
• Kernel pointers of any kind? Yes if you care about KASLR.
It's actually kind of hard to think of data in the kernel that shouldn't be read protected.
Re: Reading privileged memory with a side-channel
#549I wonder if the whole thing with enormously complex CPUs requiring deep pipelines which in turn requires complex speculation etc was a design mistake? Is there an alternative history where mainstream CPUs are equally fast with a dumber/simpler design?
VLIW is not a panacaea, engineering being all about tradeoffs after all. But it was intended to not have the complex instruction dispatching logic, with things like speculative execution and branch prediction, in the processor. Instead, using a process called if-conversion the compiler combines the two possible results of a conditional branch into a single instruction stream where predicates control which instruction syllables are executed.
* http://web.eecs.umich.edu/~mahlke/papers/1996/schlansker_hpl...
* https://www.isi.edu/~youngcho/cse560m/vliw.pdf
* https://www.cse.umich.edu/awards/pdfs/p45-mahlke.pdf
* http://web.eecs.umich.edu/~mahlke/papers/1996/schlansker_hpl...
Observe, in considering this alternative history, that the Itanium had 64 predicate registers. People have, in the past few days in various discussions of this subject, criticized Intel for holding on to a processor design for decades and prioritizing backwards compatibility over cleaner architecture. They have forgotten that Intel actually produced a cleaner architecture, back in the 1990s.
Re: Reading privileged memory with a side-channel
#550Papers describing each attack: https://meltdownattack.com/meltdown.pdf https://spectreattack.com/spectre.pdf From the spectre paper: >As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs (cf. Listing 2). Scary stuff.