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.
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:
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
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.
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)?
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.
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.