For any yung'uns seeing this for the first time, the spectre and meltdown attacks (and accompanying papers) are worth reading.
Is there an example in the wild of a spectre exploit stealing my gmail cookie and doing something with it? (Would be difficult since it's tied to other fingerprints like my IP)
Or stealing credit card numbers when they're in memory after I place an online order?
For regular end-user desktop machines, the mitigations only decrease performance for no real benefit. Spectre is a highly targeted attack, it's not something you can just point at any random machine to retrieve all their bank passwords or whatever.
This gets repeated on every thread about speculative execution exploits, but I think people who say this are underestimating how huge the difference would be. I suspect processors without speculative execution would be many times slower, not "a bit".
DuckDuckGo works fine with no JS.
Perhaps, but I am not under this misunderstanding and never expressed it.
> Only specialized software/scenarios will tangibly benefit from the parasitic gains of SMT-induced extra parallelization
In my experience it also speeds up C++/Rust compilation, which is the main thing I care about. I can't find any benchmarks now but I have definitely seen a benefit in the past.
> video encoders like x264 or CPU-bound raytracers to name a few examples. These gains typically amount to about 15-20% at the very extreme end.
Normally those types of compute heavy processes, data streamlined, processes don’t see much benefit from SMT. After all SMT only provides a performance benefit by allowing the CPU to pull from two distinct chains of instructions, and fill the pipeline gaps from one thread, with instructions from the other thread. It’s effectively instruction-by-instruction scheduling of two different threads.
But if you’re running an optimised and efficient process that doesn’t have significant unpredictable branching, or significant unpredictable memory operations. Then SMT offers you very little because the instruction pipeline for each thread is almost fully packed, offering few opportunities to schedule instructions from a different thread.
But that doesn’t mean the process of compression involves significant amounts of unpredictable branching operations. If for no other reason than it would be extremely slow and inefficient, because many branching operations means you’re either processing input pixel-by-pixel, or your SIMD pipeline is full of dead zones that you can’t actually re-schedule, because it would desync your processing waves.
Video compression is mostly very clever signal processing built on top of primitives like convolutions. You’re taking large blocks of data, and performing uniform mathematical operations over all the data to perform what is effectively statistical analysis of that data. That analysis can then be used to drive a predictor, then you “just” need to XOR the predictor output with the actual data, and record the result (using some kind of variable length encoding scheme that lets you remove most of the unneeded bytes).
But just like computing the median of a large dataset can be done with no branches, regardless of how random or the large the input is. Video compression can also largely be done the same way, and indeed has to be done that way to be performant. There’s no other way to cram up to 4k * 3bytes per frame (~11MB) through a commercial CPU to perform compression at a reasonable speed. You must build your compressor on top of SIMD primitives, which inherently makes branching extremely expensive (many orders of magnitude more expensive than branching SISD operations).
It doesn't behave this way. If you're thinking of the DCT it uses that's mostly 4x4 which is not very large. As for motion analysis there are so many possible candidates (since it's on quarter-pixels) that it can't try all of them and very quickly starts trying to filter them out.
That's 16x32 which is AVX512. What other size would you suggest using and (more importantly) what commercially available CPU architecture are you running it on?
Yes. From actual experience.
The only real constraint is that you can actually leverage multiple threads. For protos as an example, that requires a modified version of the format with checkpoints or similar (which nobody does) or having many to work on concurrently (very common in webservers or whatever).
Edit: Arbitrary memory access, not ACE
Spectre is not an arbitrary code execution kind of attack.
The amount of actual exploit crafting that is needed to actually do something meaningful with a hack is pretty much not worth doing for any financial reason. The only time this happens now is when state funded actors or prominent groups with lots of manpower really want to take down an individual person.
Probably, but there’s a huge luck element involved, at least with spectre. It’s difficult to guide the speculative execution to read exactly what you want it to read, assuming you even know where it is. As a result you need to spend quite a bit of time on a single target before you’re likely to actually get the data you want. Even then, there’s likely a significant element of human analysis to assemble something useful from all the noise.
So yes, it’s almost certainly possible. But exploits don’t exist in a vacuum. If you’re expending that much effort to get credit card numbers, then quite frankly you’re a fool, because good old phishing attacks and other social engineering attacks are easier, more reliable, and above all, cheaper.
At the end of the day, crime is a business like any other, profitability and margins are king. You don’t waste time perfecting attacks that have significantly smaller margins than your existing attacks. The only exception to that is nation states, because they aren’t motivated by directly extracting cash from victims, and ultimately that’s what makes nation state actors so dangerous.
In the early days there was a ~10% hit, but that's changed a lot since then.
1. Read Flush + Reload
2. Then reproduce it in C
3. Then read Meltdown
4. Reproduce it in C
5. Read Spectre
6. Reproduce it in C
After that we had to implement a VUSEC paper. I chose GLitch [1].
A spectre (particularly RSB-based ones) are nice to start out with imo.
Here, they claim to have a remote exploit vulnerability. It's not that Apple is leaking data, it's that the CPUs have a bug where they appear to be actually executing code based on incorrectly-loaded ("predicted") data.
Though the details are, as is usually the case, thin. I await further analysis.
Now, maybe this is because of a trampoline based on pre-existing Safari bugs and not the CPU misfeature itself. Again, the details are slim.
But "the same flavor of vulerability" seems to be a mischaracterization.
Some of the earlier speculation attacks didn't get to do arbitrary compute on the speculated data, they could only for example influence whether something was loaded into cache or not.
This makes an attack easier to write.