EDK II (SMM environment, Machine Check Exception handling): Machine Check Exceptions are enabled before SMM installs

Impact

Machine Check Exceptions are enabled before SMM installs a handler for them, so an MCE fired in that window is delivered to whatever the IDT happens to point at - which an attacker can arrange. That is arbitrary code execution at ring -2. SMM sits below the hypervisor and below the OS: an implant there survives OS reinstall and node reimaging, can forge or suppress the measurements that feed remote attestation, and is invisible to every agent a tenant or operator runs. On multi-tenant GPU hardware it is the difference between wiping a node between customers and believing you wiped it.

Who can reach it

Local attacker with sufficient privilege on the host OS to trigger a machine check at the right moment - realistically root/admin on the node, or a tenant with kernel-level access on bare metal.

What to do

Firmware flash from the server OEM. This is a core edk2 fix published August 2025, so the IBV rebase into AMI/Insyde/Phoenix trees and then into OEM BIOS payloads is the long pole - budget one to two OEM BIOS release cycles and track it per platform generation. One reboot per node, drain first. No configuration workaround: SMM is always present and cannot be disabled. Compensating control is to not hand kernel-level access on shared bare metal to untrusted tenants without a full firmware re-flash between leases.

References