[personal profile] mjg59
There's been good progress in Fedora's implementation of UEFI Secure Boot, so time for a quick update.

Boot process signing

The infrastructure for signing the bootloader binaries is now implemented. pesign is in the archive and being used to sign shim, grub2 and the kernel. At the moment they're all being signed by test keys, and the private key is actually in the pesign package. This is, obviously, not intended for production use - it's just to ensure that we can build correctly signed images. We've proof-of-concepted signing via cryptographic hardware and will shortly be deploying new build systems dedicated to building the signed binaries. These won't be general access systems and will have a lightly modified mock configuration to ensure that the crypto hardware is available to the build chroots, but otherwise there's nothing special about them.

As far as signing with the Microsoft keys goes, we're in the final round of legal review of the appropriate agreements and will be migrating to a version of shim signed with their key in the near future.

Kernel modifications

There's two main sets of patches for the kernel. The first is to automatically enable the locking down of various bits of functionality when secure boot is enabled, in order to prevent users (including root) from being able to modify the kernel at runtime. They've just been posted upstream and haven't been dreadfully received, though we'll probably be changing the name of the capability. The main thing that users will notice is that any X drivers that still need direct hardware access (which, on secure boot systems, should be zero - we've implemented native kernel drivers for all the hardware we expect to see there) will fail to work, as will setpci. The plan is for kexec to require that kernel images be signed, but that's requiring rather more reworking of kexec than expected so for now kexec will just be disabled.

The other lump of kernel functionality is the support for module signatures. That had been somewhat blocked based on a lack of consensus between patch authors and upstream, but an agreement got hammered out at Kernel Summit last week and so we should see progress there shortly. Right now we're still looking at modules being signed with a throwaway key, but the plan is still for keys in db (and MOK, if using the Suse approach) to be imported into the kernel keyring and used. That's dependent upon that code being written in time, though. It's definitely still a goal for F18.

Key management

We're planning on using Suse's approach of permitting local key management at the shim level, and I spent some time discussing this with Vojtech last week. In combination with the above, this should provide a workable mechanism for permitting the end-user to install module signing keys.

General UEFI support improvements

We've added support to grub to use the kernel's built-in UEFI setup functionality, although there's still some discussion with upstream to ensure that it's implemented in an acceptable way. This approach also makes it easy for us to obtain PCI ROMs via UEFI, which improves radeon support on a bunch of Macs. Finally, we've been hammering on some remaining UEFI bugs and are definitely at the point where the machines that don't work are surprising and the ones that do are the tedious expectation. This is far better than any previous release.


Still has to be written, and that's probably where much of the my next month is going.


Fedora 18 is still on track to have full UEFI Secure Boot support out of the box, and the Beta should be fully signed although perhaps still with our test keys.

For those of you who get sent to surprisingly expensive conferences, I'll be discussing some of this as part of a presentation on improving Linux support for UEFI at the Intel Developer Forum in San Francisco next Tuesday morning. Feel free to say hi if you're in the area.

Thank you

Date: 2012-09-05 07:10 am (UTC)
From: (Anonymous)
Thank you for all the hard work. Do those features make it into TC5?
I'm keen to try them out on my MBP 8,2.

The video BIOS is the only major problem for me.


Date: 2012-09-05 07:58 pm (UTC)
From: (Anonymous)
Sounds promising, how would I get a hold of this source? So I can test it against my motherboard (http://unix.stackexchange.com/questions/45312/how-can-i-tell-if-i-have-a-bug-with-my-kernel-or-with-my-uefi-firmware) in your "surprising" category that dosen't seem to like UEFI and linux?

Re: Source

Date: 2012-09-06 07:36 am (UTC)
From: (Anonymous)
No luck :( Thanks anyway though!

the 07/11 thread is...

Date: 2012-09-05 09:57 pm (UTC)
From: (Anonymous)

...pure, unadulterated LKML.

EFI policy should not be the justification for kernel implementation details
  1. sure it is (https://lkml.org/lkml/2012/9/4/388) -- another example could be the ACPI mess
  2. it's about a chain of trust that hasn't existed before, of course it's going to be pervasive

Date: 2012-09-07 11:46 am (UTC)
From: (Anonymous)
If I have a small shim which can boot an unsigned kernel (like Ubuntu), then will the functionality still get disabled?

Date: 2012-09-17 04:15 pm (UTC)
From: (Anonymous)
If I disable UEFI secure boot, will I lose any functionality? I just hate the idea of signing the whole kernel stack.

And why doesn't MS get sued for requiring secure boot?

Microsoft Lawsuit

Date: 2012-09-19 08:02 pm (UTC)
From: (Anonymous)
I agree 100%, shouldn't Microsoft get sued? I've tried to persuade OEMs from a consumer point of view by emailing them or online chatting with them on the issue and the overwhelming response I get from them is that this Secure Boot implementation is something that has been mandated by Microsoft. Not one single person I've contacted (from Dell, HP, Asus, etc) has apparently been told that the option to enable Secure Boot has been left up to their respective companies in order to carry the Windows 8 certification; instead they have all told me that Micro$oft is making them enable Secure Boot on all of their new PCs, period. This definitely seems to me like definite grounds for lawsuit, even though the fine print apparently shows otherwise. In other words, I don't think OEMs are being given the choice, but rather an ultimatum from Microsoft.


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags