5 ms·
My understanding: Because it may not be known whether or not the read will have ended up being prohibited at the time it's speculatively executed. Think of a s
by apendleton 9y ago
My understanding:
Because it may not be known whether or not the read will have ended up being prohibited at the time it's speculatively executed. Think of a simple for loop over the contents of an array: usually at the end of each loop iteration you jump back to the beginning of the loop, until the last time you don't, when i > array.length or whatever. The branch predictor will likely predict that the last time you'll jump back again (you always have before, and it doesn't know the actual value of array.length yet since that takes hundreds of cycles to come back from memory) and try to speculatively execute the contents of the loop body on what turns out to be out-of-bounds data. That's not typically malicious; it's at the end of pretty much every iteration over an array ever.
So then, if we can reliably get our loop to operate on a bit of data that might turn out to be out of bounds, the trick is then to have a loop body like this:
if (potentially_illegal_bit == 1) {
load_legal_location_1()
} else {
load_legal_location_2()
}
After the branch misprediction occurs, the state of the program gets rolled back so we don't know what potentially_illegal_bit itself was anymore, but we don't have to, we can surmise it from the cache contents. The program isn't going to do an illegal read, it's going to do a legal one, to either legal location 1 or legal location 2, and see which is faster (as only one of them should be cached). Both reads are legal and will succeed, so the only difference is the speed. We've now exfiltrated one bit of data from outside of your array bounds, but the only actually illegal read was speculative, which, as far as the CPU is concerned, is par for the course (predictions are wrong all the time), so no harm, no foul.
- Pxtl 9y agoAhhh, that's what I missed. I thought the "speculative execution" people were talking about was executing the tricks on the copied data after the illegal read. But not only that, the entire illegal operation can be fenced behind a speculative execution with a simple "if" branch. And illegal reads happen in that kind of context all the time because (for example) that's how every FOR loop ends. There's really two places where pipelining and speculative execution are causing this problem - the obvious one where the CPU is allowed to manipulate protected data before everything gets blown away (except cache loads of legal data, hence the problem), but a second one that means that reads of protected data happen all the time in normal branch prediction misses. When it happens in normal flow, you can't punish it by killing the process. Reading protected memory in a speculative branch isn't some digital "attempted breaking an entering" that you can clamp down hard on, it's totally normal behavior. I get it now, thanks.
- barsonme 9y agoThanks for this—I was struggling to figure out how the cache timing attack worked until your comment.
- taneq 9y agoThe thing that gets me about this attack is that it's so incredibly simple to execute, once you know what to look for. Most hacks require big chunks of super-specifically-formatted malicious data. This one just requires some simple code and a deep understanding of branch prediction.