System Management Mode Explained: SMRAM, SMI Handlers, Protections

System Management Mode (SMM) is a special x86 operating mode reserved for platform firmware. A System Management Interrupt (SMI) switches a processor into it, the firmware's SMI handler runs from a protected memory region called SMRAM, and the RSM instruction returns control to the operating system, which never sees what happened in between.

Because SMM code can touch all of memory and the flash chip that holds the firmware, the whole design depends on firmware locking SMRAM and SMM configuration before the operating system starts, and on every SMI handler treating data from the OS as hostile. This guide goes one level deeper than our posts on CPU microcode updates, coreboot and how the motherboard evolved from BIOS to UEFI, TPM and BMC. We read the System Management Mode chapter of the Intel 64 and IA-32 Architectures Software Developer's Manual (Volume 3, revision 093, September 2026), Microsoft's Windows SMM Security Mitigations Table and System Guard documentation, the TianoCore EDK II source tree, coreboot's SMM documentation, the CHIPSEC module documentation, the fwupd Host Security ID specification, AMD's product security bulletin AMD-SB-7014 and NIST SP 800-193. The UEFI Forum's website refuses scripted downloads, so where we describe the Platform Initialization (PI) specification we rely on how EDK II, which implements it, names and documents the same interfaces.

This is a defensive explainer. It describes how SMM works, how firmware protects it, the classes of mistakes that have weakened it, and how to check a machine you own. It contains no attack steps.

Key takeaways

• SMM is entered only through an SMI and left only through the RSM instruction. Intel's manual says SMM "was introduced into the IA-32 architecture in the Intel386 SL processor" and is intended "for use only by system firmware".
• On entry the processor saves its state into SMRAM, disables paging and normal interrupts, and starts the SMI handler at SMBASE plus 8000H. The default SMBASE after reset is 30000H, and firmware relocates it for every logical processor during boot.
• "Ring minus 2" is an informal nickname, not an architectural term. It captures the idea that SMM sits below the kernel (ring 0) and the hypervisor (often called ring minus 1): coreboot's documentation says SMM "has a higher privilege level than ring0", and Microsoft says SMM code "executes in the highest privilege level and is invisible to the OS".
• SMRAM is protected by several independent locks: the chipset's compatible SMRAM lock (D_LCK), locked TSEG base and limit registers that also keep devices from reaching SMRAM by DMA, the CPU's System Management Range Registers (SMRR), and on newer Intel processors an SMM code access check that stops SMM from executing outside SMRAM. Each must be set and locked by firmware before the OS runs.
• SMI handlers do real work on a normal PC: power and thermal management, hardware control, gating writes to the firmware flash, and running the authenticated UEFI variable service in EDK II based firmware.
• The recurring weakness classes are unlocked SMRAM, SMRAM caching, DMA into SMRAM, SMM callouts (SMM code calling or reading outside SMRAM), confused deputy pointer bugs in handler inputs, and race conditions. Microsoft's WSMT, EDK II's memory checks and coreboot's helper functions all target the pointer class.
• On Linux, fwupdmgr security reports the Host Security ID (HSI) attributes, including SPI flash protections that rely on SMM and, on AMD systems, an org.fwupd.hsi.Amd.SmmLocked attribute. CHIPSEC goes deeper with modules such as common.smm, common.smrr, smm_dma, common.smm_code_chk, common.bios_wp and common.bios_smi, but it needs a kernel driver and belongs on a test machine.
• Fixes for SMM issues ship as system firmware from the board or system maker, even when the root cause is in silicon vendor reference code. Track the maker's advisories and the Linux Vendor Firmware Service (LVFS), and confirm the installed BIOS version afterwards.

What is System Management Mode?

Intel's Software Developer's Manual (SDM) describes SMM as "a special-purpose operating mode provided for handling system-wide functions like power management, system hardware control, or proprietary OEM-designed code." The same chapter says SMM offers "a distinct and easily isolated processor environment that operates transparently to the operating system". The operating system does not schedule it, cannot see it run and cannot stop it.

Where did SMM come from?

The SDM says SMM was introduced into the IA-32 architecture in the Intel386 SL processor, which it calls "a mobile specialized version of the Intel386 processor", and is also available in the Pentium M, Pentium 4, Intel Xeon, P6 family, Pentium and later Intel486 processors. The problem it solved was laptop power management: firmware needed a way to power down a disk or a display, or suspend the whole machine, without depending on an operating system that knew nothing about that particular laptop's hardware. AMD's x86 processors implement SMM as well, with their own SMRAM control registers, which is why the CHIPSEC and fwupd checks later in this post have separate Intel and AMD variants.

How does an SMI enter SMM?

The SDM is explicit: "The only way to enter SMM is by signaling an SMI through the SMI# pin on the processor or through an SMI message received through the APIC bus." In practice the chipset raises SMIs for many reasons: a timer, a power button press, a write to a dedicated I/O port, an access to a trapped I/O address, a change to a protected chipset register, or a write to a BIOS control bit. The SDM also lists properties that make SMIs different from ordinary interrupts:

• An SMI is a nonmaskable external interrupt that "operates independently from the processor's interrupt- and exception-handling mechanism and the local APIC".
• It takes precedence over a non maskable interrupt (NMI) and over maskable interrupts.
• SMM is non reentrant. While a processor is in SMM, further SMIs are latched, and only one is remembered and serviced after RSM.
• The processor handles an SMI at an instruction boundary, after it waits "for all instructions to retire and for all stores to complete."

When the SMI arrives, the processor saves its current context in SMRAM, enters SMM and starts executing the SMI handler. It also signals external hardware that it is now in SMM. That signal matters: the chipset uses it to decide whether a memory access to the SMRAM range should reach SMRAM at all.

What does the processor do on entry?

The SDM's initial SMM execution environment is a flat, real mode like state with paging off. The processor clears the PE and PG bits in CR0, clears CR4, sets the code segment base to SMBASE and the instruction pointer to 8000H, and gives every data segment a 4 GB limit. Maskable interrupts, exceptions, NMIs, further SMIs, single step traps, breakpoints and INIT are all inhibited on entry.

Modern firmware does not stay in that 16 bit environment. The SDM allows an SMI handler to switch to protected mode, enable paging, or enter 64 bit mode, as long as it redoes that transition after every SMI. EDK II's SMM CPU driver does exactly that, which is how it can apply page tables and memory protections inside SMM, a point we come back to under mitigations.

How does SMM end?

"The only way to exit SMM is to execute the RSM instruction." RSM is only valid in SMM; executed anywhere else it raises an invalid opcode exception. RSM reloads the saved state from SMRAM and returns to whatever mode the processor was in when the SMI arrived. If it finds invalid saved state, such as an illegal combination of control register bits, the processor enters a shutdown state instead of resuming.

Why is it called ring minus 2?

x86 protection rings run from ring 3 (applications) to ring 0 (the kernel). Hardware virtualisation added a hypervisor that controls ring 0 guests, which people informally call ring minus 1. SMM sits below both, so it picked up the nickname ring minus 2. None of those negative numbers appear in Intel's manual. The nickname is shorthand for three real properties:

1. SMM code can address all physical memory, including the kernel and the hypervisor. Microsoft's System Guard documentation notes that "SMM code can potentially access hypervisor memory and change the hypervisor".
2. SMM runs whenever an SMI fires, regardless of what the OS is doing, and the OS cannot intercept it under the default treatment.
3. SMRAM is hidden from every other mode when it is locked correctly, so the OS cannot inspect what SMM is doing.

The nickname also explains why SMM is valuable to defend. Anything that gets code running in SMM can sit beneath every protection the operating system builds, and on many platforms SMM also controls who may write the firmware flash.

A dated timeline of SMM and its defences

The dates below come from the documents we fetched. Where a date comes from a citation inside another document, the row says so.

What is SMRAM, and how is it locked?

SMRAM is system management RAM: the memory that holds SMM's code, data, stacks, page tables and the per processor saved state. The SDM says the SMI handler's "critical code and data reside in a memory region referred to as system-management RAM (SMRAM)", and that the processor uses a fixed area inside it to save the interrupted context.

Layout: SMBASE, the entry point and the save state

The architectural layout is simple. The SDM defines a default SMRAM of 64 KB starting at SMBASE. The first instruction of the handler is at SMBASE plus 8000H, and the processor's saved state occupies SMBASE plus FE00H to SMBASE plus FFFFH. The decoded SMRAM can be anywhere from 32 KB to 4 GB.

Every processor starts with the same SMBASE of 30000H after a hardware reset. The SDM tells initialisation software to "sequentially place each processor in SMM and change its SMBASE so that it does not overlap those of other processors." The mechanism is the SMBASE field in the save state map: firmware writes a new value there, and RSM loads it into the processor's internal SMBASE register for the next SMI. This relocation is one of the first things platform firmware does on every boot, on every core, because a multi core system needs a separate save state area per logical processor.

Where SMRAM lives: compatible SMRAM and TSEG

The SDM leaves the physical placement to "system logic", meaning the chipset or the memory controller in the processor. On PC platforms that has produced two common regions:

• Compatible SMRAM, a legacy window in low memory that overlaps the old video memory range (CHIPSEC calls it CSEG; AMD documentation calls the equivalent ASeg). The SDM's own advice on SMRAM caching describes this arrangement: an uncached section that "overlaps video memory (typically located in low memory)", from which the initial SMM code jumps into a dedicated region.
• TSEG, the "top of memory segment", a dedicated region carved from the top of usable DRAM below 4 GB. Modern firmware puts nearly all SMM code and data here. The firmware memory map reports it to the OS as reserved memory, and Microsoft's Secure Launch requirements say TSEG must be reported as EfiReservedMemoryType.

The locks that protect SMRAM

No single bit protects SMRAM. Each lock covers a different path into it, and all of them have to be configured and then locked by firmware before third party code, such as option ROMs or the OS loader, runs.

A few details from the primary sources are worth spelling out.

SMRR. The SDM says that if IA32_MTRRCAP bit 11 is set, the processor supports SMRR, and that SMM software "is strongly encouraged to use it". The two MSRs "may be written only in SMM". Once the valid bit is set, accesses to the range from outside SMM behave as follows: "write accesses are ignored and read accesses return a fixed value for each byte", and the uncacheable memory type is used. CHIPSEC's module documentation explains why the cache detail matters: if software outside SMM could make SMRAM cacheable and fill cache lines at SMBASE, the processor could later execute those cached lines when an SMI fired. SMRR forces uncacheable behaviour from outside SMM. The SDM also notes the limit: "The SMRR interface can protect only the first 4 GBytes of the physical address space", which is one reason TSEG sits below 4 GB.

The code access check. In the SDM's section on model specific SMM enhancements for the 4th generation Intel Core processors, firmware can turn on a check under which "an attempt by the SMM handler to execute outside the ranges specified by SMRR ... will cause the assertion of an unrecoverable machine check exception". The control lives in MSR_SMM_FEATURE_CONTROL at address 4E0H, which raises a general protection fault if touched outside SMM. CHIPSEC's smm_code_chk module checks that SMM_CODE_CHK_EN is set and locked, and describes it as "an important step in mitigating SMM call-out vulnerabilities". EDK II exposes the same feature through the PcdCpuSmmCodeAccessCheckEnable build setting, whose description says "the SMM handler cannot execute the code outside SMM regions" and that it is "suggested to TRUE in production image."

DMA. CHIPSEC's smm_dma documentation puts it simply: SMRAM needs protecting from devices with direct memory access just as it does from software on the CPU, and that protection depends on firmware programming and locking the TSEG range registers. An input output memory management unit (IOMMU) adds another layer, which is why the fwupd HSI checks for pre boot DMA protection and an enabled IOMMU sit alongside the SMM checks.

What does firmware put in SMRAM?

The SDM says SMRAM holds the handler's code and data, the saved state, and can hold "system configuration and specific information about powered-down devices" and "OEM-specific information". In an EDK II based UEFI firmware, SMRAM typically contains:

• The SMM core (the dispatcher that loads SMM drivers and routes SMIs to registered handlers).
• The SMM CPU driver, which relocates SMBASE on every processor, synchronises processors during an SMI, and builds the page tables SMM uses after it switches to 64 bit mode. In the EDK II tree this is UefiCpuPkg/PiSmmCpuDxeSmm.
• Chipset and platform SMI handlers: power button, sleep state transitions, I/O traps, the software SMI dispatcher, and the BIOS write protection handler.
• The SMM half of the UEFI variable service. EDK II's VariableSmm driver "installs SMM variable protocol into SMM protocol database". A separate runtime driver outside SMM forwards variable requests into it.
• A lock box, a small store EDK II uses to keep data such as S3 resume configuration where the OS cannot tamper with it.
• Per CPU stacks, save state areas and, when enabled, guard pages for stack overflow detection (PcdCpuSmmStackGuard, which defaults to TRUE in UefiCpuPkg.dec).

What do SMI handlers do on a real PC?

The SDM's own examples are "powering down unused disk drives or monitors, executing proprietary code, or placing the whole system in a suspended state." Microsoft's System Guard page lists "power management, hardware configuration, thermal monitoring, and anything else the manufacturer deems useful." On current machines the work falls into a handful of groups.

Power, sleep and thermal events

The chipset raises SMIs on power button presses, on transitions into sleep states and on some thermal events. On ACPI systems much of this has moved to ACPI firmware tables interpreted by the OS, but SMI handlers still perform the low level steps the OS cannot, such as saving chipset state before a sleep transition. The SDM also describes how an SMI used to power down the processor must save registers that the processor does not save automatically, such as the MTRRs and debug registers.

Trapping I/O to emulate or wake devices

The SDM's I/O instruction restart feature exists so that "if an I/O instruction is used to access a powered-down I/O device, a chipset supporting this device can intercept the access and respond by asserting SMI#." The handler powers the device up and asks the processor to re execute the original I/O instruction on RSM. The same trap and restart pattern is the general mechanism firmware can use to present a legacy device that is not physically there, so that software written for older hardware keeps working before a modern OS driver takes over.

Guarding the firmware flash

On many Intel platforms the BIOS region of the SPI flash can be written only with SMM's cooperation. CHIPSEC's bios_wp module documentation describes the scheme. A BIOS write enable bit (BIOSWE) allows writes. When the BIOS Lock Enable (BLE) bit is set, an attempt to set BIOSWE generates an SMI, "This way, the SMI handler can decide whether to perform the write." Because a race existed between the write and the SMI, a further bit, which CHIPSEC calls EISS or SMM_BWP, makes the BIOS region writable only when all processors are in SMM. The fwupd HSI specification describes SMM_BWP the same way: it "must be set to make the BIOS region non-writable unless all processors are in system management mode."

This is why SMM security and firmware persistence are tied together. If an attacker can run code in SMM, the SMM based flash protection no longer protects anything. Our post on SPI flash write protection covers the flash side, including the protected range registers that work independently of SMM.

Authenticated UEFI variables

UEFI Secure Boot keys and many firmware settings live in UEFI variables stored in flash. In EDK II, writes to authenticated variables are verified inside SMM so that the OS cannot bypass the signature check by writing the flash directly. The VariableSmm.inf description is candid about the trust assumption: "The whole SMM authentication variable design relies on the integrity of flash part and SMM." It also warns that the variable data and communication buffer it receives in SMM are external input that "must be validated carefully to avoid security issues such as buffer overflow or integer overflow."

How the OS and DXE drivers talk to SMM

Most SMIs are not raised by the OS on purpose, but some are: a runtime service such as SetVariable has to reach the SMM variable driver. The UEFI PI specification defines a communication interface for this, and EDK II implements it. A caller outside SMM places a request in a communication buffer and triggers a software SMI; the SMM core dispatches the request to the handler registered for its GUID; the handler reads the buffer, does the work and writes a response.

EDK II's PiSmmCommunicationRegionTable.h explains where those buffers should live. If the EDK II communication region table is present, "the SMM communication buffer is restricted to EfiReservedMemoryType, EfiACPIMemoryNVS, or EfiRuntimeServicesData." Any non SMM component may then put communication data there and use the "UEFI defined SMM Communication ACPI Table, or PI defined EFI_SMM_COMMUNICATION_PROTOCOL" to reach the handler. That fixed placement is what Microsoft's WSMT asks firmware to guarantee, and it is the root of most SMM hardening.

Traditional MM and Standalone MM

Newer PI specifications rename SMM to Management Mode (MM) so the same model can cover other architectures. EDK II has two flavours. Traditional SMM drivers are loaded from the DXE phase and share some code paths with the rest of firmware. Standalone MM, in StandaloneMmPkg, loads MM drivers in an environment that does not depend on DXE services, which shrinks what SMM trusts. The package carries Arm copyrights as well as Intel ones because the same Standalone MM core can run in an Arm secure partition, which is one place where the x86 and Arm designs in the comparison table below meet.

What are the classic SMM vulnerability classes?

The classes below are described conceptually, with the defence each one led to. They are drawn from the CHIPSEC module documentation, Microsoft's WSMT guidance, EDK II and coreboot comments, and AMD's bulletin.

1. SMRAM left unlocked or misconfigured

If firmware forgets to set the compatible SMRAM lock, or leaves TSEG range registers unlocked, ordinary kernel code can read or change SMM code and data. CHIPSEC's common.smm documentation cites a 2006 paper describing exactly that on some platforms: when D_LCK is not set, "SMRAM can be accessed even when the CPU is not in SMM." The defence is configuration, and it is checkable from the OS, which is why these checks were the first ones CHIPSEC shipped and why fwupd treats several of them as minimum requirements.

2. Cache based access to SMRAM

Before SMRR, if software could mark SMRAM as cacheable from outside SMM, cache contents could disagree with SMRAM itself. The defence is SMRR, configured by firmware in SMM, plus the SDM's guidance on keeping SMRAM in a dedicated region.

3. DMA into SMRAM

Devices that can master the memory bus do not go through the CPU's checks. If the memory controller's SMRAM range is not locked, a device could be pointed at it. The defences are locked TSEG registers and an IOMMU configured before devices are allowed to run.

4. SMM callouts

An SMM callout happens when code running in SMM calls a function, or reads a function pointer or data structure, that lives outside SMRAM. Code outside SMRAM is controlled by the OS, so a callout hands SMM's privilege to whoever controls that memory. This was common in firmware where SMM drivers were built from the same code as boot time drivers and kept pointers to boot services or protocol tables. The defences are layered: the Intel code access check (a machine check if SMM executes outside SMRR), EDK II page tables in SMM that mark non SMRAM memory as non executable, and Standalone MM, which removes dependencies on DXE services altogether.

5. Confused deputy pointer bugs

This is the most common class in practice. A handler accepts a buffer address or an offset from the OS and writes a result to it. If the handler does not check that the address is outside SMRAM, and inside memory the caller is allowed to use, the OS can trick SMM into writing to SMRAM or to memory that belongs to the hypervisor. SMM is the deputy with the authority; the OS is the party confusing it.

Microsoft's WSMT page names this explicitly. It says "All SMI handlers must be restricted to only access (read or write) to allowable memory regions that contain MMIO and EFI-allocated memory", and "It is not sufficient to check that pointers in SMM do not reference memory entirely outside of SMM." Every pointer must be validated against the safe regions, which "prevents SMM from being exploited in a 'confused deputy' attack."

The open firmware projects ship helpers for this. EDK II's SmmMemLib provides SmmIsBufferOutsideSmmValid and copy functions such as SmmCopyMemToSmram, which check that a source buffer "is valid per processor architecture and not overlap with SMRAM" and return EFI_SECURITY_VIOLATION if not. coreboot's SMM documentation says that "ring0 provided data (pointers, offsets, sizes, ...) must be checked before using them in SMM" and names two helpers, smm_region_overlaps_handler and smm_points_to_smram.

Nested pointers are a variant: the communication buffer itself is valid, but it contains another pointer that is not checked. WSMT has a separate protection flag for this case.

6. Race conditions and double fetches

SMM runs while other processors may still be running OS code, unless the handler pulls every processor into SMM first. That creates two kinds of race. The first is the flash race that CHIPSEC's bios_wp documentation describes: a gap between a write and the SMI that is supposed to veto it, closed by SMM_BWP. The second is a time of check to time of use race on communication buffers: a handler validates a length or pointer in the buffer, then reads it again later, after code on another processor has changed it. The defence is to copy the request into SMRAM once, validate the copy, and work only from the copy. EDK II's SmmCopyMemToSmram exists for that pattern, and EDK II's SMM CPU driver offers synchronisation modes that control how other processors are brought into SMM (PcdCpuSmmSyncMode).

7. Unlocked SMI configuration and lock bypasses

Several protections depend on SMIs firing. If the OS can turn off the global SMI enable or the TCO SMI, those protections stop working. CHIPSEC's bios_smi module checks that SMI configuration is locked. Locks themselves can have bugs, too. AMD's bulletin AMD-SB-7014, first published on 9 August 2024 and titled "SMM Lock Bypass", says that "it may be possible for an attacker with ring 0 access to modify the configuration of System Management Mode (SMM) even when SMM Lock is enabled", traced to improper validation in a model specific register. AMD's fix was platform initialization firmware, listed per processor family with target dates, which is a good illustration of how SMM fixes travel (more on that below). CHIPSEC's common.smm_close module references this bulletin, and fwupd's AMD SMM attribute reports a distinct "not-valid" result for it.

The right hand column is the uncomfortable part. Configuration bugs can be seen from the OS. Handler logic bugs cannot, because SMRAM is hidden by design. Microsoft says the same thing about WSMT: "it is not possible to produce a test which runs in Windows to verify that the protections prescribed in the WSMT specification are actually implemented in SMM."

What mitigations exist?

The Windows SMM Security Mitigations Table (WSMT)

The WSMT is "an ACPI table defined by Microsoft that allows system firmware to confirm to the operating system that certain security best practices have been implemented" in SMM. It was defined to support Windows Virtualization-based Security (VBS). Supported Windows versions "read the WSMT Protection Flags early during initialization, prior to hypervisor and VBS launch, and may elect to enable, disable, or de-feature certain security features based on the presence of these SMM Protections Flags." Microsoft lists support starting with Windows 10, version 1607 and Windows Server Technical Preview 2016.

The two protection flags that Microsoft's implementation notes discuss are:

• FIXED_COMM_BUFFERS: SMI handlers only use communication buffers in fixed, firmware allocated memory, and validate that every pointer stays inside allowed regions.
• COMM_BUFFER_NESTED_PTR_PROTECTION: the same validation applies to pointers found inside communication buffers.

The guidance is strict about honesty. "No Protection Flag should be set to 'true' until the OEM has confirmed that the mitigations corresponding to each Protection Flag value have been properly implemented." The table is a declaration by the firmware vendor, not a measurement.

System Guard SMM protection and the supervisor design

Microsoft's page on hardware based root of trust describes two SMM defences used with System Guard Secure Launch, which was "first introduced in Windows 10 version 1809":

• Paging protection, which locks certain code tables read only and prevents access to memory that has not been assigned.
• SMM hardware supervision and attestation, in which "a hardware-enforced processor feature known as a supervisor SMI handler can monitor the SMM and make sure it doesn't access any part of the address space that it isn't supposed to."

The same page says SMM protection "is built on top of the Secure Launch technology and requires it to function." Its Secure Launch requirements spell out what the SMM side must do: all SMM communication buffers must be in EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS or EfiReservedMemoryType memory; SMM page tables "Must NOT contain any mappings to EfiConventionalMemory", must not map code sections of runtime services code, must not allow write and execute on the same page, and "BIOS SMI handler must be implemented such that SMM page tables are locked on every SMM entry." The Intel variant adds that only TSEG pages can be marked executable.

The design idea behind supervisor approaches is to split SMM in two: a small, highly reviewed supervisor that owns the page tables and the CPU state, and the larger body of SMI handlers, which run with reduced privilege under it. A buggy handler then cannot rewrite its own page tables or read OS memory it was not granted. Processor and firmware vendors have published their own names for implementations of this idea; check your platform vendor's documentation for which one your firmware uses.

The SMI transfer monitor: dual monitor treatment

The SDM describes a separate, older approach for systems that run a hypervisor. Under the default treatment, firmware handles SMIs and then resumes the hypervisor. Under the "dual-monitor treatment", "Two VM monitors collaborate to control the servicing of SMIs": the normal hypervisor (the executive monitor) and a second monitor inside SMM, which the SDM calls the "SMM-transfer monitor (STM)". The STM runs SMI handlers as a guest, so the hypervisor's memory can be protected from them. The SDM adds that dual monitor treatment "may not be supported by all processors", and software must check the IA32_VMX_BASIC capability MSR. coreboot's documentation index lists Intel TXT and STM related material under its security section.

Hardening inside open source firmware

EDK II turns several of these ideas into build settings in UefiCpuPkg.dec:

The PcdCpuSmmRestrictedMemoryAccess description also notes that loosening the restriction "is only required by RAS components in X64 platforms", so server firmware with reliability features may have reasons to turn it off. That is worth asking a server vendor about.

coreboot keeps its SMM handler small and documents the pointer checking helpers above. Because coreboot's SMM code is open source, reviewers can read every handler a coreboot based board runs, which is impossible on closed firmware.

What NIST SP 800-193 says about firmware resiliency

NIST SP 800-193, Platform Firmware Resiliency Guidelines, was published in May 2018. Its abstract frames platform firmware security around three goals: "protecting the platform against unauthorized changes, detecting unauthorized changes that occur, and recovering from attacks rapidly and securely." It is addressed to OEMs and component suppliers, and also to administrators who "can use this document to guide procurement strategies".

SMM touches all three goals. Protection: on many platforms SMM is the mechanism that decides whether the firmware flash may be written, so SMM integrity is part of the protection boundary. Detection: if SMM is compromised, measurements and checks made by firmware at runtime can no longer be trusted, which is why designs move detection into hardware roots of trust and dynamic launch. Recovery: a platform that can restore known good firmware from a protected copy can recover from a corrupted flash even if the corruption came through SMM. When you buy hardware, 800-193 gives you the vocabulary to ask vendors which component enforces each of those three properties, and whether SMM is one of them.

How do open source tools check SMM configuration?

Two open source projects cover most of what you can verify from a running system: fwupd's Host Security ID (HSI) checks, which are designed to run safely on any Linux desktop, and CHIPSEC, which reads chipset and CPU registers directly and goes much deeper.

fwupd Host Security ID attributes

The HSI specification, written by fwupd and LVFS maintainers, defines levels from HSI:0 (insecure state) to HSI:5 (secure proven state, for which "There are currently no tests implemented"). It deliberately measures only what an end user can verify "without requiring any extra hardware to be connected, additional software to be installed, or disabling any existing security layers to measure." It also explains why it does not simply wrap CHIPSEC: "running a tool like Chipsec requires that you actively turn off some security layers such as UEFI Secure Boot, and allow 3rd party unsigned kernel modules to be loaded."

The attributes most relevant to SMM are:

The specification describes the AMD SMM attribute as covering three things: SMM_BASE is not saved to and restored from the save state area, "Code in the ASeg and TSeg range and the SMM registers are Read-only", and "SMI interrupts are not intercepted in SVM." Each failing attribute's stated resolution is the same: "Contact your OEM, who may be able to issue a firmware update."

CHIPSEC modules

CHIPSEC describes itself as "a framework for analyzing the security of PC platforms including hardware, system firmware (BIOS/UEFI), and platform components." It runs on Windows, Linux and the UEFI shell. Its README warns, "This software is for security testing purposes. Use at your own risk." The project has moved its default branch to chipsec2 for 12th generation Intel Core (ADL) and newer client platforms and 4th generation Xeon Scalable (SPR) and newer servers, with chipsec1 kept for older platforms and main deprecated. Pick the branch that matches the machine.

Some CHIPSEC modules accept options that try to write to protected regions to prove the protection works. On any machine you care about, run the default read only check and leave those options alone.

SMM on x86 compared with Arm and RISC-V

Every modern architecture has a firmware level above the operating system. They differ in how they are entered, how they are isolated and who updates them.

The difference that matters most for defenders is the entry path. On Arm and RISC-V, the OS enters firmware by executing an explicit call instruction with a defined calling convention. On x86, SMIs can also be raised by hardware events the OS did not request, and the interface between OS and SMM is a set of chipset registers and memory buffers that each platform defines. That is part of why x86 SMM has a longer history of configuration mistakes. Our posts on Trusted Firmware-A and OpenSBI and RISC-V boot cover those designs in depth.

Step by step: check SMM configuration with fwupdmgr and CHIPSEC

This walkthrough uses a Linux test machine you own. The fwupd part is safe on any machine. The CHIPSEC part loads a kernel driver that can read and write hardware registers, so do it on a dedicated test machine or a spare laptop, not on a production server or a machine holding data you care about. Nothing here changes firmware.

1. Record the platform and firmware version

You will need these to match advisories later.

sudo dmidecode -s system-manufacturer
sudo dmidecode -s system-product-name
sudo dmidecode -s bios-vendor
sudo dmidecode -s bios-version
sudo dmidecode -s bios-release-date
grep -m1 "model name" /proc/cpuinfo

2. Install fwupd and read the HSI report

fwupd ships in most Linux distributions.

# Debian and Ubuntu
sudo apt install fwupd
# Fedora
sudo dnf install fwupd

fwupdmgr --version
fwupdmgr security

fwupdmgr security prints the HSI level, such as HSI:2, followed by each attribute with a pass or fail marker. For SMM, look at the SPI lines on Intel machines (BIOS write enable, BIOS lock enable, SMM BIOS write protect, SPI descriptor) and the "SMM locked down" line on AMD machines.

3. Interpret the results

• All SPI and SMM attributes pass. The firmware set the locks that the OS can observe. This says nothing about SMI handler logic, which the OS cannot see.
• SMM BIOS write protect fails on Intel. The BIOS region may be writable from the OS through the race described earlier. Check for a newer firmware release before anything else.
• AMD SMM locked down reports not-valid. The HSI specification maps this to the 2024 SMM lock bypass bulletin. Check AMD-SB-7014 for your processor family and then your system maker's BIOS release notes for a version that includes the fixed platform initialization firmware.
• An attribute is missing. fwupd only runs checks it supports for your CPU. The org.fwupd.hsi.SupportedCpu attribute tells you whether the platform is supported at all.

4. Check for firmware updates through LVFS

fwupdmgr refresh
fwupdmgr get-devices
fwupdmgr get-updates

If your system maker publishes firmware on the LVFS, get-updates lists newer system firmware. If not, go to the maker's support site. Do not install firmware on a test machine during this exercise unless you mean to.

5. Prepare CHIPSEC on the test machine

CHIPSEC's own WARNING.txt opens with "Chipsec should only be used on test systems!" Its reasons: the kernel driver gives user mode programs direct access to hardware such as physical memory, the driver is distributed as source and has to be loaded on systems that would otherwise demand signed drivers, and a module that touches hardware incorrectly can hang or crash the OS. The HSI specification adds that this usually means turning off UEFI Secure Boot. The prerequisites below follow CHIPSEC's Linux installation guide, which also notes that the PyPI package is outdated, so build from source and pick the branch that matches the hardware.

sudo apt-get install build-essential python3-dev python3 python3-venv gcc git nasm linux-headers-$(uname -r)
git clone https://github.com/chipsec/chipsec.git
cd chipsec
git checkout chipsec2      # or chipsec1 for pre ADL client and pre SPR server platforms
python3 -m venv .venv && . .venv/bin/activate
pip install -r linux_requirements.txt
python3 setup.py build_ext -i

6. Run the SMM modules

Run each module on its own so the output is easy to read.

sudo .venv/bin/python3 chipsec_main.py -m common.smm
sudo .venv/bin/python3 chipsec_main.py -m common.smrr
sudo .venv/bin/python3 chipsec_main.py -m smm_dma
sudo .venv/bin/python3 chipsec_main.py -m common.smm_code_chk
sudo .venv/bin/python3 chipsec_main.py -m common.bios_wp
sudo .venv/bin/python3 chipsec_main.py -m common.bios_smi
sudo .venv/bin/python3 chipsec_main.py -m common.spi_lock

On AMD test machines, add the AMD specific modules:

sudo .venv/bin/python3 chipsec_main.py -m common.smm_addr
sudo .venv/bin/python3 chipsec_main.py -m common.smm_lock
sudo .venv/bin/python3 chipsec_main.py -m common.smm_close

7. Read CHIPSEC's verdicts

Each module ends with a result such as PASSED, FAILED, WARNING or NOT APPLICABLE. A module that does not apply to the platform (for example common.smm on a platform without SMRAMC defined) is not a failure. Treat a FAILED result on common.smm, common.smrr, smm_dma, common.bios_wp or common.bios_smi as a firmware configuration finding for the system maker, with the module output attached. Treat common.smm_code_chk failing on a platform where the feature is available as a hardening gap rather than an open door, since it is defence in depth against callouts.

8. Put the machine back

Unload the CHIPSEC driver or reboot, turn UEFI Secure Boot back on in firmware setup, and confirm with mokutil --sb-state that it reports SecureBoot enabled. Then run fwupdmgr security again so you have a clean HSI baseline for the machine.

Why do SMM fixes come from the board vendor, and how do you track them?

SMM code is part of the system firmware image in the SPI flash. Unlike CPU microcode, which an OS can load at boot, SMM handlers cannot be patched by the OS, because they are loaded into SMRAM by firmware during boot and SMRAM is locked before the OS starts. A fix therefore means a new firmware image, signed by whoever controls the platform's firmware update key, which is the system or board maker.

The chain usually has three links:

1. The silicon vendor ships reference code: platform initialization firmware, SMM drivers for its chipsets, and security fixes. AMD's AMD-SB-7014 shows what that looks like: a table of processor families, each with a fixed platform initialization firmware version and a date.
2. The firmware supplier or the system maker's firmware team integrates that reference code with EDK II or coreboot and the board specific SMI handlers.
3. The system or board maker builds, signs, tests and publishes the BIOS update for each model, and decides how long each model receives updates.

Each link adds time. A bulletin from a CPU vendor is the start of the process for your laptop, not the end. Practical tracking looks like this:

• Keep an inventory of make, model, BIOS version and release date for every machine, using dmidecode or your management tooling. Without it you cannot answer "which of our machines still run the old firmware?"
• Subscribe to your system makers' security advisories, plus the CPU vendors' product security bulletins.
• Use the LVFS through fwupd where the maker supports it, so Linux machines can see and apply capsule updates. The HSI attribute org.fwupd.hsi.Bios.CapsuleUpdates tells you whether capsule updates are enabled in firmware setup.
• After updating, confirm the BIOS version and rerun fwupdmgr security. A firmware update that resets settings can also change lock behaviour.
• When a model reaches end of support, plan to replace it. Firmware support usually ends long before the hardware wears out.
• For EDK II based firmware you build yourself, watch the TianoCore EDK II security advisories on GitHub and rebase when they touch UefiCpuPkg, MdeModulePkg SMM drivers or StandaloneMmPkg.

Common mistakes

• Treating a passing HSI report as proof SMM is safe. HSI and CHIPSEC check configuration. Neither can read SMI handler code, and Microsoft says the same about WSMT.
• Reading WSMT flags as a test result. The flags are the firmware vendor's self declaration. They tell Windows what to expect; they do not prove anything.
• Running CHIPSEC on a production machine. It loads a driver that can write hardware registers and usually needs Secure Boot off. Use a test unit of the same model.
• Using the wrong CHIPSEC branch. After the branch change, chipsec2 targets newer platforms and chipsec1 older ones. Running the wrong one can produce misleading results.
• Assuming the OS update fixed it. Windows and Linux updates can enable features that depend on SMM hardening, but they cannot replace SMI handlers. Only a firmware update can.
• Stopping at the CPU vendor bulletin. Check that your system maker has released a BIOS that includes the fixed reference code, and that it is installed.
• Leaving validation features on in production builds. EDK II says PcdCpuSmmProfileEnable is for validation and should be FALSE in production; it also conflicts with restricted memory access on X64.
• Writing a new SMI handler that reads the communication buffer twice. Copy into SMRAM, validate, then use the copy.
• Validating only that a pointer is outside SMRAM. Microsoft's guidance requires validating that pointers are inside allowed regions, not merely outside SMM.

FAQ

What is System Management Mode in simple terms?

It is a hidden x86 processor mode that only platform firmware uses. A System Management Interrupt pauses the operating system, the firmware's handler runs from protected memory called SMRAM, and the processor returns to the OS with the RSM instruction.

Why is SMM called ring minus 2?

It is an informal nickname. Ring 0 is the kernel and the hypervisor is often called ring minus 1. SMM can reach all of memory, runs regardless of the OS, and is invisible to both, so people place it below them. Intel's manual does not use negative ring numbers.

What triggers a System Management Interrupt?

The SMI# signal or an SMI message over the APIC. Platform hardware raises them for events such as power buttons, sleep transitions, timers, trapped I/O accesses, writes to a software SMI port and attempts to enable BIOS flash writes when BIOS Lock Enable is set.

What is SMRAM and where is it?

SMRAM is the memory that holds SMM code, data and saved processor state. Architecturally it starts at SMBASE, with the handler entry at SMBASE plus 8000H. On PCs most of it lives in TSEG, a reserved region at the top of memory below 4 GB, with a small legacy window in low memory.

What is SMRR?

System Management Range Registers are a pair of CPU MSRs, IA32_SMRR_PHYSBASE and IA32_SMRR_PHYSMASK, that firmware sets from inside SMM. Outside SMM, writes to the range are ignored and reads return a fixed value, which also blocks cache based tricks.

What is the Windows SMM Security Mitigations Table?

WSMT is an ACPI table defined by Microsoft in which firmware declares that its SMI handlers follow specific practices, such as using fixed communication buffers and validating nested pointers. Windows reads it before starting the hypervisor and VBS features.

How do I check if SMM is locked on Linux?

Run fwupdmgr security and read the SPI attributes on Intel machines and the "SMM locked down" attribute on AMD machines. For deeper checks, use CHIPSEC modules such as common.smm, common.smrr and smm_dma on a test machine.

Can a Windows or Linux update fix an SMM vulnerability?

No. SMI handlers are part of the system firmware and are locked into SMRAM before the OS starts. The fix is a BIOS or UEFI update from your system or board maker, which may be delivered through Windows Update, the LVFS or the maker's support site.

Does Arm or RISC-V have System Management Mode?

Not by that name. Arm has the secure world and the EL3 secure monitor, usually Trusted Firmware-A, and RISC-V has machine mode, usually running OpenSBI. Both play a similar role, but the OS enters them with explicit call instructions rather than hardware SMIs.

Where Safeguard fits

Safeguard does not inspect firmware binaries, read SMRAM, check SMM lock bits, scan firmware or manage devices. The fit here is indirect and sits around the firmware rather than in it. Firmware is built like any other software: EDK II and coreboot trees vendor open source libraries, their build hosts run Python tooling, compilers and OpenSSL linked signing utilities, and teams increasingly build firmware inside container images. Safeguard can scan those repositories, build containers and SBOM files for known vulnerable components, show which projects contain a given component and version, and evaluate policies and gates in CI, so the pipeline that produces and signs a firmware image is held to the same standard as application code. The SMI handlers themselves still have to be fixed by whoever ships the platform firmware.

SMM fixes arrive on the firmware vendor's schedule, but the software around firmware does not have to wait: a rebuilt test machine pulls fresh packages for fwupd, CHIPSEC and Python, and firmware build pipelines carry open source libraries, compilers and container images of their own. Those are dependencies you control, and the steps below apply to them, not to the SMI handlers in your system's flash.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session in a repository: it reads a vulnerability finding, asks before each command, edits the dependency, runs the install and tests with your approval and pushes nothing. The same flow applies to the tooling repository behind a firmware build, for example the Python helpers that wrap an EDK II build or sign a capsule. It does not touch the firmware on a machine.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and runs a scan from the terminal. A firmware team can use the same flow to scan a build container or a vendored source tree on a workstation that never uploads the source elsewhere.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. An engineer can then ask about the dependencies in a firmware build repository from the assistant they already use, with only the access they grant.

Click through it at your own pace, or open it full screen.

Download the apps at https://safeguard.sh/download and read the CLI documentation at https://docs.safeguard.sh/docs/cli .

Quick check

Sources

• Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 3 (325384-093US, September 2026)
• Intel SDM landing page
• Microsoft Learn: Windows SMM Security Mitigation Table
• Microsoft Learn: How a hardware based root of trust helps protect Windows (System Guard)
• NIST SP 800-193, Platform Firmware Resiliency Guidelines
• coreboot documentation: x86 System Management Mode
• coreboot documentation: Security
• TianoCore EDK II: UefiCpuPkg.dec
• TianoCore EDK II: PiSmmCpuDxeSmm.inf
• TianoCore EDK II: SmmMemLib.h
• TianoCore EDK II: PiSmmCommunicationRegionTable.h
• TianoCore EDK II: VariableSmm.inf
• TianoCore EDK II: LockBoxLib.h
• TianoCore EDK II: StandaloneMmPkg.dec
• TianoCore EDK II security advisories
• CHIPSEC README (chipsec2 branch)
• CHIPSEC branch migration guide (main branch README)
• CHIPSEC Linux installation guide
• CHIPSEC WARNING.txt
• CHIPSEC module common.smm
• CHIPSEC module common.smrr
• CHIPSEC module smm_dma
• CHIPSEC module common.smm_code_chk
• CHIPSEC module common.bios_wp
• CHIPSEC module common.bios_smi
• CHIPSEC module common.spi_lock
• CHIPSEC modules common.smm_addr, smm_lock and smm_close
• CHIPSEC releases
• fwupd Host Security ID Specification
• fwupdmgr documentation
• AMD product security bulletin AMD-SB-7014, SMM Lock Bypass
• Trusted Firmware-A firmware design
• RISC-V ratified specifications
• OpenSBI README
• OpenSBI domain support (PMP)

Last reviewed: 24 October 2026. Register names, CHIPSEC module names and HSI attributes change between platform generations and releases; check the documentation for your exact processor, firmware and tool version.