6 ms·
This is a good overview of modern, superscalar, out-of-order, speculative CPUs that literally any programmer could easily understand. Recommended reading for ev
by SomeHacker44 9y ago
This is a good overview of modern, superscalar, out-of-order, speculative CPUs that literally any programmer could easily understand. Recommended reading for every single engineer in the whole world (who doesn't already understand this stuff from reading source material e.g., Google Zero post).
- el_benhameen 9y agoAgreed. This was the best of the explanations I've read, and it helped me to finally wrap my mind around the exploits.
- vinn124 9y agoagreed
- DrTung 9y agoMe too. Finally I understand how the leakage works: no actual reading of kernel memory is taking place. Instead, the read-ahead/speculative logic causes one of two addresses in user space to be read, and thus placed in the cache. So, by reading both of them, and checking the time it took, the exploit can indirectly determine one bit (0 or 1) of kernel memory. Scary!
- foobarian 9y agoWhat are the exploits enabled by this? Seems like mostly security-related attacks on encryption keys and such.
- infinite8s 9y agoWell that value has to still be read into the cache, since the "kern_mem[address]&0x100" calculation is speculatively carried out. I don't think the MMU can do any bit level computations.
- crispinb 9y agoYes, CPU architecture is one of many subjects I don't know enough about, and this was both interesting & has added to my reading list. It's also quite fun to think that the little Pi I have chugging away in a tiny corner doing a variety of background tasks, which was already the most trouble-free machine I own, may also be the safest (OK I know that's an oversimplification, but I'm feeling affectionate towards it).
- PuffinBlue 9y agoNon-engineer here, this bit is key right: > However, suppose we flush our cache before executing the code, and arrange a, b, c, and d so that v is zero. Now, the speculative load in the third cycle: > v, y_ = u+d, user_mem[x_] > will read from either address 0x000 or address 0x100 depending on the eighth bit of the result of the illegal read. Because v is zero, the results of the speculative instructions will be discarded, and execution will continue. If we time a subsequent access to one of those addresses, we can determine which address is in the cache. Congratulations: you’ve just read a single bit from the kernel’s address space! To my understanding it is that saying that by... 1) ...flushing the cache so you have a 'clean' state, you can get... 2) ...the speculative execution to 'pull in' to cache the address user_mem[x_] but... 3) ...the particular address that's pulled into cache, 0x000 or 0x100, is determined by whether... 4) ...the illegal read of kern_mem[address] 8th bit was a 1 or 0... 5) ...which you can then subsequently determine the value of by... 6) ...timing how long it takes to access that user_mem[x] address once again and... 7) ...thereby leaking the value of kern_mem[address]... So you still have to perform some logic on the result of the speed of the access to the secondary address read right? If read of 0x000 is slow you know kern_mem[address] was a 1 and if fast kern_mem[address] a 0, and if 0x100 is slow you know kern_mem[address] was a 0 and if fast that kern_mem[address] was a 1? Is that correct? If it is it seems that timing is the key right, and actually the clever leap of creativity in completing the exploit, at least to my untrained mind. Please do correct anything I've got wrong, I'm not an engineer/developer!