From: terje.mathisen@nospicedham.tmsw.no   
      
   Anton Ertl wrote:   
   > Terje Mathisen  writes:   
   >> 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.   
   >   
   > Actually Meltdown is the attack that allows a user process to read   
   > kernel memory, if the kernel is mapped (but unreadable) in the user   
   > process.  It does not depend on sharing of the caches between   
   > processes.  The process reads the kernel memory speculatively, and   
   > some CPUs (e.g., most Intel CPUs) actually continue speculatively with   
   > the result, eventuelly squashing the whole path; but the side effect   
   > on the caches is observable and can be exploited to extract the kernel   
   > data into the user process.   
      
   Sorry, terminology mismatch:   
      
   By "shared cache" I meant that it is shared across process protection   
   boundaries, so that a speculative access to a kernel address (later   
   squashed as you note) still have visible side-effects in the user   
   process cache.   
      
   I agree that I could have been clearer, but we have discussed actual   
   Meldown code previously here in clax.   
      
   The key is of course that any out of bounds access cannot be allowed to   
   provide side channel effects, it isn't sufficient to suppress   
   architecturally defined results.   
      
   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)