it looks like what he wanted to do was read kernel memory 1 bit at a time, by speculatively using the contents of kernel memory to cache memory from one of two user mode locations. He could then use timing to determine which user memory was cached, and thus the value of the bit of kernel memory.
There was something about hardware threads and multiple cores. If I understand correctly, he uses junk arithmetic to keep one core busy, or something.
Anyway, if that's all it was, then instead of using kernel page table isolation, and punishing all system calls, why not have the page fault interrupt handler/exception dispatcher flush the cache and maybe introduce a random delay, thus punishing the rarer (exceptional) access violation page faults instead of all system calls?
Note that the blog linked above was preliminary work which seems to have led up to this scandal. I haven't had time to read the details of the vulnerabilities/exploits themselves. I'm sure the OS devs would have thought of flushing the cache from the interrupt handler/exception dispatcher, so they seem to have felt that more was necessary.
Edit: i pasted the wrong URL.
Return to Index