From: invalid@nospicedham.lkntrgzxc.com   
      
   On Mon, 8 Apr 2019 13:10:01 +0100   
   James Harris  wrote:   
      
   > I've had another thought on that since Robert Wessel pointed out in a   
   > different thread the presence of MTRRs. AIUI on a CPU with MTRRs the   
   > BIOS is likely to have programmed them before it boots an OS.   
      
   I'm not familiar with the MTRRs.   
      
   > I would guess, based on that, that addresses which do not have RAM   
   > behind them would be mapped as uncacheable.   
      
   FYI, "addresses which do not have RAM behind them" could mean something   
   other than nothing present, e.g., ROM, memory-mapped device, or I/O   
   port.  Although, you mentioned "unconnected" (snipped).   
      
   What is the purpose of mapping nothing present address regions as   
   uncacheable? ...   
      
   Is there any reason to not cache garbage data?  Anything not cached,   
   including garbage data, will slow down the processor, correct?   
      
   I.e., I would expect an uncacheable memory region to be a region which   
   is likely to have data that could be changed by something external to   
   the processor, e.g., a port or memory-mapped device.  For C, this would   
   be an object marked with the "volatile" keyword to ensure reads and   
   writes aren't optimized away.   
      
   > Incidentally, looking at those pages again it occurs to me that since   
   > some port accesses may be trapped by SMM code, the results they   
   > return will depend on code - possibly buggy code - rather than   
   > hardware. I think we may have seen that in KBC tests we ran on some   
   > machines.   
   >   
   > Another, related thought. We might be able to tell whether accesses   
   > to a certain port trapped to SMM or not by timing them. Normally, all   
   > such accesses are so fast we would never be able to tell whether they   
   > were implemented by code or hardware unless we checked a   
   > high-resolution timer like the TSC.   
      
   I'll discuss SMM, but SMM is something I wish to not get involved with.   
   SMM could implement unknowable interactions or changes to hardware or   
   software.  I have no control over SMM anyway, if something is wrong or   
   takes too long.  SMM seems like a backdoor attack vector ...  Etc.   
      
      
   Rod Pemberton   
   --   
   The lesson for Boeing.  You push the nose of a plane down, and planes   
   go down.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)