

Linux Foundation to offer signed solution for UEFI Secure Boot conundrum - sew
http://arstechnica.com/information-technology/2012/10/linux-foundation-to-offer-signed-solution-for-uefi-secure-boot-conundrum/

======
mjg59
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.

~~~
Sander_Marechal
> 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/...](http://www.linuxfoundation.org/news-
media/blogs/browse/2012/10/linux-foundation-uefi-secure-boot-system-open-
source)

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

~~~
asdfs
You still have to put UEFI into setup mode, which means dealing with a non-
standard UI.

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

~~~
bryanlarsen
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.

------
wmf
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>

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

------
iSnow
There goes all hope to ever switching my parents to Linux.

They see a textual boot screen, they'll demand Windows back.

------
rsync
Splashscreen, and requires _user input before booting_. That's going to work
really well in a datacenter environment...

~~~
mjg59
To be fair, it's not intended for a datacentre environment - you'd either
reconfigure your keys or use a fully signed distribution.

~~~
nodata
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!

