

Making UEFI Secure Boot Work With Open Platforms - jagermo
http://www.linuxfoundation.org/publications/making-uefi-secure-boot-work-with-open-platforms

======
throwaway2048
Here is the major problem with UEFI Secure Boot. Microsoft only changed the
reqirement that secure boot must be possible to disable after there was a
public outcry, and are free to change it again any time.

They can either change a requirement to have the ability to disable it be
optional, or make the inability to disable it mandatory, like on surface
systems.

Thats the real issue. In very real way, Microsoft now hold the keys to the
future of the x86 PC archecture, and I question why people are so ready to
trust them considering their history.

The problem with supporting secure boot is it legitimizes microsoft's role as
the gatekeeper to computing. Now with a straight face they can say to
regulatory bodies "look at how many free and open source operating systems
support secure boot, there is no monopolization here". They are then free to
turn the screws, and make disabling secure boot impossible.

Not to mention distributions like fedora are making massive changes to
restrict access to users of their os when it is booted via secure boot, to
prevent windows from being "compromised". This is part of the agreement they
signed to get keys signed by Microsoft. These signed keys can also be revoked
by mictosoft at any time.[1]

I seriously do not understand why everybody has rolled over so hard on this
issue.

[1] <http://mjg59.dreamwidth.org/12368.html>

~~~
recoiledsnake
>like on surface systems.

Surface Pro ships with an unlockable bootloader. You can even remove
Microsoft's own key and install your own so that Windows can't boot.

>They can either change a requirement to have the ability to disable it be
optional, or make the inability to disable it mandatory, like on surface
systems.

No, they cannot. The antitrust govt lawyers will be all over them if they want
to try something like that.

>The problem with supporting secure boot is it legitimizes microsoft's role as
the gatekeeper to computing

Microsoft doesn't mandate that their key must be the only one to ship by
default. The fact that Linux community can't get together to make a signing
infrastructure while the OEMs are willing to add keys is not Microsoft's
fault.

>I seriously do not understand why everybody has rolled over so hard on this
issue

Simple, because the user is in real control of their PC and can add/remove
keys as they wish. And Secure Boot prevents the vast majority of non-techy
users from getting undetectable bootkits installed on their machine.

~~~
throwaway2048
>Surface Pro ships with an unlockable bootloader.

I was talking about surface systems, the arm ones with the locked boot loader,
not surface pro, the similar naming only adds confusion to this issue.

>The antitrust govt lawyers will be all over them if they want to try
something like that.

You totally ignored the point that now they can show antitrust lawyers all
these linux distros and others that support secure boot! its not about
maintaining a monopoly _cough_.

> Microsoft doesn't mandate that their key must be the only one to ship by
> default. The fact that Linux community can't get together to make a signing
> infrastructure while the OEMs are willing to add keys is not Microsoft's
> fault.

What about BSDs, what about haiku, what about the hacking project some guy
wrote last week, should they all be held responsible "for not getting their
act together" and getting OEMs to distribute their signing keys so Microsoft
doesn't directly control their fate?

The point is that this is a very intentional barrier to entry, its exactly the
same tactic Microsoft has been using for decades to shut out competitors, but
its totally sincere this time, and only about protecting users? Sorry i don't
buy it.

>Simple, because the user is in real control of their PC and can add/remove
keys as they wish.

For now, and a requirement that was only added after Microsoft went ahead with
requiring secure boot when people complained. They already distribute fully
locked down systems, is it such a stretch to believe they will permit, or even
mandate it in the future for x86?

Even if they never choose to lock down x86 systems entirely, why is this
obvious conflict of interest being allowed to exist.

>Secure Boot prevents the vast majority of non-techy users from getting
undetectable bootkits installed on their machine.

Anti-bootkit security does not imply UEFI Secure Boot where Microsoft controls
the only key on every x86 PC of consequence.

~~~
drivebyacct2
>Anti-bootkit security does not imply UEFI Secure Boot where Microsoft
controls the only key on every x86 PC of consequence.

So then, Microsoft releases Windows 9. It's signed with Microsoft's key. You
go out and buy a Windows 9 laptop. But wait, they didn't pre-enroll the
Microsoft SecureBoot key, now you're screwed and you can't even boot your
brand new computer.

That's the scenario if you don't pre-enroll the key. I'd love it if we could
somehow guarantee they'll never change their mind and remove that requirement.
In that absence of that, smarter solutions are needed- it's not as simple as
people make it out to be.

~~~
throwaway2048
it could enroll on first boot, it could warn you if the boot sector/etc
changes, it could do an almost infinite amount of things that do not require
Microsoft to become the sole gatekeeper.

Microsoft could also make a legally binding gaurentee they would never change
their minds about it, but you can be certain they wont.

There is a strong parallel to CableCard[1], when cable companies were allowed
to bake their network PPV/etc authorization directly into their receivers,
somehow it seemed that CableCard was never reliable for people with stuff like
TIVOs, it would mysteriously fail dozens of times for them, each time
requiring a visit from a cable company technician to replace the card, because
thats of course, strictly nessisary. The FCC later mandated all devices must
use CableCard for authorization, and these issues vanished.

I easily see a similar thing occurring for the ability to add your own keys.

[1]<http://en.wikipedia.org/wiki/CableCARD>

~~~
drivebyacct2
Enroll on first boot? Like literally the first time the laptop is powered on
it siphons keys from the OS? That seems... counterintuitive.

Plus, it really doesn't solve the issue we're talking about. If it enrolls on
boot then:

\- system UEFI keys are modifiable (just like they are now)

\- if you boot Windows 8 first, you're screwed... unless you can change the
keys.... like you can now.

So even if they pre-enroll, you still have the exact same problem -- will the
OEM/UEFI designer allow you to enroll keys or disable SecureBoot entirely?

Personally, I understand your worry 100% but I think it's needlessly paranoid.
I simply don't see OEMs going for this, and even if they do, there will be
models simply sold without the Windows 8 sticker or what not.

~~~
throwaway2048
the point of on first boot is that Microsoft will have to use the same
mechanism as everyone else, and not be able to "prebake" keys, which
subsequently (and quite coincidentally i'm sure) have bugs in their update
procedure.

~~~
drivebyacct2
How is that _any_ different. Even every single Linux user I know has bought a
laptop and fired it up at least once before subverting the boot process to
install Ubuntu right off the bat.

So, let's assume 99.999% of consumers will boot their laptop as soon as they
get it. okay, we're still in the _exact_ same boat we've been in. Unless I'm
missing something...

>which subsequently (and quite coincidentally i'm sure) have bugs in their
update procedure.

Given the multitude of bugs in various UEFI impls so far, I would say that
this is a fairly legitimate concern. Especially as I'm assuming most people
like you or I are likely to just disable SecureBoot altogether and never
properly "test out" enrollment.

~~~
AnIrishDuck
> Even every single Linux user I know has bought a laptop and fired it up at
> least once before subverting the boot process to install Ubuntu right off
> the bat.

Now imagine there's an option in the UEFI BIOS:

* Revert to trust-on-boot mode. WARNING: this may expose you to attacks by malware.

~~~
drivebyacct2
Again, how is this any different than just letting the user enroll a key? Or
using one signed by a supported key, or using one with a shimloader already
ready to go?

I mean, I guess as a convenience mechanism, but then again, why not just
disable it and be done with it. Maybe a chance that would make more sense to
me would be to have an option:

* Extract SecureBoot keys from bootloader/kernel whatever

and be able to specify your own kernel or what not.

But then again, that's basically what you get via your own key enrollment ;)

------
betterunix
Compliance with proprietary vendors' requirements? No thanks, I do not want
Microsoft, Apple, Sony, or anyone else deciding how I use my computer. Shame
that the _Linux foundation_ cannot understand _the most basic tenet of free
software_.

------
urza
The coming civil war over general purpose computing
<https://news.ycombinator.com/item?id=4436139>

~~~
bitcracker
For this simple reason the Linux Foundation should stop wasting further energy
for UEFI. As a Linux user from the very beginning (since 1992) I won't buy any
UEFI device for Linux in general even if Linux would be 100% supported. I
won't buy an expensive WinRT tablet just to put Linux on it.

When the Linux Foundation was founded I was happy to have a strong
organization behind Linux. But today they make me really angry for supporting
a system of someone who considered Linux, and the Open Source movement in
general, as enemy. UEFI proves that they don't have changed their mind.

LF, please stop your unrealistic UEFI dreams, and please focus on the
interests of the Linux community. I believe that most Linux users want
functional hardware alternatives which will likely remain free from DRM
restrictions. I would appreciate that even at the cost of incompatibility with
the internet. In that case we would have to build our own new Internet, free
from spam etc.

There are so many good devices like Raspberry and Beagleboard Black. They are
powerful enough to be used as a desktop workstation when using a small and
efficient Linux distro. Why not even enhance them with an e-ink display to
make them a cheap alternative tablet pc that everyone can afford?

By the way, for the price of a single UEFI WinRT tablet we could build a whole
server cluster of RPis or BBB.

------
bitwize
You're fighting an uphill fucking battle, Linux Foundation and here's why:
UEFI, the standard, is so loosey-goosey, with so many bits unspecified, that
the only real test of whether the system is compliant that actually matters is
"does it boot Windows". It's rather like the Web back in the day, when we had
HTML and CSS and all of that but the only standard that people applied was
"does it look nice and work in IE5". We've already seen one UEFI
implementation from Samsung that can brick the machine when a non-Microsoft
(or even sometimes a Microsoft) OS is installed on it; and one from Lenovo
that actually searches the strings of the boot image looking for either
"Windows" or "Red Hat Linux" and refuses to boot otherwise. Expect more cock-
ups of this sort, whether due to malice or incompetence, to follow. This isn't
about a hardware-verifiable boot process, it's about multiple vendor-specific
boot processes, the only thing they can be guaranteed to have in common is
their capability to boot into a Microsoft OS. Those of us disinclined to trust
Microsoft will see this as a largely successful attempt to decommoditize the
boot protocol, as per the Halloween Documents.

------
hexonexxon
Theo de raadt already blasted Redhat and Ubuntu for instantly compromising and
submitting to microsoft. Linux foundation non resistance makes no sense to me
either since a lot of people who sit on the board are direct competitors to M$
you'd think they would want to save their companies from being at their mercy.

I'm waiting for when cloud o/s takes over that scans for pirate
software/dissident behaviour or thought crime, and it becomes illegal to run
your own operating system. There will be a Silk Road for computer hardware and
guy's peddling BSD installs in dark alleys.

~~~
takluyver
What should they have done? As I see it, they had three options with secure
boot: find ways to work with it (as they have), try to get OEMs to disable
secure boot or ship with a 'Linux key' as well, or ignore it and let users who
want to install Linux deal with it.

Making users disable secure boot makes it that much harder and scarier to try
Linux, so there would be even fewer users in the future. And I see no evidence
that OEMs care enough about Linux to go out of their way to make life easier,
even if someone did produce a 'Linux key' to sign all the major distributions.
There are a precious few small OEMs that sell computers with Linux, but mostly
to existing Linux users. If desktop Linux isn't going to fade into complete
irrelevance, we're still crucially dependent on people experimenting with it
on Dell/Lenovo/Acer Windows laptops.

------
jagermo
Link is mentioned in this debate:
<https://news.ycombinator.com/item?id=5658184>

------
guilloche
No, this is not what I want, the secure boot is MS's evil plan and I want to
get rid of the whole shit.

------
NelsonMinar
This PDF carries a date of October 2011.

~~~
drivebyacct2
And as most people hopefully know, despite the random FUD here and on reddit,
SecureBoot is simply not an issue for x86 computers. The only issues so far
with Linux + SecureBoot were actually due to OEM bugs in the UEFI
implementation. Ubuntu and Fedora both handle SecureBoot seamlessly. Other
distros will follow, especially with the Linux Foundation finally releasing
their shim loader late last year.

