Garrett: Secure Boot and Restricted Boot [LWN.net]

Garrett: Secure Boot and Restricted Boot

Posted Mar 28, 2013 16:52 UTC (Thu) by ortalo (guest, #4654)
Parent article: Garrett: Secure Boot and Restricted Boot

The situation does not seem so complex to me.

Personally I'd sum up as:
- UEFI as SecureBoot: neutral. You can buy. (If it's mine or you ask me I'll deactivate it. If you want to activate, either ask M$ or -preferably- that Matthew from Nebula on the web).
- whatever as RestrictedBoot: negative. Do not buy. (Or, that's your money.)

It seems to me this is in support of Matthew's position, though probably not as much as he would like.

But hey, I would also like him to work on fancier things like relying on a smartcard to check kernel or program signatures efficiently and things like that (and possibly on phones or portable devices). Nobody's willing to fund him for that? (After all, he seems especially competent and interested in that field.) The end result might be interesting enough to compete with proprietary restricted boot solutions based on its own technical and security merits (like most of free software). General market adoption is another issue (remember once upon time, Apple and M$ also tried to replace TCP/IP, but then they stopped). I also know of a few very specific niches where it may make a lot of sense any time (but niche markets are niches of course).

Funnily, all the (interesting) debate around UEFI has not made me change my position so much: support the man and forget about the thing... Admittedly, if he asks me to actively support the technology, this will make up for a short schizophrenic stasis. But I'll see.

to post comments

Garrett: Secure Boot and Restricted Boot

Posted Mar 29, 2013 2:41 UTC (Fri) by geofft (subscriber, #59789) [Link] (2 responses)

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

Garrett: Secure Boot and Restricted Boot

Posted Mar 29, 2013 3:32 UTC (Fri) by raven667 (subscriber, #5198) [Link]

That is a great way to put it, you win at internets.

Garrett: Secure Boot and Restricted Boot

Posted Mar 29, 2013 15:38 UTC (Fri) by ortalo (guest, #4654) [Link]

Thanks for the clarifications too. (Indeed, my own usage of the UEFI acronym was probably inexact; btw, I had equally in mind something more generic than one boot implementation as well as something more specific with respect to security.)