A brief history of Mac firmware

0

Firmware, software that’s intimately involved with hardware at a low level, has changed radically with each of the different processor architectures used in Macs.

Classic Macs based on Motorola 68K processors come with their own Macintosh ROM. That changed after the first PowerPC models of 1994, and the Power Macintosh 9500 from 1995 supports Apple’s version of Open Firmware. That had originated as OpenBoot in Sun Microsystems’ SPARC-based computers, and is based on the language Forth. Macs with Open Firmware can be booted into an interactive interface that makes it relatively straightforward to support and bring up new hardware. It’s also a security nightmare.

Firmware version numbering was elaborate, with a ROM revision, here $77D.45F6, a Boot ROM version of $0004.25f1, and a Mac OS ROM file version of 8.4, for this Power Mac G4 running Mac OS 9.2.1 in 2002. Apple supplied separate Mac OS ROM file updates as needed.

EFI

In 1998, Intel started work on the original Extensible Firmware Interface (EFI) as its intended replacement for the BIOS in PCs. By the time Apple was beginning its transition from PowerPCs in 2006, EFI was changing into Unified EFI (UEFI), and has since progressed as far as version 2.10 in 2022.

Once an Intel Mac has cleared its initial self-test routines (POST), and key custom chips like the SMC are running, EFI firmware is loaded next. The purpose of the EFI phase and the boot loader boot.efi is to augment the basic facilities provided by BootROM to the point where the macOS kernel can be loaded with its extensions. Key to this is providing access to the Mac’s hardware through the device tree, IODeviceTree, listing and relating all the devices in that Mac. This is built by boot.efi and passed to the kernel when it loads, and forms the basis for IOKit within macOS.

Model-specific boot.efi software also provides ongoing and additional support for boot services, including memory management, basic functions for timers and events, and for hardware access. It supports basic console protocols for input and output, and access to storage systems. Runtime services extend these to give access to variables stored in the NVRAM, and to GUIDs/UUIDs used for key variables in the EFI phase and later. Most importantly, boot.efi looks for startup key commands, originally named snag keys by Apple, such as Command-R to run in Recovery mode, Command-S and -V for Single User and Verbose modes, and Shift for Safe mode.

When Apple introduced Boot Camp in 2006, it made changes to boot.efi to support booting from operating systems other than macOS. This essentially provides a suite of drivers supporting Mac hardware in terms of a Windows hardware platform, engaged when the Mac is to be booted in that operating system rather than macOS.

Firmware security

In March 2015, two security researchers from LegbaCore, Xeno Kovah and Corey Kallenberg, demonstrated proof-of-concept attacks on the BIOS of several computers including Dell, HP, and other PCs that could have been used to implant malicious code. Later that year, Kovah and Trammell Hudson turned their attention to Macs, demonstrating a firmware worm named Thunderstrike 2.

For the first nine years of Intel Macs, Apple had provided EFI firmware updates separately from updates to OS X. That year, Apple changed the way that it supplied firmware, delivering it only as part of system upgrades and updates. Although older separate firmware updates are still available, those were the last.

Then in 2017, Rich Smith and Pepijn Bruienne of Duo Labs discovered that many Macs were running outdated firmware. Their concern was less about potential bugs and other problems, and more about the security risk posed. Apple had already been busy, hiring Xeno Kovah and Corey Kallenberg who started work there in November 2015, and Nikolaj Schlej, another firmware security researcher, who joined them the following August. They developed a new tool eficheck, released in High Sierra on 25 September 2017. Each week until it was dropped from Sonoma, eficheck checked current firmware against a local database of versions known to be ‘good’, and with the user’s permission sent a report to Apple in the event that it found discrepancies.

Back in late 2017, this iMac17,1 was reported as running Boot ROM version IM171.0105.B26.

T2 firmware

In 2016, the year before Smith and Bruienne’s report, Apple introduced first the T1 chip, then hot on its heels the T2 the following year. With two separate CPUs in each T2 Mac, there are two separate sets of firmware, one EFI and the other known as iBridge or BridgeOS. Following the established pattern, both are only updated by macOS installers and updaters.

After standard power-on self-test and SMC initialisation, the T2 sub-system establishes the level of Secure Boot in force, and, if that’s Full or Medium Security, boot.efi is checked before being loaded, providing security throughout the boot process.

Apple silicon Macs

The introduction of Macs using the M1 family of chips in 2020 brought complete change in firmware to support Secure Boot, and moves away from UEFI completely. The aim of boot security in Apple silicon Macs is to provide a verified chain of trust through each step in the boot process to the loading of macOS, that can’t be exploited by malicious components. This consists of four main stages:

The Boot ROM in the hardware.
The Low-Level Bootloader, LLB, or first stage.
iBoot, or second stage.
The macOS kernel, which loads all its required kernel extensions.

One of many changes made from UEFI is that startup key combinations have been replaced by the Power button to engage Recovery and other special startup modes, which has both improved security of Recovery mode and made its features more accessible. Instead of the user having to memorise a list of different key combinations required to access different features, all are now integrated within a single environment.

Apple silicon Macs are the first Macs whose firmware can be both upgraded and downgraded by restoring them from IPSW image files when the Mac has been put into DFU mode. For the time being, at least, all Apple silicon Macs run a unified firmware version tied not to the chip or model, but to the macOS version, and only delivered in IPSW files and macOS updates.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.