The main point to bring home is that these whiz-bang features in modern firmware such as SMM not only over-complicate the design but they also have unintentional consequences such as creating gaping holes in security.<br><br>
A lot of control is being handed off to obscure parts in firmware and executed in privileged mode these days, and there be dragons along the way.<br><br><div class="gmail_quote">On Sun, May 11, 2008 at 11:49 PM, Brendan Trotter <<a href="mailto:btrotter@gmail.com">btrotter@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>
<div class="Ih2E3d"><br>
On Mon, May 12, 2008 at 12:44 PM, ron minnich <<a href="mailto:rminnich@gmail.com">rminnich@gmail.com</a>> wrote:<br>
> somebody got around to it.<br>
> <a href="http://www.pcworld.com/businesscenter/article/145703/hackers_find_a_new_place_to_hide_rootkits.html" target="_blank">http://www.pcworld.com/businesscenter/article/145703/hackers_find_a_new_place_to_hide_rootkits.html</a><br>

><br>
> The world, sooner or later, is going to get the message :-)<br>
<br>
</div>This is old news - I remember an article from a year or so ago<br>
explaining a vulnerability that allows a video "driver" in user-space<br>
on Linux to install it's own SMM code.<br>
<br>
SMRAM is meant to be locked by the firmware so that software can't<br>
enable SMRAM accesses. Some firmware doesn't lock SMRAM which creates<br>
the problem. Under most sane OSs you need to be running at CPL=0 to<br>
access I/O ports (and enable access to SMM space if it's not locked)<br>
so it doesn't matter as much (because if you're running at CPL=0<br>
anyway you don't need SMM to bypass security), but some OSs aren't so<br>
good at protecting I/O ports.<br>
<br>
Of course if everyone was using coreboot things would be much easier<br>
(for hackers)...<br>
<br>
AFAIK coreboot doesn't lock SMM space on *any* chipset, and also<br>
leaves "SMRAM base" set to the default address 0x00030000 so that the<br>
SMRAM area isn't underneath the legacy video display memory area (from<br>
0x000A0000 to 0x000BFFFF) and can be accessed/modified regardless of<br>
whether SMRAM is locked or not, or whether or not access to SMRAM is<br>
enabled or not.<br>
<br>
Of course there's always the added bonus that a hacker can download<br>
the source code for coreboot, add their own malicious code, compile,<br>
flash it and then sell the system on eBay to any unsuspecting sucker.<br>
Coreboot really is the "rootkit friendly" way to go... :-)<br>
<br>
<br>
Cheers,<br>
<font color="#888888"><br>
Brendan<br>
</font><div><div></div><div class="Wj3C7c"><br>
--<br>
coreboot mailing list<br>
<a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="http://www.coreboot.org/mailman/listinfo/coreboot" target="_blank">http://www.coreboot.org/mailman/listinfo/coreboot</a><br>
</div></div></blockquote></div><br>