System Management Mode deep dive: How SMM isolation hardens the platform

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.

SMM isolation

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:

1. SMM page configuration lockdown
2. Static page tables
3. Model-Specific Register (MSR) access
4. IO port access
5. Processor state save access

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.

AMD solution (SMM Supervisor)

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

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^*.

• Intel vPro® platform with 8^th Generation Intel® Core™ vPro® processors introduced firmware hardening and hardware-locked static page table support to reduce SMM privilege with regard to memory and to lock the memory configuration. These new locks include: CR3 lock, MSEG lock, SMBASE lock, etc.
• Intel vPro platform with 9^th Generation Intel Core vPro processors added an Intel signed SMM module enables attestation of the SMM memory configuration using Intel® Trusted Execution Technology (Intel® TXT), a component of Intel® Hardware Shield, via PCR17. The module first verifies the integrity of the hardened SMM code used to enforce the SMM access policy. It then reports this, as well as the details of the policy, back to the OS. Therefore, the OS can verify the trustworthiness of SMM and evaluate the platform’s SMM access policy without the possibility of interference from SMI handlers.
• Intel vPro platform with 10^th Generation Intel Core vPro processors enhanced the verified CPL0 SMM components to create a privilege separation with SMI handlers in order to extend policy enforcement to MSRs, IO ports, and SMM state save (access policy may vary by platform). The reporting mechanism was extended to include these capabilities as well.

*No product or component can be absolutely secure.

Secured-core PCs give the simplest experience for customers to get Secure Launch and SMM protection

Enabling SMM protection and System Guard Secure Launch may be achieved when the following support is present:

• Intel, AMD, or ARM virtualization extensions
• Trusted Platform Module (TPM) 2.0
• On Intel: TXT support in the BIOS
• On AMD: SKINIT package must be integrated in the Windows system image
• On Qualcomm: Implements DRTM TrustZone application and supports SMC memory protections.
• Kernel DMA Protection (learn more)

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.

READ MORE HERE