> 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.
Physical access to the computer meant you could boot it into the OpenFirmware interface, which not just had an interactive interface but allowed for entering code (I seem to recall finding someone's Towers Of Hanoi solver written for OpenFirmware and typing that into my own machine once), so a malicious actor could use it to tamper with the boot process.
It is a security nightmare by today’s standards, and was hard to secure back then as well.
Apple devices provide a good exemplar because of their significant investments in security, but it’s not the only company making devices about which you can say physical control is no longer an absolute proxy for logical control.
Take for instance an Apple silicon Mac (or for that matter an iPhone). Generally speaking you could steal it from someone but without the credentials it’s more or less a brick.
Apple silicon Macs in particular have firmware that requires certain base actions to be authorized with the password of the “Owner” account, which is (typically) the first user account created on the machine. Without that, it will just stare back at you.
Are there vulnerabilities that could enable a bypass? Probably. Are those in the hands of any given evil maid or thief? Exceedingly unlikely.
>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.
What stops me from writing a malicious firmware implant which tampers with the local database every time the computer boots, and inserts itself as "known good"?
I don't see how it's possible to monitor the firmware from the OS, if the OS already implicitly trusts the firmware...
Also: Does anyone know of good resources for learning about firmware security from the ground up? Seems like this article already assumes a certain level of background knowledge.
Additionally recent iBoot versions use an in-house Safe C dialect, and one of the reasons behind the embedded Swift effort is to eventually replace it with Swift.
> 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.
That's interesting; does "normal" PC UEFI pass a device tree to the OS? I thought hardware was enumerated at runtime.
Note that "device tree" can include things like "PCIe root port"
This device tree is describing fixed (per BOM/schematic) hardware. Things below that hardware are still enumerated.
I really wish this had won out over ACPI. It didn't, though, so Arm Server ready is all ACPI-ified, complete with the tooling trash-fire that the ecosystem entails.
Normally UEFI creates ACPI tables that have some similarity with device trees.
PowerPC OS X probably expected a device tree provided by Open Firmware so when they switched to EFI they probably added that boot.efi shim so the kernel didn't have to change much.
It doesn't really matter whether the bootloader or the kernel enumerates hardware.
> 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.
What made it a security nightmare?
Physical access to the computer meant you could boot it into the OpenFirmware interface, which not just had an interactive interface but allowed for entering code (I seem to recall finding someone's Towers Of Hanoi solver written for OpenFirmware and typing that into my own machine once), so a malicious actor could use it to tamper with the boot process.
> Physical access to the computer meant ...
... game over. That's one well understood fact back then as it is today. Where's the security nightmare?
It is a security nightmare by today’s standards, and was hard to secure back then as well.
Apple devices provide a good exemplar because of their significant investments in security, but it’s not the only company making devices about which you can say physical control is no longer an absolute proxy for logical control.
Take for instance an Apple silicon Mac (or for that matter an iPhone). Generally speaking you could steal it from someone but without the credentials it’s more or less a brick.
Apple silicon Macs in particular have firmware that requires certain base actions to be authorized with the password of the “Owner” account, which is (typically) the first user account created on the machine. Without that, it will just stare back at you.
Are there vulnerabilities that could enable a bypass? Probably. Are those in the hands of any given evil maid or thief? Exceedingly unlikely.
>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.
What stops me from writing a malicious firmware implant which tampers with the local database every time the computer boots, and inserts itself as "known good"?
I don't see how it's possible to monitor the firmware from the OS, if the OS already implicitly trusts the firmware...
Also: Does anyone know of good resources for learning about firmware security from the ground up? Seems like this article already assumes a certain level of background knowledge.
Sealed volume? On modern osx I think large parts are effectively read-only.
Hm, seems like that's enforced by the kernel. I'm not sure I can trust the kernel if I can't trust the firmware.
Additionally recent iBoot versions use an in-house Safe C dialect, and one of the reasons behind the embedded Swift effort is to eventually replace it with Swift.
> 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.
That's interesting; does "normal" PC UEFI pass a device tree to the OS? I thought hardware was enumerated at runtime.
Note that "device tree" can include things like "PCIe root port"
This device tree is describing fixed (per BOM/schematic) hardware. Things below that hardware are still enumerated.
I really wish this had won out over ACPI. It didn't, though, so Arm Server ready is all ACPI-ified, complete with the tooling trash-fire that the ecosystem entails.
Normally UEFI creates ACPI tables that have some similarity with device trees.
PowerPC OS X probably expected a device tree provided by Open Firmware so when they switched to EFI they probably added that boot.efi shim so the kernel didn't have to change much.
It doesn't really matter whether the bootloader or the kernel enumerates hardware.