You know Ring 0 (kernel) and Ring 3 (user). But x86 has a hidden mode more privileged than the kernel itself: System Management Mode, often called "Ring -2." It's invoked by a System Management Interrupt (SMI), and while it runs, your OS is frozen — every core stops, control transfers to firmware code stashed in a locked memory region called SMRAM, and the kernel has no way to observe it happened except by noticing time moved forward.

SMM was added in the 386SL for power management. Today it's used by firmware for: thermal throttling responses, ECC error handling, TPM interactions, USB legacy keyboard emulation (yes, this is why some servers get SMIs on every keystroke), fan control on cheap boards, and — infamously — vendor RAS features and undocumented telemetry.

The mechanics: SMIs are triggered by a dedicated pin (SMI#), by writes to specific chipset registers, or by ACPI events. On SMI, the CPU saves its entire architectural state into SMRAM (at SMBASE + 0xFE00), switches to a special 16-bit-ish mode with flat 32-bit addressing, and jumps to SMBASE + 0x8000. The handler runs, executes RSM (Resume from SMM), and state is restored. SMRAM is protected by the chipset — even Ring 0 cannot read it once the D_LCK bit is set at boot.

Why you care as a low-latency engineer: SMIs cause invisible latency spikes. A 500 μs SMI in the middle of your 100 μs critical section is undebugabble with normal tools — perf can't see it, ftrace can't see it, but your p99.99 latency will suddenly show it.

How to detect them: On Intel, MSR 0x34 (MSR_SMI_COUNT) increments on every SMI. Read it before and after your workload:

• rdmsr -p 0 0x34 (from the msr-tools package)
• Or use turbostat --show SMI which prints SMI counts per core per interval.

Real-world example: HFT and telecom engineers routinely disable USB legacy support in BIOS specifically because the USB emulation SMI handler polls every ~1 ms and takes 20–100 μs each. On a "quiet" tuned system with nohz_full and pinned threads, that USB SMI becomes the single largest source of jitter. Facebook's engineers publicly complained about this in 2018; Intel's own tuning guide for low-latency workloads lists "disable USB legacy, disable processor C-states in BIOS, disable Turbo, and audit MSR 0x34" as step one.

Rule of thumb: If MSR_SMI_COUNT increases by more than ~1 per second per core on an idle machine, your firmware is chatty and no amount of kernel tuning will get you below a few hundred microseconds of jitter. Fix the BIOS first.