Re: Crap indeed
A problem seems to be that the data is feed into the data pipeline (and L1 cache?) via speculative execution. To simplify the problem... if you have some code like:
if(false) {
x=some data that shouldn't work
} else {
do something slow
}
y=some data that shouldn't work
The x= gets the data loaded into the cache while the slow code is slow enough to make sure it gets there. Then the y= pulls data that is in the cache (and whatever makes up the other 64 bytes in its cache line) and that might not be checked against the permission bits in the virtual memory tables. I can't think of any situations where the x86 does speculative writes that would hit memory so this should be limited to reading data. The trick might work to slow down memory sharing on multi-core systems. x86 I/O sometimes is read based so that reading a memory location could resets a counter or buffer and that would be a problem limited to some i/o device. If someone can come up with a way to have the speculative data being read and then written back through the cache, the security game is over.
Biting the hand that feeds IT
