
Implementing UEFI Secure Boot in Fedora - Garbage
http://mjg59.dreamwidth.org/12368.html
======
rwmj
So Microsoft will sign just about any bootloader for a one-off fee of $99?
What's to stop me setting up a legit-looking company, writing a fake
bootloader, getting it signed, then adding malware to Windows? If the key is
blacklisted, I'll just sign up for another one.

The whole idea of secure booting on hardware that you don't physically control
is ridiculous anyway. You're trusting _everything_ in that chain of software,
from the bootloader, through the OS, through to every ring 0 driver, to not
contain any exploitable bug. We know how well that worked out, just look at
consoles & Android.

Microsoft aren't stupid. They know this isn't going to provide real security.
I think the intention is (a) prevent people easily repurposing machines to run
Linux, (b) provide a sop to Big Content, (c) set expectations that you don't
own the hardware you bought.

~~~
tzs
> I think the intention is (a) prevent people easily repurposing machines to
> run Linux

Serious question: are there really many people who

• know enough to take a Windows machine, obtain a Linux boot CD or boot USB
drive, do whatever voodoo is required to make the computer boot from that
instead of from the hard disk, and then go through the Linux install,

but who cannot easily

• figure out how to invoke the BIOS settings menu and change the secure boot
option from "enabled" to "disabled"

?

I understand that Linux is getting friendlier to non-techies, and many people
report success in getting Grandma using Linux, but in almost all of these
stories they installed Linux for Grandma. They did not just toss her a CD and
say "try this!".

~~~
rwmj
It's an extra step in the process. Plus if you're dual booting, you have to
switch the BIOS back and forth every time you switch between "secure" Windows
8 and Linux.

------
sounds
I've never thought UEFI Secure Boot was a great idea, but Fedora paying
Microsoft to get a signed boot loader feels, errrm, creepy to me.

On the bright side however, Fedora's boot loader is just a signature verifying
loader to boot grub2 - using _Fedora's_ PKI. That's encouraging because at an
ideological level it's exploiting Microsoft's process to give Fedora control
over everything downstream from their loader. The name even implies that it's
a kind of workaround: "shim loader." (Shim is defined in some circles as a
compatibility workaround.)

I guess Fedora doesn't plan on becoming a signing authority for custom
kernels, but in a pinch it could work.

Please, everyone start contributing to <http://coreboot.org> !

[Edited for clarity.]

~~~
lucian1900
As long as OEMs only listen to MS, coreboot will never happen.

Even with UEFI, this doesn't have to be a problem.

~~~
sounds
Unless I misunderstand what you mean by "will never happen," I think you
should take a second look at coreboot.

It's happening. It's just not on _your_ laptop, but it could be. Try it out.

------
saulrh

      Microsoft will be offering signing services through their
      sysdev portal. It's not entirely free (there's a one-off
      $99 fee to gain access)
    

In other words, Microsoft won. Not only have they made Linux significantly
more difficult to develop and use, they have managed to actually _extract
money_ from open-source developers. This is why MS has such a bad reputation.

~~~
recoiledsnake
Why don't you come up with a solution to avoid boot time undetectable rootkits
instead of railing against big bad MS?

>they have managed to actually extract money from open-source developers

Yes, I am sure Microsoft is laughing all the way to the bank with the $99 that
RedHat is going to pay them. I doubt that program will even cover its cost to
MS.

~~~
nitrogen
Do it the same, but place certificate signing under the control of a neutral
party, and mandate that OEMS allow users to load their own certificates into
their own UEFI, possibly with a self-signing process that allows that
motherboard, and only that motherboard, to boot a given user-signed image,
with self-signing only possible from within the UEFI UI, so OS-level malware
can't generate valid certificates.

~~~
recoiledsnake
>mandate that OEMS allow users to load their own certificates into their own
UEFI, possibly with a self-signing process that allows that motherboard, and
only that motherboard, to boot a given user-signed image, with self-signing
only possible from within the UEFI UI, so OS-level malware can't generate
valid certificates.

Do you realize that Microsoft has done exactly that? There's so much hot air
here that facts are getting lost in the blind raging and hating.

Of course, they cannot dictate to OEMs because of the antitrust lawsuits, but
it's a requirement if they want the PC to be Windows Certified and carry the
Windows sticker.

~~~
InclinedPlane
I'm not a fan of the way secure boot has been playing out, but I don't see any
evidence of MS villainy in it. It's crazy how much irrational ill-will is
stored out there against anything MS does.

~~~
fpgeek
I'd say plenty of the ill-will isn't irrational. Microsoft did spend roughly
two decades or so earning it, after all.

------
dhx
Matthew’s earlier article “Why UEFI secure boot is difficult for Linux” is
worth reading:

<http://mjg59.dreamwidth.org/9844.html>

------
josteink
Why does a computer (a physical general computation device) need, require or
trust keys from Microsoft (one singular software vendor) in the first place?

If this isn't defined as monopoly-abuse, I don't know what is.

~~~
apetrovic
Just build a computer, a physical general computation device, with a
motherboard that doesn't have Windows sticker on the box (the shiny thing
issued by Microsoft) and you should be fine.

~~~
josteink
While that is a valid solution to the problem, it is also tippy-toing around
why the problem is there in the first place. And that is what I was curious
about.

------
gioele
> Our first stage bootloader will be signed with a Microsoft key.

It is a sad sad day.

------
zurn
Anyone know what kind of key revocation mechanisms Microsoft have in place?

~~~
yungchin
See <http://ozlabs.org/docs/uefi-secure-boot-impact-on-linux.pdf> section 2.3:
"This is known in the UEFI specification as the “forbidden signatures
database”, and is modifiable during execution by authenticated software."

------
rcthompson
What if you bought a new house and the bank you bought it from told you that
they would be keeping your house keys and not giving you a copy?

It's not the most accurate analogy, but the point is that UEFI puts a lock on
the boot process, which is itself arguably a good thing, but then Microsoft
and others are trying to control the keys that rightfully belong to the owner
of the hardware. Or more simply, locks are not bad per se, but if you aren't
allowed to have the key to a lock that you supposedly own, then that's bad.

------
conductor
I wonder, once every piece of motherboards are shipped with MS key, how much
CPU time would be needed to factor the private key and sign anything? Some
distributed piece of software running on thousands of anonymous machines
should solve the problem in weeks I think, or not?

~~~
zurn
A SSL cert vendor has a popularized writeup for 2048-bit RSA (which UEFI uses
according to
[http://www.uefi.org/learning_center/UEFI_Plugfest_2012Q1_v3_...](http://www.uefi.org/learning_center/UEFI_Plugfest_2012Q1_v3_AMI.pdf))
at <http://www.digicert.com/TimeTravel/math.htm>:

"[...] It is therefore estimated, that standard desktop computing power would
take 4,294,967,296 x 1.5 million years to break a DigiCert 2048-bit SSL
certificate. Or, in other words, a little over 6.4 quadrillion years."

