> 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.
>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.
> 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?
>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.
> 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.