Garrett: Secure Boot and Restricted Boot

Just to make sure we're using the words right, "UEFI" is the name of the binary architecture and APIs for booting a computer in a way that doesn't involve it pretending to be an original IBM PC first. UEFI is (on paper) a Good Thing, because it means that the lives of bootloader and kernel authors suck less, and they get a reasonable API to the system and can write reasonable code in a reasonable development environment. (In practice, we're better at dealing with 16-bit BIOS implementations because of the quarter-century of experience than at 64-bit UEFI implementations that were just released, but that should change soon.)

Secure Boot is a cryptographic-validation feature that you can implement on top of UEFI, because it doesn't suck the way that BIOS sucks -- namely, since the firmware loads an entire 64-bit executable in a reasonable format instead of a 400-byte COM file, it's actually reasonable to expect the thing you loaded to do second-stage cryptographic validation. There are plenty of EFI / UEFI implementations that just don't involve Secure Boot at all, including every Mac made in the last several years.

"Secure Boot" and "Restricted Boot" as Matthew uses them in this article are policy requirements on top of the Secure Boot feature in the UEFI platform. (Incidentally, the arguments he makes apply equally well to cryptographic boot validation approaches on other platforms that don't really involve UEFI and thus technically aren't Secure Boot, including Android, iOS, and Chrome OS devices as well as game consoles, TiVos, etc. etc. etc.)