contrarian_

9 ms·

31.
by contrarian_ 9y ago
You can then detect which addresses were loaded because they caused other cache lines to be evicted. Even if speculative loads do not modify the cache, you could still have a side channel by analyzing the memory bus contention. IMO there is
32.
by contrarian_ 9y ago
2006: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.190... From the abstract: > Information leakage through covert channels and side channels is becoming a serious problem, especially when these are enhan
33.
by contrarian_ 9y ago
No, you could also find a gadget with ROP techniques. The eBPF thing in the paper was purely due to convenience of exploitation.
34.
by contrarian_ 9y ago
Too bad arbitrary real numbers cannot be represented in finite memory.
35.
by contrarian_ 9y ago
Yet another case where running an Anti-Virus makes your system less secure.
36.
by contrarian_ 9y ago
Did Itanium really fail because of the technology or because of x86's momentum and lock-in effects? AFAIK Itanium has explicit software control of speculative loads.
37.
by contrarian_ 9y ago
There are (at least) two separate things going on. Meltdown, the flaw exclusive to Intel and some ARM CPUs, is very easy to exploit and is the one being patched by OS vendors. Spectre is a whole other can of worms, on the one hand it's
38.
by contrarian_ 9y ago
Any branch on attacker-controlled data can be speculatively bypassed. You would have to at the very least recompile all applications to attempt to mitigate the two Spectre variants discussed so far. Unless there is some way to turn off spec
39.
by contrarian_ 9y ago
Not a bug according to Intel.
40.
by contrarian_ 9y ago
Isn't that only for Meltdown?
41.
CPU hardware vulnerable to side-channel attacks(kb.cert.org)
139 points by contrarian_ 9y ago|82 comments
42.
by contrarian_ 9y ago
FWIW, all branches will need to be followed by a memory load fence which seems to trip up speculative execution on Intel CPUs.
43.
by contrarian_ 9y ago
Note for a true fix to the BTB poisoning attack you would additionally have to disable SMT/HT. See here: https://news.ycombinator.com/item?id=16070304
44.
by contrarian_ 9y ago
From the abstract: > Information leakage through covert channels and side channels is becoming a serious problem, especially when these are enhanced by modern processor architecture features. We show how processor architecture features s
45.
Covert and side channels due to processor architecture (2006)(citeseerx.ist.psu.edu)
2 points by contrarian_ 9y ago|1 comments
46.
by contrarian_ 9y ago
> The mistake is clear from the design There is no fundamental reason why speculative instructions should be allowed to mutate the cache. OTOH the contention-based side channel attack on speculation has been public knowledge for over a d
47.
by contrarian_ 9y ago
Process isolation does not prevent Spectre. In theory, you can carry out Spectre over the network.
48.
by contrarian_ 9y ago
If it cleans cache, you can detect the evicted address tag.
49.
by contrarian_ 9y ago
Run it for long enough and you can average out the random drift. The issue cannot be fixed without disabling speculation entirely on current hardware.
50.
by contrarian_ 9y ago
There's also the diffraction limit: https://en.wikipedia.org/wiki/Diffraction-limited_system
51.
by contrarian_ 9y ago
The bar is just the right width for "(redacted)", I wouldn't read into it.
52.
by contrarian_ 9y ago
One page later: (redacted) hardware bugs. Sounds like something that would be hopefully fixable in microcode.
53.
by contrarian_ 9y ago
That only fixes one variant of Spectre, and only for code running in kernel mode. 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 s
54.
by contrarian_ 9y ago
No, that would not be enough. CPUs speculatively execute across multiple branches. Even if you had a separate speculative cache for every code path, you could still build a side-channel from the amount of contention. [1] [1] https:/&#
55.
by contrarian_ 9y ago
> New CPU microcode is enough What would that entail? Disabling speculation completely? Disabling memory accesses during speculation?
56.
by contrarian_ 9y ago
No, because there's correlated noise: all the stuff in between us and the planet.
57.
by contrarian_ 9y ago
Worse, no mitigation will ever be complete against Spectre, unless flat out disabling speculation across memory loads.
58.
by contrarian_ 9y ago
It's an arms race, there will always be new ways of exploiting this flaw in unexpected ways unless speculation is disabled entirely on existing CPUs.
59.
by contrarian_ 9y ago
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 hav
60.
by contrarian_ 9y ago
This is basically an arms race. As long as the fundamental issue is not fixed and all silicon replaced, there will always be people coming up with new ways of exploiting the Spectre vulnerability in unexpected ways.

More ›