[coreboot] cached SMI handler
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
> 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
Well, some chipsets allow you to reflash the ROM only in SMM if the
flash interface is locked.
More information about the coreboot