8 ms·

Linux Foundation to offer signed solution for UEFI Secure Boot conundrum

47 points by sew 14y ago

gvb 14y ago
[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.
- DASD 14y ago
  Not to distract from the topic but if you've got remote machines, IPMI can be a lifesaver.
- bryanlarsen 14y ago
  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.
- deleted 14y ago
  [deleted]
- ars 14y ago
  According to http://news.ycombinator.com/item?id=4644079 http://news.ycombinator.com/item?id=4644079 that's not the case. It only needs the input the first time.
wmf 14y ago
This looks worse than the SuSE solution; I'm not sure what the point is. https://www.suse.com/blogs/uefi-secure-boot-details/ https://www.suse.com/blogs/uefi-secure-boot-details/ http://mjg59.dreamwidth.org/17872.html http://mjg59.dreamwidth.org/17872.html
bcl 14y ago
Geez. Just use shim - https://github.com/mjg59/shim https://github.com/mjg59/shim
mjg59 14y ago
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.
rsync 14y ago
Splashscreen, and requires user input before booting. That's going to work really well in a datacenter environment...
- mjg59 14y ago
  To be fair, it's not intended for a datacentre environment - you'd either reconfigure your keys or use a fully signed distribution.
  - nodata 14y ago
    I don't want a solution intended for a specific environment, or to manage keys or use a signed distribution, I want to boot my computer!
    - thedeuce 14y ago
      then make your own
iSnow 14y ago
There goes all hope to ever switching my parents to Linux. They see a textual boot screen, they'll demand Windows back.

47 points by sew 14y ago

gvb 14y ago

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

DASD 14y ago
Not to distract from the topic but if you've got remote machines, IPMI can be a lifesaver.
bryanlarsen 14y ago
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.
deleted 14y ago
[deleted]
ars 14y ago
According to http://news.ycombinator.com/item?id=4644079 http://news.ycombinator.com/item?id=4644079 that's not the case. It only needs the input the first time.

wmf 14y ago

This looks worse than the SuSE solution; I'm not sure what the point is. https://www.suse.com/blogs/uefi-secure-boot-details/ https://www.suse.com/blogs/uefi-secure-boot-details/ http://mjg59.dreamwidth.org/17872.html http://mjg59.dreamwidth.org/17872.html

bcl 14y ago

Geez. Just use shim - https://github.com/mjg59/shim https://github.com/mjg59/shim

mjg59 14y ago

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.

rsync 14y ago

Splashscreen, and requires user input before booting. That's going to work really well in a datacenter environment...

mjg59 14y ago
To be fair, it's not intended for a datacentre environment - you'd either reconfigure your keys or use a fully signed distribution.
- nodata 14y ago
  I don't want a solution intended for a specific environment, or to manage keys or use a signed distribution, I want to boot my computer!
  - thedeuce 14y ago
    then make your own

iSnow 14y ago

There goes all hope to ever switching my parents to Linux. They see a textual boot screen, they'll demand Windows back.