One Article Review
| Source |  Errata Security |
|---|---|
| Identifiant | 455358 |
| Date de publication | 2018-01-03 18:10:19 (vue: 2018-01-03 18:10:19) |
| Titre | Let\'s see if I\'ve got Metldown right |
| Texte | I thought I'd write down the proof-of-concept to see if I got it right.So the Meltdown paper lists the following steps: ; flush cache ; rcx = kernel address ; rbx = probe array retry: mov al, byte [rcx] shl rax, 0xc jz retry mov rbx, qword [rbx + rax] ; measure which of 256 cachelines were accessedSo the first step is to flush the cache, so that none of the 256 possible cache lines in our "probe array" are in the cache. There are many ways this can be done.Now pick a byte of secret kernel memory to read. Presumably, we'll just read all of memory, one byte at a time. The address of this byte is in rcx.Now execute the instruction: mov al, byte [rcx]This line of code will crash (raise an exception). That's because [rcx] points to secret kernel memory which we don't have permission to read. The value of the real al (the low-order byte of rax) will never actually change.But fear not! Intel is massively out-of-order. That means before the exception happens, it will provisionally and partially execute the following instructions. While Intel has only 16 visible registers, it actually has 100 real registers. It'll stick the result in a pseudo-rax register. Only at the end of the long execution change, if nothing bad happen, will pseudo-rax register become the visible rax register.But in the meantime, we can continue (with speculative execution) operate on pseudo-rax. Right now it contains a byte, so we need to make it bigger so that instead of referencing which byte it can now reference which cache-line. (This instruction multiplies by 4096 instead of just 64, to prevent the prefetcher from loading multiple adjacent cache-lines). shl rax, 0xcNow we use pseudo-rax to provisionally load the indicated bytes. mov rbx, qword [rbx + rax]Since we already crashed up top on the first instruction, these results will never be committed to rax and rbx. However, the cache will change. Intel will have provisionally loaded that cache-line into memory.At this point, it's simply a matter of stepping through all 256 cache-lines in order to find the one that's fast (already in the cache) where all the others are slow. |
| Envoyé | Oui |
| Condensat | mov points shl 0xc jz 0xcnow 100 256 4096 accessedso actually address address ; adjacent al all already are array array retry: mov bad because become before bigger but byte bytes cache cache ; cachelines can change code committed concept contains continue crash crashed don done down end exception execute execution fast fear find first flush following from got happen happens has have however indicated instead instruction instruction: instructions intel just kernel let line lines lists load loaded loading long low make many massively matter means meantime measure meltdown memory metldown mov multiple multiplies need never none not nothing now one only operate order others out paper partially execute permission pick point possible prefetcher presumably prevent probe proof provisionally provisionally and pseudo qword raise rax rax and rax register rax to rbx rcx read real reference referencing registers result results retry mov right secret see simply since slow speculative step stepping steps: ; stick that these thought through time top use value visible ways where which will write |
| Tags | |
| Stories | |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.