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.
Best Answer
I would rather describe the boot process as:
1.) Apply power, start executing Secure Boot-capable UEFI firmware
2.) Firmware checks any potential bootloaders against Secure Boot key sets, which are stored in system NVRAM (or compiled-in defaults).
3.) The bootloader is supposed to check the OS kernel in the same way.
4.) In order to be Secure Boot-compliant and meaningfully effective, Linux kernel should also cryptographically check any kernel modules loaded.
Modern kernels include an optional feature for point 4): enterprise distributions' kernels like RedHat enable it automatically when booting on a Secure Boot-capable system. Custom kernels can be provided with a signing key at compilation time.
For RedHat kernels, at runtime, the list of allowed keys is (the key used to sign the main kernel) + (whatever is in the Secure Boot
db
key set) + (allowed keys in theMOK
set used byshim.efi
, if it exists).So if you use Secure Boot and plan to use third-party kernel modules with distribution kernels, you'll need to sign them and get the signing key on the allowed list. But if you roll your own kernels and/or have taken control of your Secure Boot keys, your Secure Boot private key can be used for signing the third-party modules too.
In order for you to be able to take control of Secure Boot, your system needs to allow you to modify Secure Boot keys. There are four (sets of) keys you're interested in:
db
, the set of public certificates of allowed bootloaders and/or SHA256 checksums of allowed bootloadersdbx
the set of public certificates and/or checksums of explicitly blacklisted bootloaders.KEK
, the set of public certificates that are used to validate any signed updates todb
PK
the one and only Primary Key (certificate) that is used to validate signed updates toKEK
.By default, the system should have hardware manufacturer's PK, and both Microsoft's and hardware manufacturer's keys in
KEK
anddb
. This allows the use of Microsoft-certified bootloaders (which includes the "shim" used with some Linuxes) and hardware manufacturer's firmware update tools out-of-the-box.The first step would be examining your UEFI BIOS Setup settings very carefully. On some systems, the Setup allows both adding and deleting of all Secure Boot keys. On other systems, the only options are resetting back to the factory default keys, and clearing all keys. If your Setup requires clearing all keys in order to be able to use custom keys, then you might want to backup any existing keys first, so that you can selectively restore them if you wish.
According to the Secure Boot specification, if the
PK
is cleared, Secure Boot will be in so-called Setup Mode, which allows free editing of all key sets and unrestricted booting. So, ideally, you want to just remove thePK
but leave the other keys as-is for now.Best case, this allows editing of Secure Boot keys from within a UEFI-aware OS using appropriate tools; worst case, you need to use the UEFI Shell and the
keytool.efi
utility from James Bottomley's efitools package.Your end goal should probably be something like this:
db
set should contain:KEK
set should contain:db
anddbx
db
and/ordbx
and those updates won't install successfully if access to Secure Boot is deniedPK
to make Secure Boot effective again.