4 ms·

So, basically CPUs will read instructions inside a branch even if the branch is eventually going to evaluate to false. Does the CPU do this to optimize branch i

So, basically CPUs will read instructions inside a branch even if the branch is eventually going to evaluate to false. Does the CPU do this to optimize branch instructions? The results of instructions that are executed ahead of time are stored in a cache. How exactly does this exploit read from the cache? I understand it uses timing somehow but I'm not quite sure exactly how that works. (I mostly do software.)

cesarb 9y ago
The cache in question is not something which stores the result of these speculatively executed instructions, but the normal L1-L2-L3 caches we are used to. The result of these instructions is discarded, but as a side effect, they may load something from memory into the cache. The exploit detects whether or not a particular memory address was loaded into the cache (reading from something already in the cache is much faster than reading from the main memory).
- ateesdalejr 9y ago
  Thanks for the helpful answer. :) Things make much more sense to me now.
rocqua 9y ago
It's a timing attack against the cache. The speculative execution might need to do a read, which means something would need to be evicted from the cache. This makes a subsequent read against that evicted adres slower. This way you can detect things based on speculative execution. I don't know how they go from that to reading memory though.
- caf 9y ago
  You arrange things so that the speculated execution loads from an address you provide (this is the target address you want to read), then uses the result of that load to calculate the address of another load (this one, into a location that aliases in the cache with an address you can load directly yourself). You can then use cache timing to see which address was read in the second load, which means you can see part of the value that was read in the first load. Rinse, repeat. The variants mostly amount to differences in how you arrange the first part (speculated execution loading from an address you get to provide).
- pwg 9y ago
  > I don't know how they go from that to reading memory though. That was the second bit of the example source code: unsigned long index2 = ((value&1)*0x100)+0x200; This creates one of two different addresses, depending upon the value of bit zero of the memory location being attacked. The two different addresses are farther apart than the size of a cache line. > unsigned char value2 = arr2->data[index2]; This actually does the read from one of the two different addresses (which results in the value located at one of them becoming resident in cache). Note that the value returned here is a "don't care" item. Then, after everything unwinds from the speculation, the follow on code on the real path would read from both of the two possible addresses that were put into "index2". The read that returns data faster must have been in cache. Knowing which one was in cache, you now know the value of bit zero of the target address location. Repeat the same block of code for bits 1-7 and you'll have read a whole byte. Continue and you can read as much as you like. You just gather data very slowly (the article mentioned about 2000 bytes per second).
  - rocqua 9y ago
    Ah, that makes sense, thanks! I was thinking of something similar but with a branching operation, but that would get screwed by branch prediction.

cesarb 9y ago

The cache in question is not something which stores the result of these speculatively executed instructions, but the normal L1-L2-L3 caches we are used to. The result of these instructions is discarded, but as a side effect, they may load something from memory into the cache. The exploit detects whether or not a particular memory address was loaded into the cache (reading from something already in the cache is much faster than reading from the main memory).

ateesdalejr 9y ago
Thanks for the helpful answer. :) Things make much more sense to me now.

rocqua 9y ago

It's a timing attack against the cache. The speculative execution might need to do a read, which means something would need to be evicted from the cache. This makes a subsequent read against that evicted adres slower. This way you can detect things based on speculative execution. I don't know how they go from that to reading memory though.

caf 9y ago
You arrange things so that the speculated execution loads from an address you provide (this is the target address you want to read), then uses the result of that load to calculate the address of another load (this one, into a location that aliases in the cache with an address you can load directly yourself). You can then use cache timing to see which address was read in the second load, which means you can see part of the value that was read in the first load. Rinse, repeat. The variants mostly amount to differences in how you arrange the first part (speculated execution loading from an address you get to provide).
pwg 9y ago
> I don't know how they go from that to reading memory though. That was the second bit of the example source code: unsigned long index2 = ((value&1)*0x100)+0x200; This creates one of two different addresses, depending upon the value of bit zero of the memory location being attacked. The two different addresses are farther apart than the size of a cache line. > unsigned char value2 = arr2->data[index2]; This actually does the read from one of the two different addresses (which results in the value located at one of them becoming resident in cache). Note that the value returned here is a "don't care" item. Then, after everything unwinds from the speculation, the follow on code on the real path would read from both of the two possible addresses that were put into "index2". The read that returns data faster must have been in cache. Knowing which one was in cache, you now know the value of bit zero of the target address location. Repeat the same block of code for bits 1-7 and you'll have read a whole byte. Continue and you can read as much as you like. You just gather data very slowly (the article mentioned about 2000 bytes per second).
- rocqua 9y ago
  Ah, that makes sense, thanks! I was thinking of something similar but with a branching operation, but that would get screwed by branch prediction.