02. eSPI SAF

Enhanced Serial Peripheral Interface (eSPI) is a relatively new interface in the Intel world. It is meant to supersede the traditional Low-Pin-Count (LPC) interface. Known in the Intel world as a Embedded Controller (EC), the Apple T2 can control many aspects of the platform over a single unified bus.

Source: https://www.intel.com/content/dam/support/us/en/documents/software/chipset-software/327432-004_espi_base_specification_rev1.0_cb.pdf

This broad range of control extends to the system's firmware and changes the way that Unified Extensible Firmware Interface (UEFI) support is implemented. One of the traditional challenges in UEFI is how to perform firmware validation when you can’t trust the integrity of the firmware validation routine itself.

One of the newer eSPI extensions, Slave Attached Flash (SAF), replaces the traditional firmware-containing SPI flash chip with a wrapped interface that the Embedded Controller can implement to provide the firmware dynamically. SAF is typically only found on server SKUs, but both the iMac Pro and 2018 Macbook Pro lines contain this functionality. This allows the T2 to perform additional firmware validation in a trusted execution environment before supplying it to the chipset for execution.

Source: https://downloadmirror.intel.com/27055/eng/329957-001_eSPI_Spec_Server_Addendum_Rev0_7.pdf

As security researchers, seeing Apple leverage this functionality does raise several questions. First, does utilizing SAF from an EC actually improve platform security and make bootkits harder to deploy? Unequivocally, yes. Even if an attacker were able to bypass firmware write protection mechanisms offered by the X86 platform, without a durable storage medium such as a traditional SPI flash chip for the malware to reside in, bootkits should not be able to survive a full reboot.

Second, does this approach realize the vision of fully trusted boot? Not yet. The eSPI SAF protocol that wraps the firmware page requests has no means of authenticating the responses it receives. This means that, with implanted hardware, it is still possible to effectively man-in-the-middle the firmware image in flight and modify it.

Finally, does the T2 present additional risk to platform integrity? You betcha. The T2 is in a class along with other PCIe-connected, DMA-capable processors. While user-space code on the T2 is not intrinsically or architecturally capable of altering the behavior of System Management Mode (SMM), the Intel Management Engine (ME), or UEFI, by virtue of being the code responsible for bootstrapping them, the kernel on the T2 is intrinsically more powerful than SMM/ME/UEFI. While it is based on an immense but mature code base and years of adversarial testing, the T2 exposes new interfaces to the host OS that have traditionally been out of reach for attackers. The most prominent of these interfaces is the RemoteXPC facility exposed by a USB-attached network interface. While direct access to the interface is gated by entitlements, advertised services can be communicated with directly without root permissions or binary entitlements. The iMac Pro firmware hinted to the T2 eventually supporting the installation of apps, but it appears to be a simple artifact of the platform porting process. The consequences of persistent privileged code execution on the T2 are serious and, in addition, are likely forensically impossible to detect. This makes the T2 an extremely appealing target for a motivated attacker.