There's a set of somewhat conflicting tensions involved in dealing with Secure Boot, and as a result there's going to be a range of solutions. The tl;dr version is that I understand why the Linux Foundation solution is the way it is, I just don't think it's terribly useful.
Doing Secure Boot properly is hard. You need to secure a whole range of components at the code level, you need to keep signing keys secure and you need to figure out what your policy is for handling key compromise or revocation. I've been working on this almost full time for a year now, and it's completely unreasonable to expect small distributions to keep up with all of this. Fedora can afford to develop and maintain the entire stack, but Mint? Arch? Slackware? I don't run any of these them, but I think diversity is important and it'd be a disaster if all of these more niche distributions vanished simply because users aren't able to install them any more.
So it's important to come up with a solution that allows end users to choose which software they want to run. To Microsoft's credit, they added a requirement that it be possible to reconfigure the key database on x86 systems after the outcry that accompanied their initial announcements. But the UI for that is wildly inconsistent between vendors, and sometimes even between different ranges from the same vendor. HP's consumer laptops need keys to be stored in one format, HP's enterprise laptops in another. It's a significant barrier to entry, especially amongst users with less technical expertise.
The Linux Foundation's approach attempts to handle that, by presenting a simple UI whenever you attempt to boot. Hit y and it'll run whatever you want. But the problem here is that it intrinsically classes Linux as a second-class citizen. Linux becomes the OS that can't reboot itself. It's the OS that pops up an ugly text entry box every time you turn your computer on. It's the OS that asks you if you're sure you want to run potentially insecure code. 10 years of progress in making Linux accessible to users, gone.
Suse came up with a more elegant approach, and we've been building on that in Fedora. The current version of Shim (so called because it wedges itself into Microsoft's trust model and bridges it into a different trust model) has bootloader-level UI that permits the user to enrol a key or a bootloader hash. If the second-stage bootloader is signed by a key it trusts, it'll simply boot that. If it's not, it'll fall back to a 10-second timeout that lets the user drop to a menu and modify their key database. If the distribution ships a signing key, they can enrol the public key. If not, they can enrol a hash of the bootloader. Afterwards, the system will boot. Post-install, it'll still boot. No dialog. No sitting there forever waiting for user interaction. One single extra step in the install process, and it's completely consistent no matter what hardware you're running on.
I think this is a wildly better solution. Big distributions with the ability to support industry expectations around secure boot can ship something that installs without any additional user interaction. Smaller distributions or end-users who want to use their own modified bootloader or kernel can enrol their key in a single step and not worry about it in future. It's not quite as easy as "press y", but it's something you do once and then your computer Just Works.
It's unfortunate that the Linux Foundation ended up taking this approach, because it's going to be perceived as the official Linux response despite it being completely different to what every Linux distribution working on this problem has implemented. Now we have to deal with a perception that Linux will only work with Secure Boot as long as you never reboot, which couldn't be further from the truth.
> But the problem here is that it intrinsically classes Linux as a second-class citizen. Linux becomes the OS that can't reboot itself.
Untrue. Read the LF article linked from this. After the user interaction screen, the key of the second bootloader can be installed on the machine. After that the system can boot directly without user intervention, even with Secure Boot fully enabled.
> the pre-bootloader will also check to see if the platform is booting in Setup Mode and if it is, will ask the user for permission to install the signature of loader.efi into the authorized signatures database. If the user gives permission, the signature will be installed and loader.efi will then boot up without any present user tests on all subsequent occasions even after the platform is placed back into secure boot mode.
I still don't get the major difference between LF and SuSE solutions. In both, if you have signed system it will boot without intervention. And if you have "untrusted" system then both will allow user to add the keys so that it'll become trusted.
My non-expert and possibly wrong understanding: the difference is where the keys are stored. The LF solution keeps it all within the UEFI store, so you have to put UEFI into "setup mode" so that their prebootloader can enroll keys, or you have to manually enter the key yourself within UEFI. In both cases, you need to deal with the UEFI user interface. The SuSE solution can also use its own key store, which means that the Shim itself can enroll its own keys in its own storage area using its own UI.
The whole thing is really screaming for a flowchart, since explaining it all through text can be quite confusing.
We encouraged them to, but they felt that it was too complicated and violated their understanding of the trust model. I obviously disagree, and I'm obviously not impressed by the Linux Foundation picking an approach that's at odds with 100% of the member companies who've voiced opinions on the topic, but the Technical Advisory Board is an autonomous group with no community oversight so there's little opportunity to influence them.
Doing Secure Boot properly is hard. You need to secure a whole range of components at the code level, you need to keep signing keys secure and you need to figure out what your policy is for handling key compromise or revocation. I've been working on this almost full time for a year now, and it's completely unreasonable to expect small distributions to keep up with all of this. Fedora can afford to develop and maintain the entire stack, but Mint? Arch? Slackware? I don't run any of these them, but I think diversity is important and it'd be a disaster if all of these more niche distributions vanished simply because users aren't able to install them any more.
So it's important to come up with a solution that allows end users to choose which software they want to run. To Microsoft's credit, they added a requirement that it be possible to reconfigure the key database on x86 systems after the outcry that accompanied their initial announcements. But the UI for that is wildly inconsistent between vendors, and sometimes even between different ranges from the same vendor. HP's consumer laptops need keys to be stored in one format, HP's enterprise laptops in another. It's a significant barrier to entry, especially amongst users with less technical expertise.
The Linux Foundation's approach attempts to handle that, by presenting a simple UI whenever you attempt to boot. Hit y and it'll run whatever you want. But the problem here is that it intrinsically classes Linux as a second-class citizen. Linux becomes the OS that can't reboot itself. It's the OS that pops up an ugly text entry box every time you turn your computer on. It's the OS that asks you if you're sure you want to run potentially insecure code. 10 years of progress in making Linux accessible to users, gone.
Suse came up with a more elegant approach, and we've been building on that in Fedora. The current version of Shim (so called because it wedges itself into Microsoft's trust model and bridges it into a different trust model) has bootloader-level UI that permits the user to enrol a key or a bootloader hash. If the second-stage bootloader is signed by a key it trusts, it'll simply boot that. If it's not, it'll fall back to a 10-second timeout that lets the user drop to a menu and modify their key database. If the distribution ships a signing key, they can enrol the public key. If not, they can enrol a hash of the bootloader. Afterwards, the system will boot. Post-install, it'll still boot. No dialog. No sitting there forever waiting for user interaction. One single extra step in the install process, and it's completely consistent no matter what hardware you're running on.
I think this is a wildly better solution. Big distributions with the ability to support industry expectations around secure boot can ship something that installs without any additional user interaction. Smaller distributions or end-users who want to use their own modified bootloader or kernel can enrol their key in a single step and not worry about it in future. It's not quite as easy as "press y", but it's something you do once and then your computer Just Works.
It's unfortunate that the Linux Foundation ended up taking this approach, because it's going to be perceived as the official Linux response despite it being completely different to what every Linux distribution working on this problem has implemented. Now we have to deal with a perception that Linux will only work with Secure Boot as long as you never reboot, which couldn't be further from the truth.