Important note: Secure Boot is not designed to defend against an attacker with physical access to a machine
Unfortunately, in practice that's what it often does, and the user is considered an "attacker". All this complexity is scary, and threatens to turn PCs into locked-down devices like the mobile world has done. I wonder if pre-UEFI/pre-ME x86 systems will become more valuable sometime in the future, because of this.
> turn PCs into locked-down devices like the mobile world
I used to wonder, even before iPhone and Android, how far away we were from a world where most “computers” were effectively unconfigurable and unprogrammable, and actual programmable computers like the ones we’re used to became relatively rare “makers tools”. That does seem to be the way things are headed; there may come a point in our lifetimes where almost nobody has a “programmers computer” in their house.
Note that the UEFI spec for x86 requires user-modifiable keys (after public outcry), but the spec for ARM requires NO user-modifiable keys. (Edit: actually this may only be a Windows requirement)
UEFI spec insists in root of trust being specified by vendor, Microsoft requires ability to set completely owner-controlled keys because they offer that as part of highest security mode on Windows for corporate clients.
If secure boot isn’t designed to defend against hardware attacks then why is their such emphasis on security? Does this long, complicated boot procedure somehow protect against remote motherboard firmware loading?
The idea was to prevent bootkits. In UEFI the last phase, the complete UEFI phase after DXE and all the parts that come before it, is to read the EFI boot options from NVRAM. If there are no configured bootloaders, EFI volumes are read from GPT disks (and el-torito extensions to iso9660 cd roms) and one of these is booted - one of:
for x86-64, x86 and AArch64 (64-bit ARM) respectively. These are if you like the default boot paths on EFI volumes.
On pre-UEFI IBM-compatible systems, the equivalent was to look for the master boot record on a disk (or equivalent on iso9660 el-torito extensions). The MBR should end with 0x55 0xAA in the first 512 bytes of the disk - if these bytes are set, the whole thing is loaded into RAM at 0x7c00 and executed - in real mode, full segmented addressing and the A20 line not set, meaning you have only 1MB of RAM to play with until you get set up. No verification was done for this at all.
In spite of the complexity of the process, it was possible to create a "bootkit" simply by overwriting that MBR sector of the disk with custom code. This way you could modify the operating system before it had a chance to load, invalidating any security guarantees it could possibly give.
The equivalent in UEFI terms is to ask for the EFI variables to change, or replace one of those specified files. This will enable you to take control before the system starts - there's plenty of articles on hooking ExitBootServices to modify the system.
With UEFI's Secure Boot function turned on, even if you can persuade the operating system to overwrite those binaries or drop a custom one, the UEFI firmware will check the digital signature (or hash) before executing the code. It's exactly the same defense as driver signing - unsigned code is not allowed to run.
This isn't a complete solution. As the author notes, parts of flash may be unsecured and drivers may provide the facility to write to it in an unrestricted fashion, allowing the chain of trust to be compromised earlier. It's also possible to attack physically. There are all kinds of issues with CPU security.
On x86 systems, Microsoft's own compatibility guidelines for PCs mandate the ability to change the platform owner key, KEK, DB and DBX keys. The parent comment on lockdown is a valid concern (on Microsoft's ARM platforms, no change is possible) but at least for PC hardware it is possible to load your own keys and render Windows unable to boot.
Exactly. Additionally Microsoft requires vendors to allow disabling Secure Boot on x86 (not so on ARM). I'm on mobile so excuse me the lack of source link.
It's not always easy to do (and Microsoft could always exempt themselves from surface devices) - I think the spec only requires that it is possible, not that there is a nice dialog box in the bootloader to do it (unfortunately).
Specifically, what I'd do is: disable secure boot, copy shell.efi and keytool to the ESP, add a boot entry for the shell.efi entry, always useful, then boot to it, run keytool, clear the PK - voila you are in setup mode and should be able to change everything.
Be aware that once you set a platform key, updates to any key database are checked for valid signatures. Updates to the KEK must be signed by PK, updates to the DB, DBX must be signed by the KEK, etc. If there's no dialog, you might also want to back up the keys, if you want to set the machine back to its factory default setting.
I can imagine Microsoft might not have enabled this level of control for their surface devices, although as I understand their HCK, they should. Perhaps they exempt themselves :(
I think people have broken UEFI+ARM. I've seen posts about running Linux on the older Windows mobile devices. The bigger problem is none of the hardware has any OSS driver support, so even if you can get a different OS to boot, you still can't use things like Wi-Fi/BT/video acceleration.
I find it strange that they bother, since in the end you can always just run a fullscreen Linux VM and hand it over 99% of the computer’s resources.
Maybe Apple’s true worry might be revealed by considering the difference between what they allow and what they prevent. Apple allow you to have a wholly-Linux UX on an Apple laptop; but they don’t allow Linux developers to run a Linux kernel directly on Apple hardware.
Maybe what they’re really concerned about is Linux having an easy testbed for developing MacBook hardware/peripheral drivers, such as for the T2, such that people could build apps in other OSes that take advantage of the touchbar, and thus in some way “commoditize” one of the costlier USPs of macOS?
If a minuscule number of people buying your hardware ever run linux, would you waste even one week testing support for it? Would you waste even a single EFI engineer's time on it? What if it were 0.1%? Or 0.01%?
What leads you to believe anyone at Apple spent even 5 minutes thinking about linux support at any point in time?
My understanding is that Apple didn't try to block anything, Linux just lacked appropriate driver support for their disk.
It is a testament to how far Linux on the desktop has come that our first assumption when Linux doesn't boot on a new machine is "The megacorp is using secret cryptography" and not "eh, missing drivers."
"Missing drivers" doesn't quite accurately convey what Apple did. They bastardized the NVMe spec, requiring OS developers to add Apple-specific workarounds to their existing drivers.
Sure, but it's not like "Vendor didn't quite implement a spec the way they should have, requiring driver quirks" has never happened before in the history of Linux drivers....
I can't recall any NVMe device requiring as many workarounds as the Apple T2. Usually it's something along the lines of certain power states not working as intended, or the drive not providing a unique identifier. Apple changed the size of fundamental data structures, botched the interrupt handling, imposed unnecessary constraints on the mixing of IO and admin commands, and effectively broke one of the biggest performance advantages of NVMe (multiple IO queues).
And some vendors actually help with the development of workarounds for their broken drives, and push out firmware fixes when possible so that the workarounds can be disabled on newer or updated devices.
I really wish efibootmgr did validation to ensure the EFI entries were correct and pointing to valid executables. I've seen a lot of devices where the firmware won't even list entries if it can't find the actually file it should load. Dell firmware is some of the best because it lets you edit EFI vars right in the setup screen, and even search for and add boot entries.
Speaking of UEFI ... if anyone wants to try Secure Boot with OVMF—the open source implementation of UEFI for virtual machines—in a Linux-based environment, here's a stupid shell script (usual caveat, please inspect it before you run :-)) that I sometimes use for testing.
It installs a minimal (@core-only in 'kickstart' parlance) Fedora with Secure Boot, which you can verify by `dmesg | grep Secure` once the guest boots.
I wrote this script on a Fedora 29 host, with KVM (the Kernel-based Virtual Machine), libvirt, QEMU and OVMF / EDK2 packages.
Unfortunately, in practice that's what it often does, and the user is considered an "attacker". All this complexity is scary, and threatens to turn PCs into locked-down devices like the mobile world has done. I wonder if pre-UEFI/pre-ME x86 systems will become more valuable sometime in the future, because of this.