Handling UEFI Secure Boot in smaller distributions

[mjg59]

The plan for supporting UEFI Secure Boot in Fedora is still pretty much as originally planned, but it's dependent upon building a binary which has the Fedora key embedded, and then getting that binary signed by Microsoft. Easy enough for us to do, but not necessarily practical for smaller distributions. There's a few possible solutions for them.

• Require that Secure Boot be disabled
  
  Not ideal. The UI for doing this is going to vary significantly between machines, making it difficult to document. It also means that the security benefits of Secure Boot are lost.
  
  
• Require that the machine be placed in Setup Mode
  
  Clearing the enrolled Platform Key results in the system transitioning into Setup Mode, and from then on new keys can be enrolled into the key database until a new Platform Key is enrolled. Distributions could ship an unsigned bootloader that then writes the distribution keys into the database - James Bottomley has an example here. This means that the distribution can still benefit from Secure Boot, but otherwise has the same downside that the UI for doing this will vary between machines.
  
  
• Ship with a signed bootloader that can add keys to its own database
  
  This is more interesting. Suse's bootloader design involves the bootloader having its own key database, distinct from those provided by the UEFI specification. The bootloader will execute any second stage bootloaders signed with a key in that database. Since the bootloader is in charge of its own key enrolment, the bootloader is free to impose its own policy - including enrolling new keys off a filesystem.

I've taken Suse's code for key management and merged it into my own shim tree with a few changes. The significant difference is a second stage bootloader signed with an untrusted key will cause a UI to appear, rather than simply refusing to boot. This will permit the user to then navigate the available filesystems, choose a key and indicate that they want to enrol it. From then on, the bootloader will trust binaries signed with that key.

Distributions are then able to take an existing signed copy of shim and put it on their install media, along with a file containing their key. If a user attempts to boot then the boot will fail because the second stage bootloader isn't signed with a trusted key, but the user can then use the navigator and select the distribution's key file. After providing confirmation and rebooting, the second stage bootloader's signature will now be recognised and the installer will boot.

This has the advantage over the first two options that the UI is consistent, making it easier to document the install process. The primary disadvantage is that the distribution won't be able to rebuild shim and will have to ship a pre-compiled binary. This may well be unacceptable to distributions like Debian, but should still provide a viable approach for other distributions who are either unwilling or unable to deal with Microsoft themselves.

Comments

Remove Microsoft/other keys from shim?

[(Anonymous)]

Is it possible for the shim layer to remove Microsoft's or other keys? That would be nice for those of us who view Windows as malware.

Re: Remove Microsoft/other keys from shim?

[mjg59]

Unfortunately not - the only way to remove keys from kek and db is via the firmware UI

Re: Remove Microsoft/other keys from shim?

[http://apebox.org/wordpress/]

Remember that device firmware (e.g. your video card's BIOS) must also be signed by a valid key with Secure Boot. And that is going to be Microsoft's key in every practical case. So purging Microsoft's key means losing hardware support, unless you turn off Secure Boot.

There is still a fundamental problem here!

[(Anonymous)]

However you workaround this there remains a fundamental problem and that is "How has the situation been allowed to arise that Microsoft is the single signing authority for Securely-booted systems?".

If there is no way for a user to disable Secure Boot then they are entirely at the mercy of Microsoft in even being able to start their computers. This is monopolistic practice at its worst and should be fought strongly.

Re: There is still a fundamental problem here!

[(Anonymous)]

"How has the situation been allowed to arise that Microsoft is the single signing authority for Securely-booted systems?"

The answer is very simple: no-one else wants to do it. Microsoft has done nothing to stop anyone else acting as a signing authority. No-one else has expressed any interest in being one. Or at least, not a public one. I guess Apple might implement SB and self-sign their own stuff. Who knows, they're Apple.

Thanks

[(Anonymous)]

Thank you for this, as one of the smaller distribution builders I want you to know that we really appreciate the time you have spent considering us.

-Andrew, Fuduntu

UEFI secure boot won't work

[(Anonymous)]

Debian user reporting. I think UEFI secure boot won't work in the long run. Soon, malware writers will find a way around it, and it will just hurt legimate users wanting to use Linux, similar to ISPs blocking servers just because it was used to send spam, even when I want to run a server from home.

And should the Linux community build an completely open source computer, without restrictions like these?

Re: UEFI secure boot won't work

[mjg59]

Soon, malware writers will find a way around it

Citation needed.

[(Anonymous)]

What about signed bootloader that generates hash like graphical image plus text, next to kernel/bootloader name, to help user identify changes? To me it looks much more userful.

[damerell]

SuSE's shim sounds like the least worst option.

[(Anonymous)]

But secure boot is still a bad technology.

Why?

[(Anonymous)]

I mean: why didn't you say or do that earlier?

This is great news for Very Small Or Even Ultimately Tiny Distributions. If I can also load Nvidia drivers I will stop bitching about secure boot.

I'll start again if Microsoft won't sign, it will blacklist it immediately, firmware will include some unexpected stuff...

What about revokation?

[(Anonymous)]

I'm afraid that a first-stage bootloader capable of loading whatever it fits appropiate by its own keyring will be deemed inappropiate by Microsoft policy and have ultimately its signature revoked.

Re: What about revokation?

[mjg59]

This is equivalent to the firmware UI that Microsoft require be present. Unless someone actually figures out a way to compromise systems using it there should be no risk of revocation.

[(Anonymous)]

Why don't all the major Linux vendors sue Microsoft for secure boot? It's probably anti-competitive behavior.

[mjg59]

Because if it's not actually anti-competitive behaviour, there's no legal case.

Status of SuSE's plan

[(Anonymous)]

So what's the status on Microsoft's approval of SuSE's plan? Presumably we're waiting on them to say "yes, we'll sign the shim", but I can't find any information on it.

[(Anonymous)]

Is it such a big deal? Pay 99$ to MS, sign your bootloader and all problems solved. 99$ per year is not a big load of money even for small distributions.

[(Anonymous)]

It's a $99 one time fee.
Apple charges $99 to allow developers put their iPhone apps in the app store. Small developers have a problem with this fee.

MS's $99 way already available?

[(Anonymous)]

Hi, The only one way I found is the MS's sysdev (HW) website to sign it, but there should be another way or website. Is there a official way to contact with MS for "$99 sign"?

Rebuilding the shim

[patscomputerservices.myopenid.com]

In the article, you say that the major disadvantage is that the shim cannot be rebuilt. Is that because you have to pre-sign the shim with all keys, so the first stage bootloader will accept it?

Also, would the distributor have to create keys for all versions of their distro? For example (using Ubuntu since they have multiple "distros"), would Canonical have to create a key for "Ubuntu", a key for "Kubuntu", a key for "Edubuntu", a key for "Lubuntu", and a key for "Xubuntu"? Or would the one key cover all binaries--as they are all based on the same foundation?

Have a great day:)
Patrick.

Re: Rebuilding the shim

[mjg59]

Right, the shim has the keys built in and then has to be signed by Microsoft - if you rebuild it then you'd need to get it signed again.

You'd need one key per bootloader or kernel signing key. If all the Ubuntu derivatives used the same bootloader and kernel then they can all use the same key.

[(Anonymous)]

> Clearing the enrolled Platform Key results in the system transitioning into Setup Mode, and from then on new keys can be enrolled into the key database until a new Platform Key is enrolled.

Is this actually the case? OVMF does not require clearing the PK before enrolling KEK/DB certificates and keys. See Secure Boot instructions (http://dee.su/liberte-install) for Liberté Linux.

[mjg59]

PK has to be cleared if you want to do it programmatically.

Acceptability to distributions like Debian

[(Anonymous)]

Debian ships some binaries it does not rebuild, for example in the firmware-free package. As long as the code satisfies their free software guidelines, I suspect they'd be able to ship shim.

Which licenze do you use for shim?

[(Anonymous)]

Hello which licence are you use for shim?
I can find this information on this site.
Thank you for information!

Re: Which licenze do you use for shim?

[mjg59]

It's two-clause BSD.