Linux Foundation to offer signed solution for UEFI Secure Boot conundrum(arstechnica.com)
arstechnica.com
Linux Foundation to offer signed solution for UEFI Secure Boot conundrum
http://arstechnica.com/information-technology/2012/10/linux-foundation-to-offer-signed-solution-for-uefi-secure-boot-conundrum/
6 comments
> 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.
http://www.linuxfoundation.org/news-media/blogs/browse/2012/...
> 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.
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.
http://www.linuxfoundation.org/news-media/blogs/browse/2012/...
> 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.
You still have to put UEFI into setup mode, which means dealing with a non-standard UI.
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.
The whole thing is really screaming for a flowchart, since explaining it all through text can be quite confusing.
How could the bootloader in SuSE solution keep the keystore secure?
edit: Disregard that question. Apparently UEFI provides storage for the bootloader which is used as keystore
edit: Disregard that question. Apparently UEFI provides storage for the bootloader which is used as keystore
Thanks for the insight. At the risk of asking a question b/f RTFA, why isn't Linux Foundation using Suse/Fedora's solution?
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.
[T]he Linux Foundation bootloader will present its own splash screen and require user input before it actually boots.
That is not a good compromise: I regularly remotely reboot linux machines. In the best case, the machine is in my basement (annoying). In the worst case, I have to drive 58 miles. Ouch.
I'm sensitive to this right now because I had to do that just this week. I did an upgrade and reboot on a machine that had the BIOS boot order set incorrectly - it was trying to boot off a non-bootable USB drive.
That is not a good compromise: I regularly remotely reboot linux machines. In the best case, the machine is in my basement (annoying). In the worst case, I have to drive 58 miles. Ouch.
I'm sensitive to this right now because I had to do that just this week. I did an upgrade and reboot on a machine that had the BIOS boot order set incorrectly - it was trying to boot off a non-bootable USB drive.
If you need remote boot then you can unlock your UEFI or add the keys. The point is that this will let normal users both boot and still be safe. Normal users don't remote boot.
According to http://news.ycombinator.com/item?id=4644079 that's not the case. It only needs the input the first time.
Not to distract from the topic but if you've got remote machines, IPMI can be a lifesaver.
[deleted]
This looks worse than the SuSE solution; I'm not sure what the point is. https://www.suse.com/blogs/uefi-secure-boot-details/ http://mjg59.dreamwidth.org/17872.html
Geez. Just use shim - https://github.com/mjg59/shim
There goes all hope to ever switching my parents to Linux.
They see a textual boot screen, they'll demand Windows back.
They see a textual boot screen, they'll demand Windows back.
Splashscreen, and requires user input before booting. That's going to work really well in a datacenter environment...
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.