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 that 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 the 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 that 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 afterward. It also writes the address of the Secure Loader Block into 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 that 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 afteRead More – Source
