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.
#UEFITOOL SCAP HOW TO#
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.
#UEFITOOL SCAP PRO#
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.
#UEFITOOL SCAP FULL#
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)
