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