home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.asm.x86      Ahh, the lost art of x86 assembly      4,675 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,274 of 4,675   
   Jan Bruns to All   
   Re: "old" files?   
   14 Feb 18 17:43:07   
   
   From: ebay@nospicedham.abnuto.de   
      
   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=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.   
      
   Gruss   
      
   Jan Bruns   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca