Re: Can anyone explain why we should consider SPECTRE a hardware fault
Spectre lets you read other processes address space; Meltdown lets you read a privileged address space. Where it gets confusing is that the privileged address space is in your map, you just aren’t supposed to be able to peek at it. Sadly you are.
Modern CPUs have branch prediction mechanisms which inform the speculative execution mechanism whether it is likely a given (conditional) path will be followed. The predictor works from virtual addresses, which I think is part of the mistake, they should work from virtual address + Address Space IDentifier. Since my process has virtual addresses, as does my victims, and we likely share code in a shared library (libc.so, {mumble}.dll, ...) I can choose an address in my mapping of this library, and poison the branch predictor to favour a particular path. Then, when my victim runs in the area of this path, the branch predictor will follow it, and dirty the cache based upon the data. I then measure the cache dirt, and voila, I know what that data was.
Seems like a lot, but with the use of decent analysis tools to find candidate paths and a little reverse engineering of some programs, and a pile of money or bitcoins as the payoff, you are away.
It strikes me that there is a readily available mitigation for OSes: don’t permit the same virtual address to appear in two address spaces. This means that libc.so would be mapped to unique locations in each process. Most binaries are relocatable [ needed for ASLR ] so it shouldn’t be a big deal for them; that leaves only ‘forked’ processes as potential victims, and only forked copies of them can be used to induce the predictor.
This would have been tragic in 32bit machines, but 64bit machines, even with lowly 47 bit VAspace can still offer 1024 unique address spaces of 140 GBytes...
Biting the hand that feeds IT
