The System Management Mode (SMM) is another mode of operation that, as already said, is supposed to be used to manage power functions.
Nowadays the Intel processors comes with a bunch of different modes and levels of privileges:
- the traditional Kernel and User Modes (Ring0 and Ring1)
- the VMX (root and non-root) mode, used by the Hypervisor, for virtualization purposes.
- the SMM mode, mainly for power management, but also to interact with the UEFI world.
It looks tricky on the first glance, because there are a lot of different possibilities to perform transitions between worlds with different capabilities an privileges (and a lot of different rules as well). But to summarize, every single transition is issued by a special instruction embedded on the processor native instruction set. In other words: the processor executes an assembly instruction to change its own mode.
USER(LAND) -------------> KERNEL ------------> SMM
[SYSCALL] [SMI]When the system is running with a Hypervisor, its called “dual monitor mode”, and this add more overhead to the transition possibilities .
But things are not so simple. To perform any “Mode Switch”, the processor will execute a lot of sanity and security routines to ensure that every requirement have been satisfied before executing the mode switch itself.
Volume 3 of the Intel processor manuals [1] already explained the
acceptable transitions between those modes:
------------------- SMI (interrupt)
|->|Real Address Mode| -------------------------------------------|
| ------------------- <----------------------------------| |
| | PE=1 ^ PE=0 (requires ring0) or |rsm or |
| v | reset |reset V
| ------------------- ---------
reset | | Protected Mode | -------> SMI (interrupt) ------> | SMM Mode |
| ------------------- <------- rsm instruction <------ ---------
| | VM=1 ^ VM=0 | ^
| v | |rsm |
| ------------------- <----------------------------------| |
|- |Virtual 8086 Mode| -------------------------------------------|
------------------- SMI (interrupt)Basically what we need to get from here is:
- Any mode of operation in the intel platform can make a transition to the SMM mode if an SMI interrupt is issued.
- SMM mode will return to the previous mode by issuing a rsm instruction (so the processor will read a saved-state to restore the system to the previous situation before enter the SMM).
https://web.archive.org/web/20130117213556/http://www.phrack.org/issues.html?issue=65&id=7#article
System Management Interrupt has the highest priority and can’t be masked. Most important facts about SMI handler execution environment:
- Similar to 16-bit real address mode with paging disabled.
- CS segment base is SMRAM base, EIP is 8000h.
- Segment limits are set to 4 GBytes, you can switch to protected mode or long mode to access all of the physical memory.
- All I/O ports are available.
- SMM code can read or modify saved execution context.
- SMM code can set it’s own IDT and use software interrupts.
As you can see, SMM code completely unaccessible from OS and OS can’t even notice when exactly SMI is being executed. There’s a several ways to generate SMI:
- Ring 0 code can trigger software SMI at any time by writing some byte value to APMC I/O port B2h.
- Internal chipset registers (SMI_EN, GEN_PMCON_1 and others) that accessible via PCI config space allows to enable or disable different kind of hardware SMI sources.
- You can route hardware interrupts into SMM by reconfiguring of advanced programmable interrupt controller (APIC) that integrated into CPU.
- I/O instruction restart CPU feature (chapter 34.12 of IA-32 Architectures Software Developer’s Manual) allows to generate SMI on any I/O port access by IN or OUT processor instruction.
http://blog.cr4.sh/2015/07/building-reliable-smm-backdoor-for-uefi.html
https://research.nccgroup.com/2023/04/11/stepping-insyde-system-management-mode/