Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
2  
UEFI itself isn't much of a problem, but secure boot may be. –  jordanm Mar 26 '13 at 21:15
3  
You can always UEFI boot with secure boot disabled... –  jasonwryan Mar 26 '13 at 21:45
1  
According to this article Microsoft requires vendors to prevent SecureBoot from beeing deactivated in ARM-based devices to provide license for use of Windows-8 Compatible logo. –  cadadr Mar 26 '13 at 21:48
1  
I haven't looked, but if you can't flash it onto your motherboard and things still work (each device in proper state at POST-OS handover), it doesn't much help. And then there's the graphics card firmware, for one. Hard disk firmware? Keyboard? ... This is getting closer toward discussion than requests for clarification, though. (And of course, at least that quote only claims that UEFI is a community effort; not the particular implementation.) –  Michael Kjörling Mar 26 '13 at 21:55
1  
Take a look at the Linux Foundation's document on UEFI and secure boot. –  vonbrand Mar 26 '13 at 22:29

2 Answers 2

up vote 6 down vote accepted

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:

  1. 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
  2. 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.
share|improve this answer
1  
Thank you for this detailed, awesome answer! Very comprehensive. UEFI sounds quite cool, although I have neither used nor wrote code for it. –  cadadr Apr 19 '13 at 9:27
    
Very good answer, indeed. Just two things: 1) usually there is a possibility to load your own keys into your UEFI - this way you can securely boot anything you sign yourself; 2) Secure boot is safe only to the point to which one trusts UEFI - if one uses a malicious firmware update, the chain of trust is be broken. And that is not inconceivable. –  peterph Jun 10 '13 at 22:08

I just went through this with a recent laptop purchase that came with Windows 8, and UEFI secure boot. After a lot of time and research, here is what I can answer:

  • Doesn't sound like you fit into the 'home user' category.

The benefits of UEFI the average user will notice is that the first thing they see on their screen will be the Microsoft/Vendor branded UEFI boot loader display. None of those scary things like "Press Del for Setup, F11 to select boot device", etc.

It will then transition nicely into the Microsoft kernel/boot loader wait screen. This presents a 'power to prompt' Microsoft themed experience. If that is an actual benefit is in the eye of the beholder I guess. I was pretty ticked that I didn't have the normal information I expect to see on boot. For instance, good luck if your vendor doesn't use a standard key to enter the base UEFI/Bios setup.

Oh, yeah, and the theory is that this will stop boot sector viruses, or at least make the creators create/steal someones ID and pay $99 to Verisign (the RedHat Fedora route. Google it.)

Ah, and there's the rub. Anyone can sign code with any key. The problem is that the machine will only run code that is signed by a trusted authorities key. The public half of the key is installed in the systems UEFI core at the factory, and is used to verify the signature of the UEFI programs (boot code) signed with the private key.

Guess who's public key is installed at the factory ? Guess who requires that Secure Boot be enabled by default ?

Every system manufacturer will obviously put Microsoft's key in there. They could also put in Canonical's (Ubuntu) key, Red Hat's key, Apple's key, etc. More keys though means more points for breaches, and there is obviously a physical limit to how many they could store.

And what is the solution for a rebel computer user like yourself ?

  • Hope your system vendor allows you to access the system boot configuration

  • Hope they allow you to turn off secure boot. Windows boot code will still run without secure boot.

  • If you're really lucky, the system vendor will allow you to put your own certificate authority keys in, and you can sign your own stuff. This is only really needed if you want to play around with Secure Boot.

My MSI Laptop allows me to do all of the above.

I would like to see a world where anyone can pick up a free copy of a Linux Distro and replace their OS. This is what we had before Secure Boot. We also had a lot of boot sector viruses. Having to disable secure boot in your system configuration is probably a small enough hurdle to verify you have the brain power to install an OS, or know someone who does.

Not having the ability to turn it off is the bad thing, and that is up to the Manufacturer. Don't blame Microsoft, unless they are 'convincing' the maker to prevent disabling secure boot.

share|improve this answer
    
Welcome and thanks! Very cool answer, but I'll wait a little bit more before accepting, as I want to see other peoples thoughts. –  cadadr Mar 30 '13 at 21:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.