I'm planning to buy a new laptop in the coming days, and I'm quite impressed with new, cool Ultrabooks. As a long-time GNU/Linux user, I'll of course install a distro of my choice on it.
Chances are I'll have to buy a computer with Windows 8 pre-installed; and chances are it will run UEFI and have "secure boot", on which non-signed kernels won't boot.
UEFI is probably good, BIOS may need to retire. I guess the hairy thing is Secure Boot.
As far as I can understand, some trusted certificates will be embedded into firmware and so into the kernel etc.. If the kernel's certificate can be traced back to either one of firmware's, the kernel will boot, else UEFI will tell me off and refuse to boot. This process will prevent uncertified software from booting. This may have benefits although I can't see them.
I wonder how can an open source kernel obtain one of these keys and still be free. 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). They want to do this because Microsoft only signs PE binaries. Mr. Torvalds has kindly rejected this changeset, stating the kernel already implemets the standard, which is not PE. RedHat is trying to push this code to kernel so they won't have to fork it one day.
See, this is a complicated thing. Let me ask my questions:
- What benefits will I gain with UEFI and Secure Boot, as a home user?
- How is this signing done?
- 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?)
- Is Microsoft the only authority to provide signatures? Shouldn't there be an independent foundation to provide them?
-
How will this impact open source and free kernels, hobbyist/academic kernel developers etc.. e.g. Will this boot (a very basic boot sector code):
hang: jmp hang times 510-($-$$) db 0 db 0x55 db 0xAA
A news item at this website was the inspration of this question. A Spanish Linux user group called Hispalinux has filed a complaint against Microsoft on this subject to Europan Comission.
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. Thanks in advance.
Best Answer
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.
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.
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.
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:
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.
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.
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.
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.
Reasons to embrace Secure Boot: