Ensuring that the platform firmware is healthy and trustworthy is fundamental to guaranteeing that powerful platform security features like Hypervisor-protected code integrity (HVCI) and Windows Defender Credential Guard are functioning as expected. Windows 10 achieves this by leveraging a hardware-based root of trust that ensures unauthorized code like Unified Extensible Firmware Interface (UEFI) malware cannot take root before the Windows bootloader launches.
Key to defending the hypervisor, and by extension the rest of the OS, from such low-level threats is protecting System Management Mode (SMM), an execution mode in x86-based processors that runs at a higher effective privilege than the hypervisor. Because of its traditionally unfettered access to memory and device resources, SMM is a known vector of attack for gaining access to the OS and hardware. SMM is particularly vulnerable to threats like confused deputy attacks, in which malicious code tricks another code with higher privileges to perform certain activities. One could have perfect code in SMM and still be affected by behavior like trampolining into secure kernel code.
Sometimes referred to as “Ring -2”, SMM is used by OEMs to interact with hardware like NV RAM, emulate hardware functionality, handle hardware interrupts or errata, and perform other functions. SMM runs in the form of interrupt handlers that are triggered by timers or access to certain memory, registers, or hardware resources. OEM drivers and runtime firmware services may explicitly trap SMM to control certain hardware functionality.
To stop sophisticated attacks from taking control of the system through SMM, the OS must have enforcement or oversight of SMM’s behavior. As part of Secured-core PCs and System Guard, Intel and AMD have developed mechanisms to isolate SMM from the OS by enforcing and reporting what resources SMM has access to.
Isolating SMM is implemented in three parts: OEMs implement a policy that states what they require access to; the chip vendor enforces this policy on SMIs; and the chip vendor reports compliance to this policy to the OS.
The policy provided by the OEM is a list detailing the resources that the SMI handlers require access to. This policy is validated and enforced by the chipset vendors’ specific enforcement mechanism detailed later. The OS does not have any control over what the policy is; it is only guaranteed enforcement of the policy stated.
Trusted Computing Base (Tcb) Launch, introduced in the Windows implementation of Dynamic Root of Trust (DRTM), gets the enforced policy from the chip vendor’s reporting mechanism. Because resource access is specific to a platform’s needs, Tcb Launch compares the OEM’s SMM access policy with several levels of Windows SMM isolation requirements to determine the level of isolation provided. The isolation level achieved by the OEM’s policy is measured for attestation and is reported to the OS.
The isolation levels consist of increasing restrictions on what SMIs may access, as well as enforcement capabilities required on the system. An example of an isolation requirement is that SMIs may not access memory owned by the OS. Additionally, these requirements can include restrictions on the following resources:
In order to ensure a consistent security promise for customers using Secured-core PCs if the minimum requirements are not met, the DRTM measurements are capped, and local and remote attestation fail. SMM isolation is tied with DRTM because without DRTM, the OS cannot trust anything evaluated by the boot environment as it is not protected from the influence of SMM. SMIs are suspended during DRTM, so the new root of trust established by DRTM can evaluate the security of the SMM access policy.
Not only are these protections utilized by Windows for local secrets protection, but remote attestation tools can also leverage this information to determine the security posture of a specific device. This attestation report can be used to prevent access to sensitive network files, for example, unless a certain combination of features is present.
During UEFI boot phase, the SMM Supervisor is loaded as a UEFI driver. This driver is signed by AMD and authenticated by the Platform Security Processor (PSP) at the time of DRTM launch. Failure of authentication will fail DRTM. (It is also under firmware anti-rollback protection by PSP.)
SMM Supervisor provides and initializes the SMI entry routine (the first code block executed after SMI is triggered). This routine is also signed by AMD and authenticated by PSP at the time of DRTM launch. Upon DRTM event, PSP also verifies that the SMI entry is properly configured to this authenticated block. Failure of this authentication will also result in DRTM failure.
SMM Supervisor marks critical pages—including SMM Supervisor code block, internal data, the page table itself, exception handler, as well as processor save state—as supervisor pages, accessible only from current privilege level 0 (CPL0, the most privileged level).
Immediately after SMI is triggered, the SMI entry routine demotes the system to execute under CPL3 (least privileged level) before executing any third party SMI handlers. From CPL3 environment, MSR, IO, and supervisor pages access, critical register changes such as CR3, as well as privileged instructions such as “hlt” and “cli” all end up as General Protection Fault enforced by CPU hardware.
In order for SMI handlers under CPL3 to access privileged data and register, SMM Supervisor provides syscall interface to allow third-party SMI handlers to make such requests. The backend of the syscall interface, which resides in SMM supervisor, is controlled by SMM secure policy. The said policy is a deny list that can be customized per platform to determine which MSRs, IOs, or memory regions can be accessed from CPL3. SMM secure policy is reported to and verified by OS secure loader during DRTM event.
Intel® Hardware Shield, a part of the Intel vPro® platform, uses CPU hardware and firmware to enforce the platform’s SMM access policy. Generationally, these capabilities evolve using new CPU hardware features in conjunction with existing CPU capabilities to strengthen related micro-architectural flows and provide new register locks in support of related firmware hardening*.
*No product or component can be absolutely secure.
Enabling SMM protection and System Guard Secure Launch may be achieved when the following support is present:
Further configuration information and requirements can be found here.On Secured-core PCs, virtualization-based security is supported, and hardware-backed security features like System Guard Secure Launch with SMM Protections are enabled by default. Customers do not need to worry about configuring the necessary functionality as Secured-core PCs come with the right configurations from OEMs, thereby providing the simplest path to the most secure Windows 10 systems. Learn more about the line of Secured-core PCs available today.
For important security features on Windows to properly do their jobs, the platform’s firmware and hardware must be trustworthy and healthy. Learn about Secure Launch, which leverages the principle of Dynamic Root of Trust for Measurement (DRTM), and System Management Mode (SMM) protection.
Secured-core PCs provide customers with Windows 10 systems that come configured from OEMs with a set of hardware, firmware, and OS features enabled by default, mitigating Thunderspy and any similar attacks that rely on malicious DMA.
Secured-core PCs combine virtualization, operating system, and hardware and firmware protection. Along with Microsoft Defender ATP, Secured-core PCs provide end-to-end protection against advanced attacks that leverage driver vulnerabilities to gain kernel privileges.
Kerberoasting, a well-known Active Directory (AD) attack vector, enables threat actors to steal credentials and navigate through devices and networks. Microsoft is sharing recommended actions administrators can take now to help prevent successful Kerberoasting cyberattacks.
