OSDev.org

ACPI methods, when invoked, may trigger SMM which takes some other action behind the scenes. But does SMM parse and execute AML itself? Or does SMM, being programmed at the factory the same time as the DSDT, etc., natively know the hardware layout of the system?

SMM is supposed to be completely transparent to the OS and the user. It may read ACPI tables, or be hard coded, or it can do pretty much anything it wants with the system, and there's not much you can do about it.

It's part of the firmware, and you just have to trust that it's working properly.

I'm familiar with the concept, I was just wondering if anybody knew whether SMM might parse/execute AML. I could figure it out by setting data breakpoints on the DSDT and seeing if it triggers while the system is in SMM, but I thought somebody might already know.

Hi,

intx13 wrote:I'm familiar with the concept, I was just wondering if anybody knew whether SMM might parse/execute AML.

I can't see why the firmware's native SMM code would need to bother interpreting the firmware's AML. Note that nothing prevents the OS from copying/moving the AML so if SMM did rely on it the firmware would have to have 2 copies of it (one for OS, and a "hidden" version protected from the OS).

intx13 wrote:I could figure it out by setting data breakpoints on the DSDT and seeing if it triggers while the system is in SMM, but I thought somebody might already know.

That wouldn't work - when entering SMM the CPU stores your DR7 and sets DR7 to 0x00000400, which effectively disables your data breakpoints until after the CPU leaves SMM (and restores your DR7).


Cheers,

Brendan

Brendan wrote:Hi,
I can't see why the firmware's native SMM code would need to bother interpreting the firmware's AML. Note that nothing prevents the OS from copying/moving the AML so if SMM did rely on it the firmware would have to have 2 copies of it (one for OS, and a "hidden" version protected from the OS).

That's kind of where I was going with it - if they didn't duplicate the AML you could patch it and execute malicious AML from within SMM, which could patch the SMM entry point itself to jump to unprotected memory. Basically using a patched DSDT as a kernel-to-SMM exploit vector. But if SMM doesn't interpret AML then it basically has to duplicate all the information in the DSDT, etc. internally in some other format... or at least the parts it needs.

That wouldn't work - when entering SMM the CPU stores your DR7 and sets DR7 to 0x00000400, which effectively disables your data breakpoints until after the CPU leaves SMM (and restores your DR7).

I use a hardware debugger, I think it uses soft breakpoints for stuff like that, as opposed to the debug registers. I know it successfully can step/break through SMM code, I haven't tried data breakpoints yet.