Garrett: Supporting UEFI secure boot on Linux: the details

"Let's ignore the issues of key distribution and..."

So...it's going to be pretty easy, if we ignore the fact that it may be impossible. :)

(Actually, that is a little bit reassuring, but not as reassuring as I'd like. Can't fault Matthew for not providing information he doesn't have, though.)

I do love the bit about "[U]ntil earlier this week the only widely available developer firmware (Intel's) was incompatible with the only widely available signed OS (Microsoft's)." So freakin' typical! :)

a week? that sounds over confident to me. would this code be tested in any way and would it provide security to the linux deployment or just circumvent whatever secure boot features that where there in a trivial and meaningless way? (equivalent to disabling it in the bios)

It will take more than a week to even test to see if secure uefi installations actually work for any distro that does more than developer smoke testing before rolling code out. how much testing does Fedora do on its installation code changes?

There should also be some penetration testing to make sure nothing dumb gets in that invalidates the security. The pen-testing isn't trivial and needs some settling time. more than a week.

What about OS update tools? What would kernel or initial ramdisk updates look like for such a thing? I think there may be a can of worms there to deal with.

Lastly what if there is a TPM and a measured boot is available in addition to the secure boot? would we be able to support that?

Basically we should be able to enable an end user to lock down their own deployments (personal laptop or embedded gadget) as well as MS gets to lock down Win8. (I hope even better)

Please don't feed me noise that "Linux is secure" kernel.org has been down for a month! how embarrassing! (and irritating)

The attitude of not taking this stuff seriously only hurts the community.

I reckon we only get this one chance to raise a ruckus and get this right. So lets get rowdy.

Anything less than what I propose below and we lose. Maybe not this year, maybe not five years out, but eventually.

I want to boot the firmware and be able to a) clear the existing key store. and then b) tell the firmware to look on the install media (optical, USB, net, whatever) for a file containing key(s) to trust. Then I want it to look on a USB stick for MY personal (and/or company) key and to add it to the list, equally trusted. Then tell it to boot that media and install an OS.

And that install media can be a copy of Windows, RHEL, Debian or the most obscure BSD fork and it won't matter. No CAs to worry about who they will and won't sign a cert for, no unremovable OEM or Microsoft key lurking in the BIOS along with an unknown number of keys nobody really knows who owns but every motherboard just seems to come with, none of that foolishness.

"It was also possible to bypass the copyright monitors by installing a modified system kernel. Dan would eventually find out about the free kernels, even entire free operating systems, that had existed around the turn of the century. But not only were they illegal, like debuggers—you could not install one if you had one, without knowing your computer's root password. And neither the FBI nor Microsoft Support would tell you that."

-- https://www.gnu.org/philosophy/right-to-read.html