System Management Mode
System Management Mode (SMM) is an operating mode on x86 and x86-64 processors, intended for use by Firmware/BIOS to perform low-level system management operations while an OS is running.
The role of SMM
During platform initialization the PC's firmware (BIOS) has complete control of the system and can perform whatever configuration operations are required to prepare the system for an OS to take over. Once an OS is running it expects that it has complete control of the system. If the firmware developer would like the firmware to continue to have some control over the system, SMM is used.
SMM is intended to be completely transparent to the OS. When the system enters SMM, the firmware preserves the state of the CPU in a region of RAM designated as "SMRAM". During SMM the firmware performs low-level management operations like changing fan speeds, checking thermal zones, adjusting the CPU speed, etc. Before leaving SMM, the firmware restores the state of the CPU from SMRAM. From the perspective of the OS, those low-level management operations are happening atomically and automatically in the background.
Triggering SMM
SMM is triggered through a System Management Interrupt (SMI), a signal sent from the chipset to the CPU. During platform initialization, the firmware configures the chipset to cause a System Management Interrupt for various events that the firmware developer would like the firmware to be made aware of. The firmware also designates the region of RAM that should be used as SMRAM and specifies where the CPU should jump when an SMI occurs. During operation, the chipset detects the configured events and signals an SMI, triggering the CPU to enter SMM by jumping to the SMM entry point. The OS has no way of knowing when the chipset might signal an SMI and cannot "catch" System Management Interrupts like other interrupts. SMIs are not routed through the IVT/IDT.
An OS can ask the chipset to signal an SMI, although the handling of the SMI will still be transparent. This is performed by writing to a particular port (determined via ACPI). If the OS asks the chipset to signal an SMI and there is no reason for an SMI to be triggered at that particular moment, the firmware will not have much to do and the OS will regain control almost immediately.
SMM and ACPI
SMM predates ACPI. Without ACPI, it makes sense that the firmware would want to stay resident in memory even once an OS is running, because the OS may not have drivers for all of the thermal sensors, fans, and CPU performance settings that are available on that particular motherboard/chipset/CPU combination. With ACPI, however, the firmware stores AML code for the OS to interpret and execute; that AML tells the OS how to handle all those things. Theoretically, this means that SMM is not nearly as critical on a modern system as on a pre-ACPI system. However, at boot time the firmware has no way of knowing whether or not the OS includes a complete ACPI implementation or whether the OS is willing to take responsibility to managing power, thermal properties, and CPU performance. So by default, the firmware will still use SMM to handle all those things itself.
If, however, at some point the OS indicates to firmware that it does have a complete ACPI implementation, the firmware will stop performing those low-level management operations and will expect the OS to perform them instead. Even once the OS takes over, the chipset will still occasionally signal SMIs and the CPU will enter SMM, but the firmware will not have very much to do.
The firmware developer decides on the division of responsibilities between firmware and the OS. The firmware could store AML code that tells the OS exactly how to handle every single thing that might happen with the system, leaving the firmware with nothing to do and no real reason for SMM to be used. On the other hand, the AML code could simply tell the OS to tell the chipset to signal an SMI whenever anything happens, at which point the firmware will directly handle the event itself.
A simple example of SMM and ACPI is the power button. Pressing the power button causes the chipset to signal an SMI, sending the CPU into SMM and jumping to the SMM entry point. The firmware determines that the power button was pressed. By default, before the OS takes over low-level system management responsibilities, the firmware will handle the event by telling the chipset to tell the power switching component of the motherboard to turn off, and the system powers off immediately. If, however, the OS has indicated that it will handle low-level system management responsibilities, the firmware ignores the button press and updates the ACPI structures in memory to note that the event occurred. The OS can detect the event by examining the ACPI structures and perform any clean-up operations (like saving files) before it tells the chipset to tell the power switching component of the motherboard to turn off.
Transparency
TODO - write a bit about how SMM implements its transparent behavior, SMRAM, the lock bits in the MMU, etc.
What can I do with system management mode?
SMM is designed so that OS developers do not need to be aware of it, other than understanding its relationship with ACPI. Since code executing in SMM cannot be detected by the OS under normal circumstances, SMM is an attractive vector for advanced malware. CPU implementations of SMM and BIOS implementations of SMM firmware that can be detected, abused, or interfered with are significant security issues. TODO - include some links to Invisible Things and some SMM hacking papers.