Posted 2017 September 17
In preparing a larger post on deployment and terminology, I did some research on Apple EFI Firmware Update downloads and thought that my findings, while fairly straightforward to research, were nevertheless worth documenting in one place.
If you look through the history of Apple EFI (and SMC) Firmware updates, they were not released en masse. Individual models or families received updates that would show up in Software Update on the applicable Mac; you could also download those updates separately from support.apple.com/downloads. These updates were functionality changes, usually fixing bugs.
Thunderstrike changed all that. In late 2014, security researcher Trammell Hudson found a vulnerability that allowed untrusted code to be flashed to the boot ROM, in this case via the Thunderbolt port. You couldn't fix this in the OS; you had to patch the EFI firmware. All of a sudden, Apple needed to patch any Mac with a Thunderbolt port. This is the moment that Apple changed the way they delivered firmware updates.
So on 2015 January 27, Apple included an EFI and SMC firmware update in the 10.10.2 (Yosemite) updater. Apple’s detailed information page on the update mentions which computers would be patched and the fact that only 10.10.0 or 10.10.1 systems would receive the patch. When similar vulnerabilities were found later in 2015 — dubbed Thunderstrike 2 by the researchers — Apple once again released the firmware patches inside of an OS upgrade (to 10.10.4) but also released the patch within a Security Update for 10.8.5 (Mountain Lion) and 10.9.5 (Mavericks). In addition, they released a redundant standalone EFI Firmware Updater for 10.8.5 and 10.9.5. Apple used this methodology a final time on 2015 October 21, when Mavericks users (only) could download a separate EFI installer alongside what was offered inside the El Capitan 10.11.1 update, Security Update 2015-004 Yosemite, and Security Update 2015-007 Mavericks. Ever since then, firmware updates have only been available through OS or Security Updates.
This means that “imaging” as a method of deploying a newer OS (particularly a major version upgrade) has actually been broken for about 2 years.
So Why The Hubbub Now?
There are two reasons that this change is now causing grief to Mac Admins who are using any deployment workflow involving laying down an image: APFS and the Touch Bar. APFS requires certain functionality within the EFI to be able to boot and for macOS to use storage formatted that way. Touch Bar MacBook Pros need to run the embedded iOS-like chip that runs the Touch Bar and that involves working with the invisible EFI partition on your Mac, which imaging doesn’t touch. (Allister Banks explains this issue very well in a recent post.) If you were deploying an image and weren’t dealing with APFS or a Touch Bar MacBook Pro, things probably didn’t break; the next time you ran an Apple OS or Security updater, the Mac’s firmware would be appropriately updated (there’s a FirmwareUpdate.pkg in every such updater in case you skip a version). However, it’s going to be difficult if not impossible to avoid APFS as a Mac Admin (unless you’re retiring or leaving the field in the next year).
In researching this post, I did find that there have been people paying close attention to these firmware issues for some time. Posts from Erik Gomez and Allister Banks addressed Touch Bar and EFI updates respectively. It is also a regular topic in the Mac Admins Slack (#autodmg and #security channels have had the most traffic on this lately). But for many of us, it’s only materially affected us recently. Nevertheless, Apple has been operating without standalone firmware updates for about two years, so while one can try some of the end-arounds documented by members of the community (even myself), it should be as a transitional tactic while one prepares a new deployment strategy that aligns with the clear direction that Apple has set.