From: terje.mathisen@nospicedham.tmsw.no   
      
   Jan Bruns wrote:   
   >   
   > Terje Mathisen:   
   >> Jan Bruns wrote:   
   >   
   >>> I was wondering about why the intel cpus even do speculative memory   
   >>> reads in context of speculative code execution (during branch   
   >>> prediction). It simply looks like a (yet even harmful) waste of   
   >>> memory-bandwidth to me.   
   >>   
   >> This one is easy:   
   >>   
   >> Without branch prediction and the ability to execute code speculativly   
   >> past those branches, current computers would be far slower than what   
   >> they are, i.e. modern branch predictors actually work, and work very   
   >> well indeed. (95+% is pretty good guessing)   
   >   
   > But a loop like   
   >   
   > for (i=0; i   x = signed_integers[i];   
   >   y += (x>=0) ? some_mem[posx(x)] : some_mem[negx(x)];   
   > };   
   >   
   > totally depends on memory contents, will for that reason get mispredicted   
   > in 50% of all cases, and given that the fomula contains only minor   
   > arithmetic computation, the real theoretical bottleneck is memory access,   
   > that can only become worse if bandwidth is wasted by mispredicted paths.   
   >   
   >> Meltdown depends on having a cache that is shared among multiple   
   >> threads/processes, so that you have a covert channel which allows you to   
   >> detect what supposedly secure code is doing.   
   >>   
   >> The solution here is either to have no sharing at all across potentially   
   >> adversarial processes, or to make CPU hardware which doesn't actually   
   >> share anything between various security domains. Worst case you flush   
   >> all caches on every security boundary transition, best case you have   
   >> multiple caches (or multiple partitions of a single cache) so that what   
   >> the kernel does cannot influence a user-level cache (and vice versa).   
   >   
   > But it's still a CPU-bug, the memory access should be checked against   
   > privileges *before* the memory is actually accessed.   
      
   Not really, and this is key to why Meldown affects Intel but not AMD:   
      
   At least as far as we know here and now, it is perfectly OK to speculate   
   one level into memory, which AMD also does, but not to allow   
   out-of-order to run-ahead so far as to use the results of that primary   
   access to indirect into memory one more level.   
      
   AFAIK every single OoO cpu, since IBM invented the idea, have done that   
   speculative first-level memory access, but IBM and AMD have avoided the   
   trap of speculating into an additional level of indirection.   
      
   On a Mill (http://millcomputing.com/) any out-of-bounds access results   
   in a NaR (Not a Result) value instead of whatever byte(s) actually   
   resides at that address.   
      
   Terje   
      
   --   
   -    
   "almost all programming can be viewed as an exercise in caching"   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)