5 ms·

I guess Intel decided to speculate data access regardless of privilege level of the target address, with the theory that what has been successfully speculated c

by wilun 9y ago

I guess Intel decided to speculate data access regardless of privilege level of the target address, with the theory that what has been successfully speculated can't be accessed anyway before the permission are really checked, and somebody found a bug (or given all Intel processors are taggued as unsecure, maybe a quasi-architectural hole) that let read the speculated data or a significant subset or trace of it. My wild guess is that you can read a good portion (if not all) of the memory (or a significant subset or trace of it) of the whole computer from unprivileged userspace programs.

zimmerfrei 9y ago
Could this be possibly fixed with a microcode update in the future (at least for most recent models for which Intel is still bound to some kind of warranty)?
- justincormack 9y ago
  I think probably not, I think it may be too fundamental. But perhaps there is a mitigation if only a few instructions cause the leak and they can disable those in speculation. Performance hit could be bad though, worse than the Linux fix.
rst 9y ago
One possible vector suggested by Matt Tait (pwnallthethings) on Twitter: if speculative operations can influence what the processor does with the cache, the results can be observed with cache timing attacks. If the branch predictor reads the results of speculative operations, it's real easy, as he suggests here: https://twitter.com/pwnallthethings/status/947978927284383744 https://twitter.com/pwnallthethings/status/94797892728438374... but (as he notes elsewhere) there are plenty of other channels in an Intel processor for information to leak...
- Taniwha 9y ago
  my guess is that the cache tags or tlb entries loaded on failed speculative accesses are wrong (maybe the valid bit is set but the address wasn't changed, or the user/supervisor protections are munged), that could leave you with a cache line or page tagged as user accessible but really protected kernel data
contrarian_ 9y ago
Perhaps an interaction with conditional branches and cache timing? You could then extract individual bits from privileged memory by having the CPU pull in specific cache lines as part of a speculatively executed branch on the value of the bit.

by wilun 9y ago

zimmerfrei 9y ago

Could this be possibly fixed with a microcode update in the future (at least for most recent models for which Intel is still bound to some kind of warranty)?

justincormack 9y ago
I think probably not, I think it may be too fundamental. But perhaps there is a mitigation if only a few instructions cause the leak and they can disable those in speculation. Performance hit could be bad though, worse than the Linux fix.

rst 9y ago

One possible vector suggested by Matt Tait (pwnallthethings) on Twitter: if speculative operations can influence what the processor does with the cache, the results can be observed with cache timing attacks. If the branch predictor reads the results of speculative operations, it's real easy, as he suggests here: https://twitter.com/pwnallthethings/status/947978927284383744 https://twitter.com/pwnallthethings/status/94797892728438374... but (as he notes elsewhere) there are plenty of other channels in an Intel processor for information to leak...

Taniwha 9y ago
my guess is that the cache tags or tlb entries loaded on failed speculative accesses are wrong (maybe the valid bit is set but the address wasn't changed, or the user/supervisor protections are munged), that could leave you with a cache line or page tagged as user accessible but really protected kernel data

contrarian_ 9y ago

Perhaps an interaction with conditional branches and cache timing? You could then extract individual bits from privileged memory by having the CPU pull in specific cache lines as part of a speculatively executed branch on the value of the bit.