[coreboot] cached SMI handler

Stefan Reinauer stepan at coresystems.de
Sat Feb 7 13:35:40 CET 2009


Kevin O'Connor wrote:
> On Fri, Feb 06, 2009 at 11:50:26PM +0100, Stefan Reinauer wrote:
>   
>> Occasionally a CPU might do speculative readahead on the SMRAM memory
>> while not in SMM. The chipset will generate master aborts on the PCI
>> bus, so the cached data is incorrect (0xff) and upon SMM entry the CPU
>> goes to nirvana. The SMM area in ASEG is always uncached. The upper
>> SMRAM areas can be cached, but they must only be cached while in SMM.
>>     
>
> If there is memory only accessible from SMM mode, then I agree it
> would need to be uncached.  I thought that Jason was just reserving
> memory for use by SMM - memory that could also be read/written in
> non-SMM mode.  In that case, I did not think caching needed to be
> disabled.  Indeed, the intel system programming guide recommends using
> some cached memory for SMM.
>   
I'm not involved in the details - But you are correct: The issue I
described can only occur when it is "locked" SMM memory, not just normal
RAM that happens to be accessed from SMM as well.
> Random thought - I wonder if the OS could "break into" SMM mode by
> turning on caching for the SMM area and then manipulating the cache
> contents so that an SMI used icache/dcache contents set by the OS
The attack scenario is realistic - the OS might gain control over the
cache contents through setting up MTRRs in some cases. The questions
come up whether this is exploitable and whether it's possible to make an
SMM handler safe against this kind of attack. I don't think you can
reasonably use the prefetchers to put exploit code in the cache by a CAR
approach. On some CPUs it is even explicitly suggested that the
prefetchers are disabled during CAR mode.
This leaves the OS dependent on some PCI device to answer the bus
requests instead leaving the chipset to generate a Master Abort.

The simplest way to avoid this is by putting the main SMI handler at
0xa0000, so it has control over the cache before it accesses the high
SMM memory. Right now the SMI handler I wrote does not use the high SMM
memory at all, so there's no immediate risk.

Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.dehttp://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866





More information about the coreboot mailing list