EFI Pre-EFI Initialization Core Interface Specification v0.91.EFI Firmware File System Specification v0.9.EFI Driver Execution Environment Core Interface Spec v0.91.EFI S3 Resume Boot Path Specification v0.9.The most relevant EFI documents for this post are: Recent OS X versions are 64-bit only so this feature is not used anymore. It was followed by the UEFI (Unified Extensible Firmware Interface) managed by the Unified EFI Forum ( Apple forked from EFI v1.10 (Dec 2002) and introduced some changes, for example support for fat EFI binaries (support for both 32-bit and 64-bit systems). 1 – Relevant documentationĮFI (Extensible Firmware Interface) specification was published by Intel. The script is stored in physical memory and this is the main reason why the Dark Jedi attack described at CCC 2014 is possible. It is on the DXE phase that the boot script is created on normal boot path, meaning that the script is created once on a normal boot. The DXE phase is where most of the initialization work is performed (there are some 150 DXE drivers in EFI firmware), so this is the main reason why the boot script is important for a fast resume from sleep cycle (EFI documents from 2003 describe that Microsoft requires a maximum of 0.5 seconds for the S3 resume). The following picture from the EFI documentation describes the differences between the normal and S3 boot phases.Ī description of each phase – SEC (Security), PEI (Pre-EFI Initialization), DXE (Driver Execution Environment), BDS (Boot Device Selection) – can be found here. Sample contents of a boot script will be shown later. Script execution will be faster than restarting and reinitializing all the necessary drivers, as it happens in a regular boot path. Instead of reinitializing everything again, the boot script will restore the machine to the same configuration without executing again the whole DXE phase, which is time consuming. Other specific operations or routines that are necessary to restore the chipset and processor configu‐ ration.It can contain the following chipset and processor information: The key difference is a performance optimization materialized in a boot script. In practice, this means that the resume path is a special boot path that differs from the normal boot path. If it took the same time as a normal boot, there would be no advantages in using it (battery power consumption for example). It is mostly used in notebook computers (closed lid) and its performance is important since users expect their computer to wake up from sleep in a short period of time. On this mode there is still power usage but it’s vastly reduced. One of those is the S3 state, which is a power saving feature that suspends to memory, meaning that the current operating system state is held in memory. The ACPI (Advanced Configuration and Power Interface) specification defines a few system power states and transitions. I am also going to show you how to build a temporary fix. Now let’s jump to the technical part and understand why the bug occurs.
All machines based on Haswell or newer platforms are not vulnerable. This includes the newest Mac Pro since its Xeon E5 CPU is still based on Ivy Bridge platform. This also allows finding which Mac models are vulnerable to this bug.Īll machines based on Ivy Bridge, Sandy Bridge (and maybe older) platforms are vulnerable. The necessary information is not saved, so the locks will not be restored when the machine wakes up from sleep. The initial assumptions pointing to some kind of S3 boot script failure were correct.Īpparently, Apple did not follow Intel’s recommendation and failed to lock the flash protections (and also SMRR registers) after the S3 suspend cycle. The bug is definitely not related to a hardware failure and can be fixed with a (simple) firmware update. So the main question after the media storm was if my assumption was wrong or not and what was really happening inside Apple’s EFI. One of the reasons for its full disclosure was the assumption that Apple knew about this problem since newer machines were not vulnerable. At the time, I did not research the source of the bug due to other higher priority tasks. For example, Gigabyte ships their UEFI with the flash always unlocked and other vendors also suffer from all kinds of firmware vulnerabilities.Īs I wrote in the original post, I found the vulnerability a couple of months ago while researching different ways to reset a Mac firmware password. It must be noticed that firmware issues are not Apple exclusive. While (I believe) its real world impact is small, it is nonetheless a critical vulnerability. The suspend/resume vulnerability disclosed a few weeks ago (named Prince Harming by Katie Moussouris) turned out to be a zero day.
0 kommentar(er)
