Implementing UEFI Secure Boot in Fedora
mjg59.dreamwidth.org
mjg59.dreamwidth.org
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.
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!".
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.]
Even with UEFI, this doesn't have to be a problem.
It's happening. It's just not on _your_ laptop, but it could be. Try it out.
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)
Also, as far as I can tell a user (or an OEM) can just go into their UEFI settings and turn off secure boot, then install and boot completely unsigned anything.
This doesn't seem like the end of the world to me.
That's besides the point. It's that Microsoft - a software vendor - is suddenly the authority over distributing and signing keys for what amounts to a hardware lock mechanism that prevents you from doing whatever the fuck you want with your computer, all in the name of a false pretext of security. This is insanity.
>Also, as far as I can tell a user (or an OEM) can just go into their UEFI settings and turn off secure boot, then install and boot completely unsigned anything.
The problem is with what you've conveniently placed into parentheses - if the OEM decides to not give you the ability to turn it off, you're fucked. A hardware vendor should not have the ability to tell me what the fuck I can run off it. I'll admit that this is getting into slippery slope territory, but I can see a lot of OEMs using this "feature" because, hey, it worked for Apple - it can't be that bad⸮
It worked for Apple on iOS devices. Macs are fully open, despite having TPM devices and a potential trusted boot chain for some time.
How is it false? Rootkits are a real danger, because they can be undetectable by any antivirus you can run. It's funny because many of same people attacking Microsoft here turn around and claim that Microsoft software is insecure and recommend you switch to OS X/Linux!
>if the OEM decides to not give you the ability to turn it off, you're fucked
In order to qualify for the Windows Logo, OEMs are REQUIRED by Microsoft to give the user the ability to turn it off or add their own keys. As such, UEFI software will have this feature anyway, so I seriously doubt any OEM would not do that, since they aren't saving anything and only the tech savvy will mess with the settings anyway.
On x86, for now.
Don't forget that the exact opposite is required on ARM. And there's no reason why Microsoft can't change the requirements for Windows 9 (when it will be harder to do something about the situation because Microsoft's keys will be widely used).
Right, and there's no reason why Microsoft can't suddenly start eating babies as a matter of corporate policy next year. This is just FUD.
More to the point, Microsoft doesn't have a current policy about eating babies with ARM CPUs. They do have a current policy about locking the bootloaders of ARM devices.
First of all, the requirements are only recommendations in order for the OEMs to slap a Windows sticker on it. They can't require or not require anything of the OEMs, because they're legally barred from doing so.
They could do anything for Windows 9, if they last that long in the Post-PC era. It's a moot point.
And ARM is a red herring, it's a totally new platform and MS could be subsidizing the hardware and/or OS license fees in exchange for App Store revenue (like Kindle Fire), so they lose out if the user swaps the OS. Why is ARM such a big issue when there are about 200 different kinds of Android ARM tablets out there that you can install Ubuntu on?
Some people are interested in dual-booting Windows and "something else" (Android, Ubuntu, ...) on ARM devices. Historically, dual-booting has an important source of Linux users. Microsoft's current policies for ARM prevent that (absent bootloader hacks, of course).
Beyond that, if subsidies are really the underlying issue, why not permit customers to "buy off" the bootloader lock (i.e. pay to get permission to install their own keys as well)? Or at least move to that policy after the initial uproar?
I think that the reason is that there are more than subsidies at stake here. I think the simplest explanation is that Microsoft wants to establish different default expectations for the "Post-PC era".
And not all rootkits modify the kernel image. And if there is a bug in the bootloader (and there is always a bug in the bootloader), you're back to square one anyhow.
So its those guys you need to chase after with the pitch-forks ;-)
>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.
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.
If this was really about security, MS would focus on fixing their sandboxing. This is about locking people into their software once they buy the machine. You can't install another system by using something like wubi anymore - now you have to know how to disable secure boot or get new keys into it.
This is probably a foot in the door towards more cumbersome and restrictive measures on servers, where security matters much more and where the big money is.
If this isn't defined as monopoly-abuse, I don't know what is.
Note this part:
>While Microsoft have modified their original position and all x86 Windows machines will be required to have a firmware option to disable this or to permit users to enrol their own keys, it's not really an option to force all our users to play with hard to find firmware settings before they can run Fedora
Two things can be picked from that quote:
1) If you don't want to trust MS, then put in your own keys.
2) Fedora got their bootloader signed for convenience, not because it would be required.
Microsoft updated the requirements to say that OEMs must provide, on x86, a way to disable it or allow users to install their own keys.
It is a sad sad day.
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.
"[...] 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."