{"id":38148,"date":"2020-11-12T17:00:33","date_gmt":"2020-11-12T17:00:33","guid":{"rendered":"https:\/\/www.microsoft.com\/security\/blog\/?p=92175"},"modified":"2020-11-12T17:00:33","modified_gmt":"2020-11-12T17:00:33","slug":"system-management-mode-deep-dive-how-smm-isolation-hardens-the-platform","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/system-management-mode-deep-dive-how-smm-isolation-hardens-the-platform\/","title":{"rendered":"System Management Mode deep dive: How SMM isolation hardens the platform"},"content":{"rendered":"

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.<\/p>\n

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<\/a>, 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.<\/p>\n

Sometimes referred to as \u201cRing -2\u201d, 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.<\/p>\n

To stop sophisticated attacks from taking control of the system through SMM, the OS must have enforcement or oversight of SMM\u2019s 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.<\/p>\n

SMM isolation<\/h2>\n

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.<\/p>\n

\"Diagram<\/p>\n

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\u2019 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.<\/p>\n

Trusted Computing Base (Tcb) Launch, introduced in the Windows implementation of Dynamic Root of Trust (DRTM), gets the enforced policy from the chip vendor\u2019s reporting mechanism. Because resource access is specific to a platform\u2019s needs, Tcb Launch compares the OEM\u2019s 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\u2019s policy is measured for attestation and is reported to the OS.<\/p>\n

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:<\/p>\n

    \n
  1. SMM page configuration lockdown<\/li>\n
  2. Static page tables<\/li>\n
  3. Model-Specific Register (MSR) access<\/li>\n
  4. IO port access<\/li>\n
  5. Processor state save access<\/li>\n<\/ol>\n

    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.<\/p>\n

    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.<\/p>\n

    \"Diagram<\/p>\n

    AMD solution (SMM Supervisor)<\/h2>\n

    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.)<\/p>\n

    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.<\/p>\n

    SMM Supervisor marks critical pages\u2014including SMM Supervisor code block, internal data, the page table itself, exception handler, as well as processor save state\u2014as supervisor pages, accessible only  from current privilege level 0 (CPL0, the most privileged level).<\/p>\n

    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 \u201chlt\u201d and \u201ccli\u201d all end up as General Protection Fault enforced by CPU hardware.<\/p>\n

    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.<\/p>\n

    Intel Hardware Shield<\/h2>\n

    Intel\u00ae Hardware Shield, a part of the Intel vPro\u00ae platform, uses CPU hardware and firmware to enforce the platform\u2019s 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*<\/sup>.<\/p>\n