View source for System Management Mode

{{Short description|Operating mode of x86 central processor units}}
{{more citations needed|date=November 2010}}
{{Use dmy dates|date=May 2019|cs1-dates=y}}
{{x86 Processor Modes}}

'''System Management Mode''' ('''SMM''', sometimes called '''ring&nbsp;−2''' in reference to [[protection ring]]s)<ref>{{cite web | url=https://www.blackhat.com/docs/us-15/materials/us-15-Domas-The-Memory-Sinkhole-Unleashing-An-x86-Design-Flaw-Allowing-Universal-Privilege-Escalation-wp.pdf | title=The Memory Sinkhole | date=20 July 2015 | accessdate=22 August 2015 | author=Domas, Christopher |publisher = [[Black Hat Briefings|Black Hat]]}}</ref><ref>{{cite web | url=https://www.blackhat.com/presentations/bh-usa-09/TERESHKIN/BHUSA09-Tereshkin-Ring3Rootkit-SLIDES.pdf | publisher=[[Invisible Things Lab]], [[Black Hat Briefings|Black Hat USA]] | date=29 July 2009 | accessdate=22 August 2015 |author1=Tereshkin, Alexander |author2=Wojtczuk, Rafal |title=Introducing Ring -3 Rootkits |page=4 }}</ref> is an operating mode of [[x86]] [[central processor unit]]s (CPUs) in which all normal execution, including the [[operating system]], is suspended.  An alternate software system which usually resides in the computer's [[firmware]], or a hardware-assisted [[debugger]], is then executed with high privileges.

It was first released with the [[Intel 386SL]].<ref>{{cite web|url=http://blogs.msdn.com/carmencr/archive/2005/08/31/458609.aspx|title=SMIs Are EEEEVIL (Part 1)|publisher=Microsoft|work=msdn.com|date=17 July 2020 }}</ref><ref>Ellis, Simson C., "The 386 SL Microprocessor in Notebook PCs", Intel Corporation, Microcomputer Solutions, March/April 1991, page 20</ref> While initially special SL versions were required for SMM, Intel incorporated SMM in its mainline 486 and Pentium processors in 1993. [[AMD]] implemented Intel's SMM with the [[Am386]] processors in 1991.<ref>{{cite web | url=http://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXwtys.pdf | title=AMD Am386SX/SXL/SXLV Datasheet|publisher=AMD}}</ref> It is available in all later [[microprocessor]]s in the x86 [[Computer architecture|architecture]].<ref>Intel Corporation, "NewsBits: Intel Support EPA's Energy Star Computer Program", Microcomputer Solutions, January/February 1993, page 1</ref>

In [[ARM architecture]] the Exception Level 3 (EL3) mode is also referred as Secure Monitor Mode or System Management Mode.<ref>{{Cite web | url=https://documentation-service.arm.com/static/5ed11e40ca06a95ce53f905c?token= | title=ARM® Management Mode Interface Specification | website=documentation-service.arm.com | year=2016}}</ref>

==Operation==
SMM is a special-purpose operating mode provided for handling system-wide functions like power management, system hardware control, or proprietary OEM designed code. It is intended for use only by system firmware ([[BIOS]] or [[UEFI]]), not by applications software or general-purpose systems software. The main benefit of SMM is that it offers a distinct and easily isolated processor environment that operates transparently to the operating system or executive and software applications.{{citation needed|date=December 2021}}

In order to achieve transparency, SMM imposes certain rules. The SMM can only be entered through SMI (System Management Interrupt). The processor executes the SMM code in a separate address space (SMRAM) that has to be made inaccessible to other [[X86#Operating modes|operating modes]] of the CPU by the [[firmware]].<ref>{{cite web |url=http://www.intel.com/design/processor/manuals/253669.pdf |title=Intel 64 and IA-32 Architectures Developer's Manual: Vol.&nbsp;3B |publisher=Intel}}</ref>

System Management Mode can address up to 4&nbsp;GB memory as [[huge real mode]]. In [[x86-64]] processors, SMM can address >4&nbsp;GB memory as real address mode.<ref>Intel 64 and IA-32 Software Development Manual, Vol.&nbsp;3, System Management Mode.</ref>

=={{Anchor|USB-LEGACY-SUPPORT}}Usage==
Initially, System Management Mode was used for implementing power management and hardware control features like [[Advanced Power Management]] (APM). However, BIOS manufacturers and OEMs have relied on SMM for newer functionality like [[Advanced Configuration and Power Interface]] (ACPI).<ref>{{cite web|url=http://blogs.msdn.com/b/carmencr/archive/2005/09/01/459194.aspx|title=SMIs Are EEEEVIL (Part 2)|publisher=Microsoft|work=msdn.com}}</ref><ref>{{Cite web|title=System Management Mode - OSDev Wiki|url=https://wiki.osdev.org/SMM|access-date=2020-09-12|website=wiki.osdev.org}}</ref>

Some uses of the System Management Mode are:
* Handle system events like memory or chipset errors
* Manage system safety functions, such as shutdown on high CPU temperature
* [[System Management BIOS]] (SMBIOS)
* [[Advanced Configuration and Power Interface]]
* Control [[power management]] operations, such as managing the [[voltage regulator module]] and [[LPCIO]] ([[super I/O]] or [[embedded controller]])
* Emulate [[USB]] mouse/keyboard as [[PS/2 port|PS/2]] mouse/keyboard (often referred to as ''USB legacy support'')<ref name="kernel.org">{{cite web
 | url = https://www.kernel.org/doc/Documentation/x86/usb-legacy-support.txt
 | title = Linux kernel documentation: USB Legacy support
 | date = January 2004 | accessdate = 2013-10-06
 | author = Vojtech Pavlik | publisher = kernel.org
}}</ref>
* Centralize system configuration, such as on Toshiba and IBM/Lenovo notebook computers
* Managing the [[Trusted Platform Module]] (TPM)<ref>[https://www.youtube.com/watch?v=X72LgcMpM9k&feature=player_detailpage#t=2070s Google Tech Talks – Coreboot – 00:34:30].</ref>
* BIOS-specific hardware control programs, including USB hotswap and [[Thunderbolt (interface)|Thunderbolt]] hotswap in [[operating system]] runtime<ref>[[UEFI Platform Initialization]] Specification.</ref>

System Management Mode can also be abused to run high-privileged [[rootkit]]s, as demonstrated at [[Black Hat Briefings|Black Hat]] 2008<ref>{{cite web |url=http://www.infoworld.com/d/security-central/hackers-find-new-place-hide-rootkits-252 |title=Hackers find a new place to hide rootkits |author=Robert McMillan |date=10 May 2008 |work=InfoWorld}}</ref> and 2015.<ref>{{cite web |url=http://hothardware.com/news/researchers-discover-rootkit-exploit-in-intel-processors-that-dates-back-to-1997 |title=Researchers Discover Rootkit Exploit In Intel Processors That Dates Back To 1997 |author=Rob Williams |date=7 August 2015 |work=HotHardware.com}}</ref>

==Entering SMM==
SMM is entered via the SMI (system management interrupt), which is invoked by:
* Motherboard hardware or chipset signaling via a designated pin ''SMI#'' of the processor chip.<ref name="rrc">[http://www.rcollins.org/ddj/Jan97/Jan97.html Intel's System Management Mode] by Robert R. Collins</ref>  This signal can be an independent event.
* Software SMI triggered by the [[system software]] via an I/O access to a location considered special by the motherboard logic (port {{mono|0B2h}} is common).<ref>{{cite patent | country = US | number = 5963738 | title = Computer system for reading/writing system configuration using I/O instruction}}.</ref>
* An I/O write to a location which the firmware has requested that the processor chip act on.

By entering SMM, the processor looks for the first instruction at the address SMBASE (SMBASE register content) + 8000h (by default 38000h), using registers CS = 3000h and EIP = 8000h. The CS register value (3000h) is due to the use of real-mode memory addresses by the processor when in SMM. In this case, the CS is internally appended with 0h on its rightmost end.

==Problems==
By design, the operating system cannot override or disable the SMI. Due to this fact, it is a target for malicious rootkits to reside in,<ref>{{cite web
 | url = http://www.eecs.ucf.edu/~czou/research/SMM-Rootkits-Securecom08.pdf
 | title = SMM Rootkits: A New Breed of OS Independent Malware
 | date = September 2008 | accessdate = 2013-10-06
 | author1 = Shawn Embleton | author2 = Sherri Sparks | author3 = Cliff Zou
 | publisher = ACM }}</ref><ref>{{cite news
 | url = http://www.pcworld.com/article/145703/article.html
 | title = Hackers Find a New Place to Hide Rootkits
 | date = 2008-05-09 | accessdate = 2013-10-06
 | publisher = PC World
}}</ref> including [[NSA ANT catalog|NSA's "implants"]],<ref>{{cite web |author=#1 Source for Leaks Around the World! |url=http://leaksource.wordpress.com/2013/12/30/nsas-ant-division-catalog-of-exploits-for-nearly-every-major-software-hardware-firmware/ |title=NSA's ANT Division Catalog of Exploits for Nearly Every Major Software/Hardware/Firmware &#124; LeakSource |publisher=Leaksource.wordpress.com |date=2013-12-30 |accessdate=2014-01-13 |archive-date=2014-01-02  |archive-url=https://web.archive.org/web/20140102120401/http://leaksource.wordpress.com/2013/12/30/nsas-ant-division-catalog-of-exploits-for-nearly-every-major-software-hardware-firmware/ |url-status=dead }}</ref> which have individual [[code name]]s for specific hardware, like SOUFFLETROUGH for [[Juniper Networks]] firewalls,<ref>{{cite web |url=https://www.schneier.com/blog/archives/2014/01/souffletrough_n.html |title=Schneier on Security: SOUFFLETROUGH: NSA Exploit of the Day |publisher=Schneier.com |date=2013-12-30 |accessdate=2014-01-13}}</ref> [[:File:Nsa-ant-schoolmontana.jpg|SCHOOLMONTANA]] for [[Juniper J-Series|J-series routers]] of the same company,<ref>{{cite web |url=https://www.schneier.com/blog/archives/2014/01/schoolmontana_n.html |title=Schneier on Security: SCHOOLMONTANA: NSA Exploit of the Day |publisher=Schneier.com |date=2008-05-30 |accessdate=2014-01-16}}</ref> [[:File:NSA DEITYBOUNCE.jpg|DEITYBOUNCE]] for DELL,<ref>{{cite web |url=https://www.schneier.com/blog/archives/2014/08/reverse-enginee.html |title=Schneier on Security |work=schneier.com|date=15 August 2014 }}</ref> or [[:File:NSA IRONCHEF.jpg|IRONCHEF]] for HP [[Proliant]] servers.<ref>{{cite web |url=https://www.schneier.com/blog/archives/2014/01/nsa_exploit_of_1.html |title=Schneier on Security: IRONCHEF: NSA Exploit of the Day |publisher=Schneier.com |date=3 January 2014 |accessdate=2014-01-13}}</ref>

Improperly designed and insufficiently tested SMM BIOS code can make the wrong assumptions and not work properly when interrupting some other x86 operating modes like [[Physical Address Extension|PAE]] or 64-bit [[long mode]].<ref>{{Cite web | url=http://images0.cnitblog.com/cnitblog_com/yuhensong/mode.JPG | format=JPG | title=Transitions Among the Processor's Operating Modes | website=images0.cnitblog.com}}</ref> According to the documentation of the [[Linux kernel]], around 2004, such buggy implementations of the USB legacy support feature were a common cause of crashes, for example, on motherboards based on the Intel [[E7505]] chipset.<ref name="kernel.org" />

Since the SMM code (SMI handler) is installed by the system firmware ([[BIOS]]), the OS and the SMM code may have expectations about hardware settings that are incompatible, such as different ideas of how the [[Advanced Programmable Interrupt Controller]] (APIC) should be set up.

Operations in SMM take CPU time away from the applications, operating-system kernel and [[hypervisor]], with the effects magnified for multicore processors, since each SMI causes all cores to switch modes.<ref>Brian Delgado and Karen L. Karavanic, "Performance Implications of System Management Mode", 2013 IEEE International Symposium on Workload Characterization, Sep.&nbsp;22–24, Portland, OR USA.</ref> There is also some overhead involved with switching in and out of SMM, since the CPU state must be stored to memory (SMRAM) and any write-back caches must be flushed. This can destroy real-time behavior and cause [[clock tick]]s to get lost. The Windows and Linux kernels define an "SMI Timeout" setting{{snd}} a period within which SMM handlers must return control to the operating system, or it will "[[Hang (computing)|hang]]" or "[[Crash (computing)|crash]]".

The SMM may disrupt the behavior of [[Real-time computing|real-time]] applications with constrained timing requirements.

A [[logic analyzer]] may be required to determine whether the CPU has entered SMM (checking state of ''SMIACT#'' pin of CPU).<ref name="rrc"/> Recovering the SMI handler code to analyze it for bugs, vulnerabilities and secrets requires a logic analyzer or disassembly of the system firmware.

==See also==
* [[Coreboot]]{{snd}} includes an open-source SMM/SMI handler implementation for some chipsets
* [[Intel 80486SL]]
* [[LOADALL]]
* [[MediaGX]]{{snd}} a processor which emulates nonexistent hardware via SMM
* [[Ring −3]]
* [[Unified Extensible Firmware Interface]] (UEFI)
* [[Basic Input/Output System]] (BIOS)
* [[Speculative execution CPU vulnerabilities]]

==References==
{{Reflist|30em}}

==Further reading==
* {{cite patent|country=US|number=5175853|title=Transparent system interrupt|inventor=James Kardach|inventor2=Gregory Mathews|inventor3=Cau Nguyen|inventor4=Sung S. Cho, Kameswaran Sivamani, David Vannier, Shing Wong, Edward Zager|assign=[[Intel Corporation]]|status=patent|pridate=1990-10-09|fdate=1991-11-06|pubdate=1992-12-29|gdate=1992-12-29}}
* [https://web.archive.org/web/20081207054135/http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_26049.pdf AMD Hammer BIOS and Kernel Developer's guide], Chapter 6 (archived from the original on 7 December 2008)
* [http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3c-part-3-manual.pdf Intel 64 and IA-32 Architectures Developer's Manual, Volume 3C], Chapter 34

[[Category:Rootkits]]
[[Category:X86 operating modes]]
[[Category:BIOS]]
[[Category:ARM architecture]]