[coreboot] we've always known this was possible and hence never bothered to do it but ...
btrotter at gmail.com
Mon May 12 08:49:00 CEST 2008
On Mon, May 12, 2008 at 12:44 PM, ron minnich <rminnich at gmail.com> wrote:
> somebody got around to it.
> The world, sooner or later, is going to get the message :-)
This is old news - I remember an article from a year or so ago
explaining a vulnerability that allows a video "driver" in user-space
on Linux to install it's own SMM code.
SMRAM is meant to be locked by the firmware so that software can't
enable SMRAM accesses. Some firmware doesn't lock SMRAM which creates
the problem. Under most sane OSs you need to be running at CPL=0 to
access I/O ports (and enable access to SMM space if it's not locked)
so it doesn't matter as much (because if you're running at CPL=0
anyway you don't need SMM to bypass security), but some OSs aren't so
good at protecting I/O ports.
Of course if everyone was using coreboot things would be much easier
AFAIK coreboot doesn't lock SMM space on *any* chipset, and also
leaves "SMRAM base" set to the default address 0x00030000 so that the
SMRAM area isn't underneath the legacy video display memory area (from
0x000A0000 to 0x000BFFFF) and can be accessed/modified regardless of
whether SMRAM is locked or not, or whether or not access to SMRAM is
enabled or not.
Of course there's always the added bonus that a hacker can download
the source code for coreboot, add their own malicious code, compile,
flash it and then sell the system on eBay to any unsuspecting sucker.
Coreboot really is the "rootkit friendly" way to go... :-)
More information about the coreboot