[coreboot] cached SMI handler

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Sat Feb 7 17:31:37 CET 2009

On 07.02.2009 17:11, Kevin O'Connor wrote:
> On Sat, Feb 07, 2009 at 01:35:40PM +0100, Stefan Reinauer wrote:
>> Kevin O'Connor wrote:
>>> 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 simplest way to avoid this is by putting the main SMI handler at
>> 0xa0000
> We're probably getting off topic.  But here is what I was thinking:
> * OS uses mtrr to cache memory at 0xa0000
> * OS loads a "jmp 0x10000" insn into L2 cache at 0xa0000
> * OS invokes an SMI (acpi defines a way to do this)
> If the SMI handler is set to run code at 0xa0000 (ie, it has an SMBASE
> of 0x98000), then it would see the 'jmp' insn and start running OS
> code at 0x10000.

This needs a unified cache, though.

>> 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.
> I don't think there is much risk anyway - if someone has full access
> to the machine to change cache settings, then they don't need SMM
> mode.

Well, some chipsets allow you to reflash the ROM only in SMM if the
flash interface is locked.



More information about the coreboot mailing list