Microsoft on Tuesday announced a new hardware security initiative, dubbed Secured-core PC. The short version of what “Secured-core PC” really means is a defense against attacks at the firmware layer.
Although actual firmware-based attacks have been relatively uncommon in the field so far, they represent a particularly nasty avenue of exploitation for an advanced, persistent attacker.
Once a machine’s firmware is compromised, the exploit is persistent across reboots, operating-system re-installations, and even full hard drive replacement.
As operating systems themselves become more secure and difficult to compromise and keep compromised, the value of pivoting from a shell to the firmware layer in order to enhance persistence also increases. Even detection of compromised firmware is problematic, since Windows Defender and other antivirus applications run at the operating-system level and don’t necessarily have direct access to the firmware.
From Secure Boot to System Guard Secure Launch
Beginning with Windows 8, Microsoft leveraged UEFI core capabilities to ensure that only trusted operating-system bootloaders could launch. Secure Boot verifies that the initial bootloader is signed with a key that’s trusted by the firmware. This prevents the use of “rootkits,” or malicious software which loads before the operating system itself. By loading before the operating system itself, a rootkit could ensure that it had the absolute highest level of system privilege, thus hiding it from detection efforts from within the operating system.
Secure Boot largely solved the rootkit problem, but since it runs on the already-trusted firmware itself, it can’t help with compromises to that firmware. That’s where System Guard Secure Launch comes in. SSGL allows the system to launch initially on untrusted code, but then it takes control of all CPUs and, Microsoft says, “forces them down a well-known and measured code path.”
Unpacking the “well-known and measured code path” requires some deeper knowledge of the particular platform System Guard Secure Launch is being run on. Fortunately, AMD provided a pretty deep technical explainer for it. We also reached out to Intel, but its promotional material was vague and not much help on a technical level, so the rest of our coverage will focus on AMD’s implementation of SSGL.
SKINIT and the Dynamic Root of Trust Measurement
In AMD CPUs, an instruction called SKINIT—a homophonous abbreviation of “secure init”—reinitializes the processor. This is sort of like hitting a “reset” button; it makes certain that system state is effectively blanked out prior to the execution of the AMD Secure Loader. This instruction only accepts one parameter, which is the address of a 64KB block of RAM which contains the Secure Loader. SKINIT then marks the 64KB block of RAM containing the Secure Loader as the Secure Loader Block, which cannot be tampered with afterwards. It also writes the address of the Secure Loader Block into the the Trusted Platform Module (TPM) itself.
The Secure Loader then measures and authenticates the firmware and bootloader itself and gathers information such as physical memory map, APIC and IOMMU configuration, and more for future verification by the OS. It then validates, initializes, and transitions control to the Security Kernel, which is trusted code which controls access to system resources at the operating-system level.
The short version is this—UEFI Secure Boot prevents a bootloader from running if it wasn’t signed with a trusted key; System Guard Secure Launch also prevents a compromised bootloader—or any later-executed code at the operating system level—from “cleaning up after itself.” Since it’s kept immutable in RAM at the device level and its address is readable from the TPM itself, the operating system can inspect the bootloader—and key system parameters which otherwise might be used to “hide” memory or functions from it—with assurance of validity later.
SKINIT is an AMD specific term and instruction, but as Intel has also published its adherence to Microsoft’s new System Secure Guard Launch and Secured-core PC initiative, we can assume its CPUs offer a very similar instruction to perform largely the same tasks.
System Management Mode
The remaining attack surface that must be protected is System Management Mode. SMM is a special x86 CPU mode that handles low-level tasks including power management, hardware configuration, and thermal monitoring. When one of these system operations is requested, an SMI interrupt calls and executes SMM code installed by the BIOS. This code executes in the highest privilege level, which makes it invisible to the operating system and grants it access across hypervisor memory barriers.
SMI handlers are generally provided by the motherboard manufacturer, not the operating-system manufacturer or CPU manufacturer. Since a handler runs at the very highest privilege level, it’s an attractive target for attackers. To minimize the value of this attack surface, AMD uses a special security module called the SMM Supervisor. The SMM Supervisor executes immediately after the SMI interrupt, before control is transferred to SMM code itself, and prevents the SMM from doing things it has no business doing—like modifying hypervisor or OS memory (apart from a small coordinate communication buffer), introducing new SMM code at runtime, or accessing any DMA, I/O, or registers which might compromise the hypervisor or operating system.
Finding a Secured-core PC
A short-so-far list of Secured-core laptops including entries from Lenovo, Panasonic, Dell, HP, and Microsoft itself can be found at Microsoft’s Secured-core partner page here.