This process will prevent uncertified software from booting. This may have benefits although I can't see them.
You have a new security mechanism to control what can and what can not boot from your hardware. A security feature. You don't feel like you need it until it's too late. But I digress.
I have read a thread on Linux mailing list where a Red hat employee asks Linus Torvalds to pull a changeset which implements facility to parse PE binaries and take a complex set of actions to let kernel boot in Secure Boot mode (as far as I can understand).
Drivers, like your GPU firmware, have to be signed in line with Secure Boot, otherwise it can be yet another rootkit. The status quo is that those drivers are signed in PE format. The kernel can boot without those anyway, but hardware won't work. Parsing PE format in kernel is just a technically simpler choice for this than asking every hardware vendor to sign their blobs for each distro, or setting up a userspace framework to do this. Linus decides not to suck Microsoft's dick. That's not a technical argument.
What benefits will I gain with UEFI and Secure Boot, as a home user?
The most visible feature is UEFI fast boot. I've got my hands on several Windows 8 logo desktops and they boot so fast that I often miss to pop up the boot menu. Intel and OEMs have got quite some engineering on this.
If you're the type of linux users who hate bloatedness and code duplication with a passion, you may also want to manage multiboot at firmware level and get rid of bootloaders altogether. UEFI provides a boot manager with which you can boot directly into kernel or choose to boot other OS' with firmware menu. Though it may need some tinkering.
Also, fancier graphics during boot time and in firmware menu. Better security during boot (Secure Boot). Other features (IPv4/6 netboot, 2TB+ boot devices, etc.) are mostly intended for enterprise users.
Anyway, as Linus said, BIOS/UEFI is supposed to "just load the OS and get the hell out of there", and UEFI certainly appears so for home users with fast boot. It certainly does more stuff than BIOS under the hood but if we're talking about home users, they won't care about that.
How is this signing done?
Theoretically, a binary is encrypted with a private key to produce a signature. Then the signature can be verified with the public key to prove the binary is signed by the owner of the private key, then the binary verified. See more on Wikipedia.
Technically, only the hash of the binary is signed, and the signature is embedded in the binary with PE format and additional format twiddling.
Procedurally, the public key is stored in your firmware by your OEM, and it's from Microsoft. You have two choices:
- Generate your own key pair and manage them securely, install your own public key to the firmware, and sign the binary with your own private key (sbsign from Ubuntu, or pesign from Fedora), or
- Send your binary to Microsoft and let them sign it.
Who can obtain signatures/certificates? Is it paid? Can it be public? (It should be available in the source code of Linux, doesn't it?)
As signatures/certificates are embedded in binaries, all users are expected to obtain them. Anyone can set up their own CA and generate a certificate for themselves. But if you want Microsoft to generate a certificate for you, you have to go through Verisign to verify your identity. The process costs $99. The public key is in firmware. The private key is in Microsoft's safe. The certificate is in the signed binary. No source code involved.
Is Microsoft the only authority to provide signatures? Shouldn't there be an independent foundation to provide them?
The technical side is rather trivial, compared to the process of managing PKI, verifying identity, coordinating with every known OEM and hardware vendor. This costs a dear. Microsoft happens to have infrastructure (WHQL) and experience for this for years. So they offer to sign binaries. Anyone independent foundation can step up to offer the same thing, but none has done it so far.
From a UEFI session at IDF 2013, I see Canonical has also begun putting their own key to some tablet firmware. So Canonical can sign their own binaries without going through Microsoft. But they're unlikely to sign binaries for you because they don't know who you are.
How will this impact open source and free kernels, hobbyist/academic kernel developers etc.
Your custom built kernel won't boot under Secure Boot, because it's not signed. You can turn it off though.
The trust model of Secure Boot locks down some aspects of the kernel. Like you can't destroy your kernel by writing to /dev/kmem even if you're root now. You can't hibernate to disk (being worked upstream) because there is no way to ensure the kernel image is not changed to a bootkit when resuming. You can't dump the core when your kernel panics, because the mechanism of kdump (kexec) can be used to boot a bootkit (also being worked upstream). These are controversial and not accepted by Linus into mainline kernel, but some distros (Fedora, RHEL, Ubuntu, openSUSE, SUSE) ship with their own Secure Boot patches anyway.
Personally the module signing required for building a Secure Boot kernel costs 10 minutes while actual compilation only takes 5 minutes. If I turn off module signing and turn on ccache, kernel building only takes one minute.
UEFI is a completely different boot path from BIOS. All BIOS boot code won't be called by UEFI firmware.
A Spanish Linux user group called Hispalinux has filed a complaint against Microsoft on this subject to Europan Comission.
As said above, no one except Microsoft has stepped up to do the public service. There is currently no evidence of Microsoft's intent of doing any evil with this, but there is also nothing to prevent Microsoft from abusing its de facto monopoly and going on a power trip. So while FSF and Linux user groups might not look quite pragmatic and have not actually sit down to solve problems constructively, it's quite necessary people put pressure on Microsoft and warn it about the repercussions.
Should I be concerned? I reject to use neither proprietary software nor software signed by trusted companies. I have done so till now, and I want to continue so.
Reasons to embrace Secure Boot:
- It eliminates a real security attack vector.
- It is a technical mechanism to give user more freedom to control their hardware.
- Linux users need to understand Secure Boot mechanism and act proactively before Microsoft gets too far on monopoly of Secure Boot policy.