You are not signed on; if you are a visitor please register for a free account!
|The Market Ticker Single Post Display (Show in context)||
User: Not logged on
|User Info||It's Operating As Designed (ROFL!); entered at 2018-01-03 23:14:11|
Registered: 2010-06-21 Florida
It's amusing to see Intel in the hot seat, but the actual likelihood of this bug being successfully exploited in the wild is pretty close to zero. Bitsquatting and Rowhammer are more practical attacks that have mostly gone ignored. (Seriously, google "bitsquatting", read Artem's paper, and prepare to be terrified.)|
There are no security implications for hypervisors because hypervisor memory is already in a separate address space, and this bug only allows you to read mapped memory for which you lack sufficient privilege. An attacker could only use this bug to read kernel memory. Linux is more vulnerable than other OSes because Linux normally creates a kernel mapping for all of physical memory, and this mapping could be used to read memory in other processes' working sets.
Next, you would first need to find a mapped kernel address. There is a paper from a couple of years ago that presented a timing attack to detect whether a given kernel address was in the TLB, but a defender could easily fix this by assuming a user fault on a kernel address is malicious and killing the process.
Since details haven't yet been disclosed, it's possible that the bug is more severe, but my assumption is that the attack uses timings to detect branch mispredicts and thereby infer the values of bits read during speculative execution. If that's the case, once you found an address to read, you could get at most 1 bit per ~50 cycles. (I am assuming that you would need 4~5 mispredicts at ~10 cycles each to create branch history.) That gives you ~10.5 MiB/s on a 4 GHz processor. However, this pattern is detectable, and to avoid detection you'd have to throttle back possibly even below 1 KiB/s.
The performance impact of the work-around really isn't going to be that bad because PCID eliminates all of the TLB invalidations you would otherwise suffer from switching address spaces. For Linux, the hardest part is dealing with race conditions involving user pages being migrated, which could lead to another dirty CoW type bug. Windows is ****ed because it's designed around the ability of the kernel to directly read/write user memory for performance. Quite a few 3rd party drivers do this and will break if Microsoft patches the kernel, so I expect they'll ignore it.
I am actually shocked that there isn't some bit in some MSR that can be flipped to disable speculation. It would still have caused a significant performance loss, but it would have been fixable in the BIOS.