From	David Howells <>		   
Subject	[GIT PULL] Load keys from signed PE binaries	 	   
Date	Thu, 21 Feb 2013 15:47:58 +0000	 	 

Hi Linus,

Can you pull this patchset please?

It provides a facility by which keys can be added dynamically to a kernel that
is running in secure-boot mode.  To permit a key to be loaded under such a
condition, we require that the new key be signed by a key that we already have
(and trust) - where keys that we "already have" could include those embedded in
the kernel, those in the UEFI database and those in cryptographic hardware.

Now, "keyctl add" will already handle X.509 certificates that are so signed,
but Microsoft's signing service will only sign runnable EFI PE binaries.

We could require that the user reboot into the BIOS, add the key, and then
switch back, but under some circumstances we want to be able to do this whilst
the kernel is running.

The way we have come up with to get around this is to embed an X.509
certificate containing the key in a section called ".keylist" in an EFI PE
binary and then get the binary signed by Microsoft.  The key can then be passed
to the kernel by passing the signed binary:

	keyctl padd asymmetric "" {ID of .system_keyring} < pekey.efi.signed
This command executes the following steps:

 (1) Parse the PE binary to locate the signature and the new key.

 (2) Parse the PKCS#7 message in the PE binary.

 (3) Parse the content of the PKCS#7 message which is in "Microsoft individual
     code signing form" (the mscode bits in my patches).  This contains the PE
     binary digest type and the expected resultant digest value.

 (4) Digest the signed parts of the PE binary and compare the digest obtained
     to the digest expected (obtained in step (3)).

 (5) Digest the signed parts of the PKCS#7 message (which covers the content
     data used in step (3)).

 (6) Verify the signature on the PKCS#7 message against one of the X.509
     certificates it contains.

 (7) Check the signatures on the chain of X.509 certificates in the PKCS#7
     message as far as possible.

 (8) Cross-reference the chain of X.509 certificates against the known keys the
     kernel already possesses, and if one is found, verify the signature of the
     nearest object to the PKCS#7 message that we can (or the PKCS#7 message
     itself) against the trusted key.

 (9) Pass the X.509 certificate embedded in the message to the X.509 parser to
     be turned into a key.

To make this work, step (8) requires access to the .module_sign keyring, so
this is separated from the module code to make the build dependencies simpler.
It is also renamed to .system_keyring as it can then be generic.

To make life easier whilst testing, I got rid of the "extra_certificates" file
and replaced it with a glob that just glues together all the "*.x509" files in
the source and build root directories.

Since this requires the ability to add to .system_keyring, I have had to turn
on WRITE permission for root - but so that _only_ trusted keys can be added,
I've added two more flags in key->flags:

	KEY_FLAG_TRUSTED - this key is trusted.

	KEY_FLAG_TRUSTED_ONLY - only links to trusted keys can be made to this
				keyring.

I'm not sure that this is the best mechanism by which to filter keyring
additions, but it's not currently visible to the user, and so can be changed.
One thing we might want to consider is using X.509 extension fields to contain
bitfields that indicate what is permitted of the key inside an X.509
certificate.  These contribute to the X.509 cryptographic digest and so are
secure.


What these patches then do is allow you to add new keys by signing them with a
key a user will already have.  There can be more than one source for these
keys: firstly, there is a key built into the kernel for module signing
purposes, and secondly, we have patches under development for extracting keys
from the UEFI signature database.


Note: Though we don't actually execute the PE binary container to get at the
key, the binary must be executable in the EFI environment for Microsoft to sign
it.

The test wrapper I'm using is this:

	#include <efi.h>
	#include <efilib.h>

	EFI_STATUS
	efi_main (EFI_HANDLE image_handle, EFI_SYSTEM_TABLE *systab)
	{
		InitializeLib(image_handle, systab);
		Print(L"This program contains a list of public keys.\n");
		return EFI_SUCCESS;
	}
	extern __attribute__((section(".keylist"))) const uint8_t certificate_list[];
	extern __attribute__((section(".keylist"))) const uint8_t certificate_list_end[];
	asm(".section .keylist,\"a\"\n"
	    "certificate_list:\n"
	    ".incbin \"signing_key.x509\"\n"
	    "certificate_list_end:"
	    );

and is built from pekey.c by something like this:

	CPPFLAGS := -nostdinc -I /usr/include/efi -I /usr/include/efi/x86_64

	CFLAGS := -O2 -fpic \
		-Wall -fshort-wchar -fno-strict-aliasing \
		-fno-merge-constants -mno-red-zone

	LDSCRIPT := /usr/lib64/gnuefi/elf_x86_64_efi.lds
	CRT0	:= /usr/lib64/gnuefi/crt0-efi-x86_64.o
	X509	:= magrathea
	KEY	:= /data/modsign/linux-modsign/signing_key.priv

	pekey.efi.signed: pekey.efi
		pesign -i $< -o $@ -c $(X509) -p $(KEY) -s -f

	pekey.efi: pekey.so
		objcopy \
			-j .text -j .sdata -j .data -j .dynamic -j .dynsym -j .rel \
			-j .rela -j .reloc -j .keylist --target=efi-app-x86_64 $< $@

	pekey.so: pekey.o
		$(LD) -nostdlib -T $(LDSCRIPT) -shared -Bsymbolic $(CRT0) $< -o $@ \
			-L /usr/lib64 -lefi -lgnuefi \
			-L /usr/lib/gcc/x86_64-redhat-linux/4.7.2 -lgcc

	pekey.o: pekey.c Makefile
		$(CC) $(CPPFLAGS) $(CFLAGS) -c $< -o $@

Signed-off-by: David Howells <dhowells@redhat.com>
---
The following changes since commit 406089d01562f1e2bf9f089fd7637009ebaad589:
  Merge tag 'trace-3.8-rc3-regression-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace (2013-01-14 20:22:16 -0800)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-modsign.git tags/pekey-20130221

for you to fetch changes up to 4ea349d3bb1d3521b7df8dbf0e88fe41cd3c0683:

  MODSIGN: Fix including certificate twice when the signing_key.x509 already exists (2013-02-21 14:11:40 +0000)
----------------------------------------------------------------
(from the branch description for devel-pekey local branch)
clone of "master"
signed-pefile contained key

----------------------------------------------------------------
Chun-Yi Lee (1):
      MODSIGN: Fix including certificate twice when the signing_key.x509 already exists
David Howells (27):
      KEYS: Load *.x509 files into kernel keyring
      KEYS: Separate the kernel signature checking keyring from module signing
      KEYS: Add a 'trusted' flag and a 'trusted only' flag
      KEYS: Rename public key parameter name arrays
      KEYS: Move the algorithm pointer array from x509 to public_key.c
      KEYS: Store public key algo ID in public_key struct
      KEYS: Split public_key_verify_signature() and make available
      KEYS: Store public key algo ID in public_key_signature struct
      X.509: struct x509_certificate needs struct tm declaring
      X.509: Add bits needed for PKCS#7
      X.509: Embed public_key_signature struct and create filler function
      X.509: Check the algorithm IDs obtained from parsing an X.509 certificate
      X.509: Handle certificates that lack an authorityKeyIdentifier field
      X.509: Export certificate parse and free functions
      PKCS#7: Implement a parser [RFC 2315]
      PKCS#7: Digest the data in a signed-data message
      PKCS#7: Find the right key in the PKCS#7 key list and verify the signature
      PKCS#7: Verify internal certificate chain
      PKCS#7: Find intersection between PKCS#7 message and known, trusted keys
      Provide PE binary definitions
      pefile: Parse a PE binary to find a key and a signature contained therein
      pefile: Strip the wrapper off of the cert data block
      pefile: Parse the presumed PKCS#7 content of the certificate blob
      pefile: Parse the "Microsoft individual code signing" data blob
      pefile: Digest the PE binary and compare to the PKCS#7 data
      PEFILE: Validate PKCS#7 trust chain
      PEFILE: Load the contained key if we consider the container to be validly signed

 crypto/asymmetric_keys/Kconfig                     |  20 +-
 crypto/asymmetric_keys/Makefile                    |  30 ++
 crypto/asymmetric_keys/mscode.asn1                 |  28 ++
 crypto/asymmetric_keys/mscode_parser.c             | 110 +++++
 crypto/asymmetric_keys/pefile_parser.c             | 479 +++++++++++++++++++++
 crypto/asymmetric_keys/pefile_parser.h             |  36 ++
 crypto/asymmetric_keys/pkcs7.asn1                  | 127 ++++++
 crypto/asymmetric_keys/pkcs7_parser.c              | 326 ++++++++++++++
 crypto/asymmetric_keys/pkcs7_parser.h              |  72 ++++
 crypto/asymmetric_keys/pkcs7_trust.c               | 149 +++++++
 crypto/asymmetric_keys/pkcs7_verify.c              | 260 +++++++++++
 crypto/asymmetric_keys/public_key.c                |  60 ++-
 crypto/asymmetric_keys/public_key.h                |   6 +
 crypto/asymmetric_keys/x509.asn1                   |   2 +-
 crypto/asymmetric_keys/x509_cert_parser.c          |  55 ++-
 crypto/asymmetric_keys/x509_parser.h               |  28 +-
 crypto/asymmetric_keys/x509_public_key.c           | 119 ++---
 include/crypto/public_key.h                        |   9 +-
 include/keys/system_keyring.h                      |  23 +
 include/linux/key-type.h                           |   1 +
 include/linux/key.h                                |   3 +
 include/linux/oid_registry.h                       |   7 +-
 include/linux/pe.h                                 | 448 +++++++++++++++++++
 init/Kconfig                                       |  13 +
 kernel/Makefile                                    |  47 +-
 kernel/modsign_pubkey.c                            | 104 -----
 kernel/module-internal.h                           |   2 -
 kernel/module_signing.c                            |   7 +-
 ...modsign_certificate.S => system_certificates.S} |   7 +-
 kernel/system_keyring.c                            | 103 +++++
 security/keys/key.c                                |   8 +
 security/keys/keyring.c                            |   4 +
 32 files changed, 2478 insertions(+), 215 deletions(-)
 create mode 100644 crypto/asymmetric_keys/mscode.asn1
 create mode 100644 crypto/asymmetric_keys/mscode_parser.c
 create mode 100644 crypto/asymmetric_keys/pefile_parser.c
 create mode 100644 crypto/asymmetric_keys/pefile_parser.h
 create mode 100644 crypto/asymmetric_keys/pkcs7.asn1
 create mode 100644 crypto/asymmetric_keys/pkcs7_parser.c
 create mode 100644 crypto/asymmetric_keys/pkcs7_parser.h
 create mode 100644 crypto/asymmetric_keys/pkcs7_trust.c
 create mode 100644 crypto/asymmetric_keys/pkcs7_verify.c
 create mode 100644 include/keys/system_keyring.h
 create mode 100644 include/linux/pe.h
 delete mode 100644 kernel/modsign_pubkey.c
 rename kernel/{modsign_certificate.S => system_certificates.S} (72%)
 create mode 100644 kernel/system_keyring.c

Date	Thu, 21 Feb 2013 08:39:55 -0800		   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	   
From	Linus Torvalds <>	 	 

On Thu, Feb 21, 2013 at 7:47 AM, David Howells <dhowells@redhat.com> wrote:
>
> Can you pull this patchset please?

Not without a lot more discussion first.

Quite frankly, this is f*cking moronic. The whole thing seems to be
designed around stupid interfaces, for completely moronic reasons. Why
should we do this?

I already dislike our existing X.509 parser. And this makes the
idiotic complicated interfaces, and now it goes up to 11.

            Linus

Date	Thu, 21 Feb 2013 16:42:44 +0000		   
From	Matthew Garrett <>	 	   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	 

On Thu, Feb 21, 2013 at 08:39:55AM -0800, Linus Torvalds wrote:
> On Thu, Feb 21, 2013 at 7:47 AM, David Howells <dhowells@redhat.com> wrote:
> >
> > Can you pull this patchset please?
> 
> Not without a lot more discussion first.
> 
> Quite frankly, this is f*cking moronic. The whole thing seems to be
> designed around stupid interfaces, for completely moronic reasons. Why
> should we do this?

There's only one signing authority, and they only sign PE binaries.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Date	Thu, 21 Feb 2013 08:58:45 -0800		   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	   
From	Linus Torvalds <>	 	 

On Thu, Feb 21, 2013 at 8:42 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
> There's only one signing authority, and they only sign PE binaries.

Guys, this is not a dick-sucking contest.

If you want to parse PE binaries, go right ahead.

If Red Hat wants to deep-throat Microsoft, that's *your* issue.  That
has nothing what-so-ever to do with the kernel I maintain. It's
trivial for you guys to have a signing machine that parses the PE
binary, verifies the signatures, and signs the resulting keys with
your own key. You already wrote the code, for chissake, it's in that
f*cking pull request.

Why should *I* care? Why should the kernel care about some idiotic "we
only sign PE binaries" stupidity? We support X.509, which is the
standard for signing.

Do this in user land on a trusted machine. There is zero excuse for
doing it in the kernel.

               Linus

Date	Thu, 21 Feb 2013 17:49:55 +0000		   
From	Matthew Garrett <>	 	   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	 

On Thu, Feb 21, 2013 at 08:58:45AM -0800, Linus Torvalds wrote:

> If Red Hat wants to deep-throat Microsoft, that's *your* issue.  That
> has nothing what-so-ever to do with the kernel I maintain. It's
> trivial for you guys to have a signing machine that parses the PE
> binary, verifies the signatures, and signs the resulting keys with
> your own key. You already wrote the code, for chissake, it's in that
> f*cking pull request.

There's one significant practical awkwardness, which is that it makes 
key revocation a multi-step process - the blacklisted hash is going to 
be for the PE and not the key itself. I guess the original hash could be 
stuffed in some metadata in the key, but urgh.

Vendors want to ship keys that have been signed by a trusted party. 
Right now the only one that fits the bill is Microsoft, because 
apparently the only thing vendors love more than shitty firmware is 
following Microsoft specs. The equivalent isn't just Red Hat (or anyone 
else) programmatically re-signing those keys, it's re-signing those keys 
with a key that's trusted by the upstream kernel. Would you be willing 
to carry a default trusted key if some sucker/upstanding and 
trustworthy member of society hosted a re-signing service? Or should we 
just assume that anyone who wants to ship external modules is a fucking 
idiot and deserves to be miserable?

(I mean, *I'm* fine with the idea that they're fucking idiots and 
deserve to be miserable, but apparently there's people who think this is 
a vital part of a business model)

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Date	Thu, 21 Feb 2013 10:03:20 -0800		   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	   
From	Linus Torvalds <>	 	 

On Thu, Feb 21, 2013 at 9:49 AM, Matthew Garrett < mjg59@srcf.ucam.org> wrote:
>
> Vendors want to ship keys that have been signed by a trusted party.
> Right now the only one that fits the bill is Microsoft, because
> apparently the only thing vendors love more than shitty firmware is
> following Microsoft specs.

Quite frankly, I doubt that anybody will ever care, plus getting me to
care about some vendor that ships external binary-only modules is
going to be hard as hell.

Plus quite frankly, signing random kernel vendor modules (indirectly)
with a MS key is f*cking stupid to begin with.

In other words, I really don't see why we should bend over backwards,
when there really is no reason to. It's adding stupid code to the
kernel only to encourage stupidities in other people.

Seriously, if somebody wants to make a binary module for Fedora 18 or
whatever, they should go to Red Hat and ask whether RH is willing to
sign their key. And the whole "no, we only think it makes sense to
trust MS keys" argument is so f*cking stupid that if somebody really
brings that up, I can only throw my hands up and say "whatever".

In other words, none of this makes me think that we should do stupid
things just to perpetuate the stupidity. And I don't believe in the
argument to begin with.

Besides, let's face it, Red Hat is going to sign the official nVidia
and AMD binary modules anyway. Don't even bother to pretend anything
else.

                         Linus

From	David Howells <>		   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	   
Date	Thu, 21 Feb 2013 18:17:33 +0000	 	 

Linus Torvalds < torvalds@linux-foundation.org> wrote:

> > There's only one signing authority, and they only sign PE binaries.
> 
> If Red Hat wants to deep-throat Microsoft, that's *your* issue.  That
> has nothing what-so-ever to do with the kernel I maintain. It's
> trivial for you guys to have a signing machine that parses the PE
> binary, verifies the signatures, and signs the resulting keys with
> your own key. You already wrote the code, for chissake, it's in that
> f*cking pull request.

There's a problem with your idea.

 (1) Microsoft's revocation certificates would be based on the hash of the PE
     binary, not the key.

 (2) Re-signing would make the keys then dependent on our master key rather
     than directly on Microsoft's.  Microsoft's revocation certificates[*]
     would then be useless.

 (3) The only way Microsoft could then revoke the extra keys would be to
     revoke our *master* key.

[*] Assuming of course we add support for these.

David

Date	Thu, 21 Feb 2013 10:25:47 -0800		   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	   
From	Linus Torvalds <>	 	 

On Thu, Feb 21, 2013 at 10:17 AM, David Howells <dhowells@redhat.com> wrote:
>
> There's a problem with your idea.

You continue to miss the big question:

 - why should the kernel care?

 - why do you bother with the MS keysigning of Linux kernel modules to
begin with?

Your arguments only make sense if you accept those insane assumptions
to begin with. And I don't.

           Linus

Date	Thu, 21 Feb 2013 15:08:22 -0500		   
From	Theodore Ts'o <>	 	   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	 

On Thu, Feb 21, 2013 at 06:17:33PM +0000, David Howells wrote:
> There's a problem with your idea.
> 
>  (1) Microsoft's revocation certificates would be based on the hash of the PE
>      binary, not the key.
> 
>  (2) Re-signing would make the keys then dependent on our master key rather
>      than directly on Microsoft's.  Microsoft's revocation certificates[*]
>      would then be useless.
> 
>  (3) The only way Microsoft could then revoke the extra keys would be to
>      revoke our *master* key.

Well, this hypothetical service could also simply scan the Microsoft
revocation certificates (aka CRL's), and if the service detects a PE
hash that it relied upon to resign the module, it could then issue its
own CRL revoking the signature on the module.

If it is run this way, programmatically, I'll note that anyone can run
this service.  It doesn't have to be Red Hat.  It could be Linux
Foundation, if the LF wanted to support this whole code signing
insanity.  (Which I really think is completely overblown, and I'm
going to be amused when this blows to hell all of Red Hat's
investments in Systemtap, but whatever.)  Given that I think this
whole thing is insane, I completely agree with Linus's attempt to keep
this insanity as far away from the upstream kernel as we can.  :-/

     	      	     	       	   - Ted

List:       linux-kernel
Subject:    Re: [GIT PULL] Load keys from signed PE binaries
From:       Florian Weimer < fw () deneb ! enyo ! de>
Date:       2013-02-25 14:28:32
Message-ID: 87ppzo79in.fsf () mid ! deneb ! enyo ! de

* Matthew Garrett:

> There's only one signing authority, and they only sign PE binaries.

There are at least two, with different policies, albeit run by the
same organization.  Actually, we don't know how many authorities are
out there which have non-localized reach, so it's ... interesting to
attempt to construct any form of security based on that.

But what puzzles me most is why anyone would assume that the UEFI
application signing process somehow ensures that the embedded
certificate is non-malicious.  We cannot even track it back to the
submitter because the third-pary market place UEFI authority only
issues pseudonymous proxy certificates.  This utterly useless for any
purpose whatsoever, with the notable exception of avoding one
additional step when setting up a dual-boot machine (which will not
even work reliably until we switch to overwriting the Windows boot
loader, like in the pre-UEFI days).

Seriously, folks, can we go back one step and discuss what problem you
are trying to solve?  Is it about allowing third-party kernel modules
in an environment which does not allow unsigned ring 0 code execution?

From	David Howells <>		   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	   
Date	Mon, 25 Feb 2013 23:51:05 +0000	 	 

Florian Weimer <fw@deneb.enyo.de> wrote:

> Seriously, folks, can we go back one step and discuss what problem you
> are trying to solve?  Is it about allowing third-party kernel modules
> in an environment which does not allow unsigned ring 0 code execution?

Let me try and lay things out:

 (1) Like it or not, the reality is that machines exist that have UEFI secure
     boot.  We want it to be possible for people to be able to install and run
     Linux on these.

 (2) Unless secure boot is completely disabled, the operating system boot
     loader must be signed by a key that's in the UEFI key database.

 (3) We don't want to stop people from being able to dual boot Windows (and
     other OS's - but Windows is the problematic one), therefore we will need
     to be able to operate with secure mode enabled.

 (4) Machines are shipped with a Microsoft root key.  They are not shipped
     with a Microsoft-independent root key from Red Hat or, say, the Linux
     Foundation.

 (5) Unless we get the administrator to add a key prior to Linux installation,
     Linux cannot be booted on a secure UEFI machine - unless the boot loader
     is signed by Microsoft's key.

 (6) To maintain secure boot mode, the kernel must be signed and the boot
     loader must check the signature on it.  The key must be either compiled
     into the bootloader (and thus validated by the bootloader signature) or
     must reside in the UEFI database.

     [*] Note: This step is simplified a bit.

 (7) To maintain secure boot mode, the kernel modules must be signed and the
     kernel must check the signature on them.  The key must be compiled into
     the kernel or the bootloader or must reside in the UEFI database.

At this point, you have the kernel booted in secure boot mode.  Now, there are
several issues we have to deal with going on from here if we want to *stay* in
secure boot mode:

 (A) Unsigned modules.  These may not be loaded in secure boot mode.  At all.

 (B) Systemtap.  We need to be able to debug live kernels.  Red Hat uses
     systemtap a lot for customer support.  However, the private side of the
     key that was used to sign the normal kernel modules gets discarded during
     the build - massively reducing the probability of the key being leaked -
     and so is not available for signing additional modules outside of the
     build.

 (C) Third party modules.  Despite Linus's graphic assertions to the contrary,
     Red Hat has no intention of signing third party modules.

     [*] Note: We realise that it is the right of people to load weird and
     	 terrific stuff into their kernels...  But we don't want to have to
     	 try and deal with the consequences when they do and the sources
     	 aren't easily available.

 (D) kexec.  To be able to replace one kernel with another under secure boot
     means that you have to be able to trust the replacement kernel.
     Therefore that kernel must also be signed by a trusted key known to the
     kernel.

 (E) /dev/mem and similar.  This is not permitted.  Programs should go through
     drivers rather than directly accessing memory mapped devices.

 (F) Direct hardware instruction and DMA.  This must be vetted thoroughly by
     the driver so that this doesn't permit a device to be used to modify a
     running kernel.

 (G) Suspend to disk.  This is not permitted if it's possible to then alter
     the image and resume it.

Now, E-G above are outside the scope of this discussion - however, dealing
with kexec and the loading of modules is pertinent (kexec's boot target can be
dealt with more or less the same as for a module).  So:

 (a) Red Hat will not sign third party modules.

 (b) I don't imagine Linus wants to take patches to make modules PE rather
     than ELF, so direct module signing by Microsoft is out of the question.

 (c) Thus, to load a module signed by a third party requires the third party's
     key be made available to the kernel first.

 (d) Red Hat will not compile third party keys into its kernels - unless those
     keys come via the upstream kernel.

 (e) If Linus patches the upstream kernel to include third party keys, so be
     it.  That's his decision - in that case we will have those keys
     available.  But given Linus's responses, I find that unlikely.

 (f) We must therefore require the administrator to manually add a key using
     the UEFI shell and/or permit keys to be loaded dynamically.  The latter
     option makes it much easier to use with systemtap without having to take
     a machine down (which may be unacceptable or there may be no guarantee of
     reproducing the behaviour after a reboot).

     [*] Note: since the signing keys are done using the in-kernel keyrings
     	 facility, there is a command that's obviously available for adding
     	 them ("keyctl add").

 (g) We cannot simply permit the dynamic addition of just any old key
     otherwise we may as well not bother with signed modules at all.  The
     public key has to be in a container that's signed by a key the kernel
     already possesses and trusts.  The latter key can be one that is compiled
     into the bootloader or the kernel or could be one previously added (if
     multiple chaining is acceptable) or one resident in the UEFI database.

     X.509 certificates are currently the only container that is supported
     upstream.  Red Hat has also used PGP as a container format in the past.

 (h) Red Hat will not sign third party keys.  This would involve us becoming a
     certificate authority, which we'd rather not do as there's a lot of work
     involved in checking that people who want keys are who they say they are.

 (i) Permitting an external key to be chained from the UEFI database means
     that third party keys do not have to chain from Red Hat's key.
     Theoretically, a third party key could then be signed by anyone who owns
     a key in the UEFI database - Microsoft for instance - and still work
     under Linux.

 (j) To the best of my knowledge, Microsoft will only sign PE binaries and
     will not sign X.509 certificates.

So all my patchset does is to permit us to load a key from a signed PE binary
whilst the kernel is running - assuming that PE binary is signed by a key we
have access to and trust.  We don't actually run the binary - we just parse
it.  Sadly the format is a bit weird and involves a PKCS#7 message embedded in
the PE and several steps of digestion, but it's not particularly hard to deal
with.

We also don't want to force people to go through the steps of manually adding
keys to their UEFI.  The steps vary by UEFI firmware implementation - thus
making documentation hard - and there's always the possibility of hitting a
bug and terminally mucking up their key database.

David

[*] Note also, Red Hat wants to support the revocation, blacklist and
    whitelist mechanisms supported by the UEFI database - but that's a side
    issue.

Date	Mon, 25 Feb 2013 16:59:55 -0800		   
From	Greg KH <>	 	   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	 

On Mon, Feb 25, 2013 at 11:51:05PM +0000, David Howells wrote:
> Florian Weimer <fw@deneb.enyo.de> wrote:
> 
> > Seriously, folks, can we go back one step and discuss what problem you
> > are trying to solve?  Is it about allowing third-party kernel modules
> > in an environment which does not allow unsigned ring 0 code execution?
> 
> Let me try and lay things out:
> 
>  (1) Like it or not, the reality is that machines exist that have UEFI secure
>      boot.  We want it to be possible for people to be able to install and run
>      Linux on these.
> 
>  (2) Unless secure boot is completely disabled, the operating system boot
>      loader must be signed by a key that's in the UEFI key database.
> 
>  (3) We don't want to stop people from being able to dual boot Windows (and
>      other OS's - but Windows is the problematic one), therefore we will need
>      to be able to operate with secure mode enabled.
> 
>  (4) Machines are shipped with a Microsoft root key.  They are not shipped
>      with a Microsoft-independent root key from Red Hat or, say, the Linux
>      Foundation.
> 
>  (5) Unless we get the administrator to add a key prior to Linux installation,
>      Linux cannot be booted on a secure UEFI machine - unless the boot loader
>      is signed by Microsoft's key.
> 
>  (6) To maintain secure boot mode, the kernel must be signed and the boot
>      loader must check the signature on it.  The key must be either compiled
>      into the bootloader (and thus validated by the bootloader signature) or
>      must reside in the UEFI database.
> 
>      [*] Note: This step is simplified a bit.

That's all fine, and now your machine can boot both Linux and Windows
wonderfully.  Distros have shipped code doing this for a short while now
thanks to Matthew's and other developer's effort in writing a UEFI
bootloader / shim that Microsoft has signed.

>  (7) To maintain secure boot mode, the kernel modules must be signed and the
>      kernel must check the signature on them.  The key must be compiled into
>      the kernel or the bootloader or must reside in the UEFI database.

Wait right here.  This is NOT mandated by UEFI, nor by anyone else.  It
might be a nice thing that some people and companies want to implement,
but please don't think that some external entity is requiring that Linux
implement this, that is not true.

> At this point, you have the kernel booted in secure boot mode.  Now, there are
> several issues we have to deal with going on from here if we want to *stay* in
> secure boot mode:

Well, it's all how you define "secure boot mode", isn't it.  This seems
to be some random thing that people are making up as they go along ("We
must sign firmware!")

>  (A) Unsigned modules.  These may not be loaded in secure boot mode.  At all.

Why not?  Who says so?  See, now you really don't have an argument
besides "the policy I am deciding to make up says so," right?

Same for your other "requirements", these are all self-inflicted, no one
that I can determine is mandating any of these, who is deciding that
Linux MUST follow this policy?  I'm not saying that they are not nice
things to have, personally, I want some of these things for my own
machines just to make things more secure, but again, these are "I want
to have", not "Someone else is saying Linux MUST have."

thanks,

greg k-h

Date	Tue, 26 Feb 2013 02:33:32 +0000		   
From	Matthew Garrett <>	 	   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	 

On Mon, Feb 25, 2013 at 04:59:55PM -0800, Greg KH wrote:

> Wait right here.  This is NOT mandated by UEFI, nor by anyone else.  It
> might be a nice thing that some people and companies want to implement,
> but please don't think that some external entity is requiring that Linux
> implement this, that is not true.

Oh, come on Greg. Allowing unsigned modules allows loading arbitrary 
code into the kernel, and allowing arbitrary code into the kernel means 
that the kernel can be used to directly boot a modified copy of the 
Windows kernel. Avoiding that scenario is *explicitly* mandated by 
Microsoft. We can avoid it by either not using Microsoft as the root of 
trust or by requiring explicit key installation during the OS install 
process, but both of those make OS installation more difficult. If we 
want Linux to Just Work out of the box on Microsoft-certified hardware, 
this is one of the rules we have to live by.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Date	Mon, 25 Feb 2013 19:02:49 -0800		   
From	Greg KH <>	 	   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	 

On Tue, Feb 26, 2013 at 02:33:32AM +0000, Matthew Garrett wrote:
> On Mon, Feb 25, 2013 at 04:59:55PM -0800, Greg KH wrote:
> > Wait right here.  This is NOT mandated by UEFI, nor by anyone else.  It
> > might be a nice thing that some people and companies want to implement,
> > but please don't think that some external entity is requiring that Linux
> > implement this, that is not true.
> 
> Oh, come on Greg. Allowing unsigned modules allows loading arbitrary 
> code into the kernel, and allowing arbitrary code into the kernel means 
> that the kernel can be used to directly boot a modified copy of the 
> Windows kernel. Avoiding that scenario is *explicitly* mandated by 
> Microsoft.

Then why is the signed shim is currently being used by successfully by
distros that do not use signed kernel modules?

> We can avoid it by either not using Microsoft as the root of 
> trust or by requiring explicit key installation during the OS install 
> process, but both of those make OS installation more difficult. If we 
> want Linux to Just Work out of the box on Microsoft-certified hardware, 
> this is one of the rules we have to live by.

I don't see that being required in the wording for the Microsoft signing
authority, and in personal discussions with them, they say it would be
nice, but they can't force the issue.  Where does it say this in the
agreement specifically?

thanks,

greg k-h

Date	Tue, 26 Feb 2013 03:13:38 +0000		   
From	Matthew Garrett <>	 	   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	 

On Mon, Feb 25, 2013 at 07:02:49PM -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 02:33:32AM +0000, Matthew Garrett wrote:
> > Oh, come on Greg. Allowing unsigned modules allows loading arbitrary 
> > code into the kernel, and allowing arbitrary code into the kernel means 
> > that the kernel can be used to directly boot a modified copy of the 
> > Windows kernel. Avoiding that scenario is *explicitly* mandated by 
> > Microsoft.
> 
> Then why is the signed shim is currently being used by successfully by
> distros that do not use signed kernel modules?

Because Microsoft have indicated that they'd be taking a reactive 
approach to blacklisting and because, so far, nobody has decided to 
write the trivial proof of concept that demonstrates the problem.

> > We can avoid it by either not using Microsoft as the root of 
> > trust or by requiring explicit key installation during the OS install 
> > process, but both of those make OS installation more difficult. If we 
> > want Linux to Just Work out of the box on Microsoft-certified hardware, 
> > this is one of the rules we have to live by.
> 
> I don't see that being required in the wording for the Microsoft signing
> authority, and in personal discussions with them, they say it would be
> nice, but they can't force the issue.  Where does it say this in the
> agreement specifically?

"In addition, in the case of Microsoft’s digital signatures of UEFI 
Code, Microsoft may remove a Compatible Product from the Microsoft 
Compatibility Lists and/or revoke the digital signature upon 30 days’ 
notice to Company in the event Microsoft determines in its sole judgment 
that the security of the UEFI Code is compromised."

The ability to use the signed code to boot an untrusted copy of the 
Windows kernel is a clear breach of the trust model.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Date	Mon, 25 Feb 2013 22:25:08 -0500		   
From	Theodore Ts'o <>	 	   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	 

On Tue, Feb 26, 2013 at 03:13:38AM +0000, Matthew Garrett wrote:
> Because Microsoft have indicated that they'd be taking a reactive 
> approach to blacklisting and because, so far, nobody has decided to 
> write the trivial proof of concept that demonstrates the problem.

Microsoft would take a severe hit both from a PR perspective, as well
as incurring significant legal risks if they did that in certain
jourisdictions --- in particular, I suspect in Europe, if Microsoft
were to break the ability of Linux distributions from booting, it
would be significantly frowned upon.

So Microsoft may have privately threatened this to certain Red Hat
attendees (threats are cheap, but it's not obvious that they would
necessarily follow through on this threat.

						- Ted

Date	Tue, 26 Feb 2013 03:28:39 +0000		   
From	Matthew Garrett <>	 	   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	 

On Mon, Feb 25, 2013 at 10:25:08PM -0500, Theodore Ts'o wrote:
> On Tue, Feb 26, 2013 at 03:13:38AM +0000, Matthew Garrett wrote:
> > 
> > Because Microsoft have indicated that they'd be taking a reactive 
> > approach to blacklisting and because, so far, nobody has decided to 
> > write the trivial proof of concept that demonstrates the problem.
> 
> Microsoft would take a severe hit both from a PR perspective, as well
> as incurring significant legal risks if they did that in certain
> jourisdictions --- in particular, I suspect in Europe, if Microsoft
> were to break the ability of Linux distributions from booting, it
> would be significantly frowned upon.

If a Linux vendor chose to knowingly breach the obligations they agreed 
to, you don't think there'd be any PR hit?

> So Microsoft may have privately threatened this to certain Red Hat
> attendees (threats are cheap, but it's not obvious that they would
> necessarily follow through on this threat.

You're happy advising Linux vendors that they don't need to worry about 
module signing because it's "not obvious" that Microsoft would actually 
enforce the security model they've spent significant money developing 
and advertising?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

List:       linux-kernel
Subject:    Re: [GIT PULL] Load keys from signed PE binaries
From:       Greg KH <gregkh () linuxfoundation ! org>
Date:       2013-02-26 3:31:56
Message-ID: 20130226033156.GA24999 () kroah ! com

On Tue, Feb 26, 2013 at 03:13:38AM +0000, Matthew Garrett wrote:
> On Mon, Feb 25, 2013 at 07:02:49PM -0800, Greg KH wrote:
> > On Tue, Feb 26, 2013 at 02:33:32AM +0000, Matthew Garrett wrote:
> > > Oh, come on Greg. Allowing unsigned modules allows loading arbitrary 
> > > code into the kernel, and allowing arbitrary code into the kernel means 
> > > that the kernel can be used to directly boot a modified copy of the 
> > > Windows kernel. Avoiding that scenario is *explicitly* mandated by 
> > > Microsoft.
> > 
> > Then why is the signed shim is currently being used by successfully by
> > distros that do not use signed kernel modules?
> 
> Because Microsoft have indicated that they'd be taking a reactive 
> approach to blacklisting and because, so far, nobody has decided to 
> write the trivial proof of concept that demonstrates the problem.

So, once that proof is written, suddenly all of the working Linux
distros's keys will be revoked?  That will be fun to watch happen, and
odds are, it will not.  Imagine the PR fun that will cause :)

> > > We can avoid it by either not using Microsoft as the root of 
> > > trust or by requiring explicit key installation during the OS install 
> > > process, but both of those make OS installation more difficult. If we 
> > > want Linux to Just Work out of the box on Microsoft-certified hardware, 
> > > this is one of the rules we have to live by.
> > 
> > I don't see that being required in the wording for the Microsoft signing
> > authority, and in personal discussions with them, they say it would be
> > nice, but they can't force the issue.  Where does it say this in the
> > agreement specifically?
> 
> "In addition, in the case of Microsoft’s digital signatures of UEFI 
> Code, Microsoft may remove a Compatible Product from the Microsoft 
> Compatibility Lists and/or revoke the digital signature upon 30 days’ 
> notice to Company in the event Microsoft determines in its sole judgment 
> that the security of the UEFI Code is compromised."
> 
> The ability to use the signed code to boot an untrusted copy of the 
> Windows kernel is a clear breach of the trust model.

I don't buy it.  Yes, I understand this is your position, and has been
all along, and _maybe_ you can extend it to "we should sign our kernel
modules", but to take it farther than that, like the list David has
described, is not required by anyone here.

Yes, they are all "nice" things to have, but I fail to see how Microsoft
should be dictating how Linux, or any other operating system, works,
especially when they aren't even signing the kernel, they are merely
signing a bootloader shim and saying "do your best for keeping the rest
of the system secure please."

thanks,

greg k-h

Date	Mon, 25 Feb 2013 19:32:04 -0800		   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	   
From	Linus Torvalds <>	 	 

On Mon, Feb 25, 2013 at 7:28 PM, Matthew Garrett < mjg59@srcf.ucam.org> wrote:
>
> You're happy advising Linux vendors that they don't need to worry about
> module signing because it's "not obvious" that Microsoft would actually
> enforce the security model they've spent significant money developing
> and advertising?

And you're happy shilling for a broken model?

The fact is, the only valid user for the whole security model is to
PROTECT THE USER.

Your arguments constantly seem to miss that rather big point. You
think this is about bending over when MS whispers sweet nothings in
your ear..

The whole and only reason I ever merged module signatures is because
it actually allows *users* to do a good job at security. You, on the
other hand, seem to have drunk the cool-aid on the whole "let's
control the user" crap.

Did you forget what security was all about?

              Linus

List:       linux-kernel
Subject:    Re: [GIT PULL] Load keys from signed PE binaries
From:       Matthew Garrett < mjg59 () srcf ! ucam ! org>
Date:       2013-02-26 3:38:04
Message-ID: 20130226033803.GA30285 () srcf ! ucam ! org

On Mon, Feb 25, 2013 at 07:31:56PM -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 03:13:38AM +0000, Matthew Garrett wrote:
> > Because Microsoft have indicated that they'd be taking a reactive 
> > approach to blacklisting and because, so far, nobody has decided to 
> > write the trivial proof of concept that demonstrates the problem.
> 
> So, once that proof is written, suddenly all of the working Linux
> distros's keys will be revoked?  That will be fun to watch happen, and
> odds are, it will not.  Imagine the PR fun that will cause :)

No. Why would they be?

> > "In addition, in the case of Microsoft’s digital signatures of UEFI 
> > Code, Microsoft may remove a Compatible Product from the Microsoft 
> > Compatibility Lists and/or revoke the digital signature upon 30 days’ 
> > notice to Company in the event Microsoft determines in its sole judgment 
> > that the security of the UEFI Code is compromised."
> > 
> > The ability to use the signed code to boot an untrusted copy of the 
> > Windows kernel is a clear breach of the trust model.
> 
> I don't buy it.  Yes, I understand this is your position, and has been
> all along, and _maybe_ you can extend it to "we should sign our kernel
> modules", but to take it farther than that, like the list David has
> described, is not required by anyone here.

Failing to take it to that extent is dangerously naive. If you can do it 
with kernel modules, you can do it with kexec. If you can do it with 
kexec, you can do it with arbitrary mmio access to PCI devices.

> Yes, they are all "nice" things to have, but I fail to see how Microsoft
> should be dictating how Linux, or any other operating system, works,
> especially when they aren't even signing the kernel, they are merely
> signing a bootloader shim and saying "do your best for keeping the rest
> of the system secure please."

Microsoft aren't dictating anything here. We're free not to use their 
signatures. However, if we do use their signatures, we agree to play by 
their rules. Nobody seems to have come up with a viable alternative, so 
here we are.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Date	Tue, 26 Feb 2013 03:42:50 +0000		   
From	Matthew Garrett <>	 	   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	 

On Mon, Feb 25, 2013 at 07:32:04PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 7:28 PM, Matthew Garrett < mjg59@srcf.ucam.org> wrote:
> >
> > You're happy advising Linux vendors that they don't need to worry about
> > module signing because it's "not obvious" that Microsoft would actually
> > enforce the security model they've spent significant money developing
> > and advertising?
> 
> And you're happy shilling for a broken model?
>
> The fact is, the only valid user for the whole security model is to
> PROTECT THE USER.

The user Microsoft care about isn't running Linux. The user is running 
Windows, and someone's merely using Linux as a vector to launch their 
backdoored Windows kernel. How do Microsoft protect that user? They 
blacklist the signature used by that Linux bootloader. If we want to 
protect the user's ability to boot Linux, we need to protect the 
Windows users from having Linux used against them.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Date	Mon, 25 Feb 2013 19:45:24 -0800		   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	   
From	Linus Torvalds <>	 	 

On Mon, Feb 25, 2013 at 7:42 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
> The user Microsoft care about isn't running Linux

How f*cking hard is it for you to understand?

Stop arguing about what MS wants. We do not care. We care bout the
*user*. You are continually missing the whole point of security, and
then you make some idiotic arguments about what MS wants you to do.

It's irrelevant. The only thing that matters is what our *users* want
us to do, and protecting *their* rights. As long as you seem to treat
this as some kind of "let's please MS, not our users" issue, all your
arguments are going to be crap.

                Linus

Date	Tue, 26 Feb 2013 03:48:42 +0000		   
From	Matthew Garrett <>	 	   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	 

On Mon, Feb 25, 2013 at 07:45:24PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 7:42 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> >
> > The user Microsoft care about isn't running Linux
> 
> How f*cking hard is it for you to understand?
> 
> Stop arguing about what MS wants. We do not care. We care bout the
> *user*. You are continually missing the whole point of security, and
> then you make some idiotic arguments about what MS wants you to do.
> 
> It's irrelevant. The only thing that matters is what our *users* want
> us to do, and protecting *their* rights. As long as you seem to treat
> this as some kind of "let's please MS, not our users" issue, all your
> arguments are going to be crap.

Our users want to be able to boot Linux. If Microsoft blacklist a 
distribution's bootloader, that user isn't going to be able to boot 
Linux any more. How does that benefit our users? The user that wants to 
explicitly disable the security is free to do so ("mokutil 
--disable-validation" as root, follow the prompts, reboot), but if 
we only care about *our* users then Microsoft will gleefully blacklist 
us into complete irrelevance.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

List:       linux-kernel
Subject:    Re: [GIT PULL] Load keys from signed PE binaries
From:       Theodore Ts'o <tytso () mit ! edu>
Date:       2013-02-26 3:49:35
Message-ID: 20130226034935.GB12906 () thunk ! org

On Tue, Feb 26, 2013 at 03:28:39AM +0000, Matthew Garrett wrote:
> You're happy advising Linux vendors that they don't need to worry about 
> module signing because it's "not obvious" that Microsoft would actually 
> enforce the security model they've spent significant money developing 
> and advertising?

My advice was to Linus and those who are willing to listen to me, not
to Red Hat.  Red Hat has not generally been receptive to my advice in
the past; not that they have any obligation to listen to me, of
course.  After all, I'm not on Red Hat's payroll.  :-)

Speaking more generally, though, (a) revoking the Linux's key is not
zero-cost to Microsoft, (b) it's also not an instant death sentence to
Linux distributions.  Users can always either disable secure boot
mode, or they can install another signing key.  Yes, that is not the
best user experience, but it's something which is doable.

The other thing to consider is that it's not clear in the long run how
much of a lock Microsoft and Windows 8 will have hardware
manufacturers.  There's already been people discussing how to install
Linux on the Chromebook Pixel.  Other traditional PC manufacturers,
including HP and Lenovo, have started creating non-Windows-8 x86
systems using ChromeOS, which can easily have a stock Linux distro
installed on it, and they come at a variety of different price points.
(Heck, the recent ChromeOS boxes, such as Pixel, come with an open
source BIOS which you can reflash.)

Finally note that secure boot is not an issue on server platforms,
which is where most of the traditional Linux vendors have made their
money.  And those who are making money with pre-installed Linux
systems (i.e., like Ubuntu, or Google with ChromeOS) for consumers are
generally doing so in cooperation with hardware OEM partners, where
there's no reason to kowtow to Microsoft's policies.  So there really
isn't a good reason for Linux vendors to cower in fear of Microsoft.

Much of Microsoft power comes from people letting them have power over
them.  You don't have to do it.  Sometimes it's better to let them
carry through on their threat, and while it will be inconvenient, it
is highly likely they will also take damage from their taking action.
Consider what happened the last time the Republicans carried through
on their threat to shut down the US Federal Government.  Sometimes
it's better to let the blackmailers carry through on their threat, and
then steps from there.  Cowering in fear and paying Danegled rarely
gets rid of the Dane.

Regards,

						- Ted

List:       linux-kernel
Subject:    Re: [GIT PULL] Load keys from signed PE binaries
From:       Greg KH <gregkh () linuxfoundation ! org>
Date:       2013-02-26 3:54:16
Message-ID: 20130226035416.GA1128 () kroah ! com

On Tue, Feb 26, 2013 at 03:38:04AM +0000, Matthew Garrett wrote:
> On Mon, Feb 25, 2013 at 07:31:56PM -0800, Greg KH wrote:
> > On Tue, Feb 26, 2013 at 03:13:38AM +0000, Matthew Garrett wrote:
> > > Because Microsoft have indicated that they'd be taking a reactive 
> > > approach to blacklisting and because, so far, nobody has decided to 
> > > write the trivial proof of concept that demonstrates the problem.
> > 
> > So, once that proof is written, suddenly all of the working Linux
> > distros's keys will be revoked?  That will be fun to watch happen, and
> > odds are, it will not.  Imagine the PR fun that will cause :)
> 
> No. Why would they be?

Because they are using the "public" shim that you provided them, or the
Linux Foundation's shim.  Almost no distro, other than the "main" 3-4
will end up getting their own shim signed, the rest will just use the
one you so helpfully provided them :)

> > > "In addition, in the case of Microsoft’s digital signatures of UEFI 
> > > Code, Microsoft may remove a Compatible Product from the Microsoft 
> > > Compatibility Lists and/or revoke the digital signature upon 30 days’ 
> > > notice to Company in the event Microsoft determines in its sole judgment 
> > > that the security of the UEFI Code is compromised."
> > > 
> > > The ability to use the signed code to boot an untrusted copy of the 
> > > Windows kernel is a clear breach of the trust model.
> > 
> > I don't buy it.  Yes, I understand this is your position, and has been
> > all along, and _maybe_ you can extend it to "we should sign our kernel
> > modules", but to take it farther than that, like the list David has
> > described, is not required by anyone here.
> 
> Failing to take it to that extent is dangerously naive. If you can do it 
> with kernel modules, you can do it with kexec. If you can do it with 
> kexec, you can do it with arbitrary mmio access to PCI devices.

Yes you can.  There are all sorts of fun ways you can do this, I can
think of a few more at the moment as well.  So, where does it stop?
And why stop it at all?  Why not just forbid root users at all?

> > Yes, they are all "nice" things to have, but I fail to see how Microsoft
> > should be dictating how Linux, or any other operating system, works,
> > especially when they aren't even signing the kernel, they are merely
> > signing a bootloader shim and saying "do your best for keeping the rest
> > of the system secure please."
> 
> Microsoft aren't dictating anything here. We're free not to use their 
> signatures. However, if we do use their signatures, we agree to play by 
> their rules. Nobody seems to have come up with a viable alternative, so 
> here we are.

Ok, I keep hearing people say, "why doesn't someone else create a
signing authority!" all the time.  And it comes down to one big thing,
money.

The money required to put up a bond to allow a root key to be placed
into the BIOS for just one major OEM is larger than pretty much all of
the Linux companies combined at this moment in time.

The money required to staff up, and put into place the proper
infrastructure to be a signing authority is, I'm pretty sure, larger
than the operating budget of the Linux Foundation at this point in time.
And again, remember the bond requirement of the OEMs.

So that's why the LF, or anyone else, including the UEFI group
themselves, are NOT getting into the key signing business.  Money.

Oh, and the fact that it's just not worth it in the end, but that's a
different topic :)

thanks,

greg k-h

List:       linux-kernel
Subject:    Re: [GIT PULL] Load keys from signed PE binaries
From:       Matthew Garrett <mjg59 () srcf ! ucam ! org>
Date:       2013-02-26 4:04:56
Message-ID: 20130226040456.GA30717 () srcf ! ucam ! org

On Mon, Feb 25, 2013 at 07:54:16PM -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 03:38:04AM +0000, Matthew Garrett wrote:
> > On Mon, Feb 25, 2013 at 07:31:56PM -0800, Greg KH wrote:
> > > So, once that proof is written, suddenly all of the working Linux
> > > distros's keys will be revoked?  That will be fun to watch happen, and
> > > odds are, it will not.  Imagine the PR fun that will cause :)
> > 
> > No. Why would they be?
> 
> Because they are using the "public" shim that you provided them, or the
> Linux Foundation's shim.  Almost no distro, other than the "main" 3-4
> will end up getting their own shim signed, the rest will just use the
> one you so helpfully provided them :)

There's no reason for the LF or generic shim to be blacklisted, since 
neither will load anything without manual intervention. But that also 
means that anyone trying to boot them has to have some knowledge of 
English, and that there's no way to netboot them. But sure, anyone 
planning that approach has much less to worry about.

> > > I don't buy it.  Yes, I understand this is your position, and has been
> > > all along, and _maybe_ you can extend it to "we should sign our kernel
> > > modules", but to take it farther than that, like the list David has
> > > described, is not required by anyone here.
> > 
> > Failing to take it to that extent is dangerously naive. If you can do it 
> > with kernel modules, you can do it with kexec. If you can do it with 
> > kexec, you can do it with arbitrary mmio access to PCI devices.
> 
> Yes you can.  There are all sorts of fun ways you can do this, I can
> think of a few more at the moment as well.  So, where does it stop?
> And why stop it at all?  Why not just forbid root users at all?

Because there's a distinction between ring 0 and ring 3?

> > Microsoft aren't dictating anything here. We're free not to use their 
> > signatures. However, if we do use their signatures, we agree to play by 
> > their rules. Nobody seems to have come up with a viable alternative, so 
> > here we are.
> 
> Ok, I keep hearing people say, "why doesn't someone else create a
> signing authority!" all the time.  And it comes down to one big thing,
> money.

Right. We've failed at creating an alternative. That doesn't mean that 
we get to skip the responsibilities associated with the choice we've 
made.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

List:       linux-kernel
Subject:    Re: [GIT PULL] Load keys from signed PE binaries
From:       Greg KH < gregkh () linuxfoundation ! org>
Date:       2013-02-26 4:13:24
Message-ID: 20130226041324.GA7241 () kroah ! com

On Tue, Feb 26, 2013 at 04:04:56AM +0000, Matthew Garrett wrote:
> On Mon, Feb 25, 2013 at 07:54:16PM -0800, Greg KH wrote:
> > On Tue, Feb 26, 2013 at 03:38:04AM +0000, Matthew Garrett wrote:
> > > On Mon, Feb 25, 2013 at 07:31:56PM -0800, Greg KH wrote:
> > > > So, once that proof is written, suddenly all of the working Linux
> > > > distros's keys will be revoked?  That will be fun to watch happen, and
> > > > odds are, it will not.  Imagine the PR fun that will cause :)
> > > 
> > > No. Why would they be?
> > 
> > Because they are using the "public" shim that you provided them, or the
> > Linux Foundation's shim.  Almost no distro, other than the "main" 3-4
> > will end up getting their own shim signed, the rest will just use the
> > one you so helpfully provided them :)
> 
> There's no reason for the LF or generic shim to be blacklisted, since 
> neither will load anything without manual intervention. But that also 
> means that anyone trying to boot them has to have some knowledge of 
> English, and that there's no way to netboot them. But sure, anyone 
> planning that approach has much less to worry about.

I don't see anything about "manual intervention" in the wording that you
provided from Microsoft absolving you from the "duty" you feel you owe
them.  I understand you are worried about "automated" exploits, but that
really is just a semantic overall, as we know it is easy to get people
to hit a key when booting just to get on with the process.

> > Yes you can.  There are all sorts of fun ways you can do this, I can
> > think of a few more at the moment as well.  So, where does it stop?
> > And why stop it at all?  Why not just forbid root users at all?
> 
> Because there's a distinction between ring 0 and ring 3?

Since when did you start trusting ring 0 code?  Bozos like me write this
stuff, surely it isn't secure :)

> > > Microsoft aren't dictating anything here. We're free not to use their 
> > > signatures. However, if we do use their signatures, we agree to play by 
> > > their rules. Nobody seems to have come up with a viable alternative, so 
> > > here we are.
> > 
> > Ok, I keep hearing people say, "why doesn't someone else create a
> > signing authority!" all the time.  And it comes down to one big thing,
> > money.
> 
> Right. We've failed at creating an alternative. That doesn't mean that 
> we get to skip the responsibilities associated with the choice we've 
> made.

Wait, who is "we" here?  The community?  The community over-all didn't
agree with anything with Microsoft, that is between the people getting a
signed key and Microsoft.  Again, you are trying to push your (prior)
company's agreement between them and Microsoft onto the community, and
now the community is pushing back, is that a surprise?

thanks,

greg k-h

List:       linux-kernel
Subject:    Re: [GIT PULL] Load keys from signed PE binaries
From:       Matthew Garrett <mjg59 () srcf ! ucam ! org>
Date:       2013-02-26 4:23:38
Message-ID: 20130226042338.GA30944 () srcf ! ucam ! org

On Mon, Feb 25, 2013 at 08:13:24PM -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 04:04:56AM +0000, Matthew Garrett wrote:
> > There's no reason for the LF or generic shim to be blacklisted, since 
> > neither will load anything without manual intervention. But that also 
> > means that anyone trying to boot them has to have some knowledge of 
> > English, and that there's no way to netboot them. But sure, anyone 
> > planning that approach has much less to worry about.
> 
> I don't see anything about "manual intervention" in the wording that you
> provided from Microsoft absolving you from the "duty" you feel you owe
> them.  I understand you are worried about "automated" exploits, but that
> really is just a semantic overall, as we know it is easy to get people
> to hit a key when booting just to get on with the process.

If the user has explicitly enrolled a hash then they're stepping outside 
the trust model. That's why the LF loader shows dire warnings, and why 
shim has deliberately awkward UI. Perhaps we'll have made an incorrect 
judgement and it'll turn out that users can still be manipulated into 
being exploited this way, and in that case we'll have to reappraise some 
of those choices. But given that the barrier there is similar to the 
barrier involved in just telling users to disable Secure Boot entirely, 
I don't think it's terribly likely.

> > > Yes you can.  There are all sorts of fun ways you can do this, I can
> > > think of a few more at the moment as well.  So, where does it stop?
> > > And why stop it at all?  Why not just forbid root users at all?
> > 
> > Because there's a distinction between ring 0 and ring 3?
> 
> Since when did you start trusting ring 0 code?  Bozos like me write this
> stuff, surely it isn't secure :)

The fact that we bother with CVEs seems to suggest that we at least 
aspire to it...

> > Right. We've failed at creating an alternative. That doesn't mean that 
> > we get to skip the responsibilities associated with the choice we've 
> > made.
> 
> Wait, who is "we" here?  The community?  The community over-all didn't
> agree with anything with Microsoft, that is between the people getting a
> signed key and Microsoft.  Again, you are trying to push your (prior)
> company's agreement between them and Microsoft onto the community, and
> now the community is pushing back, is that a surprise?

The community's not obliged to take the patches, and I'm sure Red Hat 
and any other vendors who care can carry them themselves. But it'd be 
nice to avoid even more divergence between upstream and the 
distributions, wouldn't it?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

List:       linux-kernel
Subject:    Re: [GIT PULL] Load keys from signed PE binaries
From:       Linus Torvalds < torvalds () linux-foundation ! org>
Date:       2013-02-26 4:31:08
Message-ID: CA+55aFyAfgqmxGnh+WpZjgR5qKd+CLr1S7gKnXihqJXB346DqQ () mail ! gmail ! com

On Mon, Feb 25, 2013 at 7:48 PM, Matthew Garrett < mjg59@srcf.ucam.org> wrote:
>
> Our users want to be able to boot Linux. If Microsoft blacklist a
> distribution's bootloader, that user isn't going to be able to boot
> Linux any more. How does that benefit our users?

How does bringing up an unlikely and bogus scenario - and when people
call you on it, just double down on it - help users?

Stop the fear mongering already.

So here's what I would suggest, and it is based on REAL SECURITY and
on PUTTING THE USER FIRST instead of your continual "let's please
microsoft by doing idiotic crap" approach.

So instead of pleasing microsoft, try to see how we can add real security:

 - a distro should sign its own modules AND NOTHING ELSE by default.
And it damn well shouldn't allow any other modules to be loaded at all
by default, because why the f*ck should it? And what the hell should a
microsoft signature have to do with *anything*?

 - before loading any third-party module, you'd better make sure you
ask the user for permission. On the console. Not using keys. Nothing
like that. Keys will be compromised. Try to limit the damage, but more
importantly, let the user be in control.

 - encourage things like per-host random keys - with the stupid UEFI
checks disabled entirely if required. They are almost certainly going
to be *more* secure than depending on some crazy root of trust based
on a big company, with key signing authorities that trust anybody with
a credit card. Try to teach people about things like that instead.
Encourage people to do their own (random) keys, and adding those to
their UEFI setups (or not: the whole UEFI thing is more about control
than security), and strive to do things like one-time signing with the
private key thrown out entirely. IOW try to encourage *that* kind of
"we made sure to ask the user very explicitly with big warnings and
create his own key for that particular module" security. Real
security, not "we control the user" security.

Sure, users will screw that up too. They'll want to load crazy nvidia
binary modules etc crap. But make it *their* decision, and under
*their* control, instead of trying to tell the world about how this
should be blessed by Microsoft.

Because it really shouldn't be about MS blessings, it should be about
the *user* blessing kernel modules.

Quite frankly, *you* are what he key-hating crazies were afraid of.
You peddle the "control, not security" crap-ware. The whole "MS owns
your machine" is *exactly* the wrong way to use keys.

                 Linus

Date	Tue, 26 Feb 2013 04:57:47 +0000		   
From	Matthew Garrett <>	 	   
Subject	Re: [GIT PULL] Load keys from signed PE binaries	 	 

On Mon, Feb 25, 2013 at 08:31:08PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 7:48 PM, Matthew Garrett  wrote:
> >
> > Our users want to be able to boot Linux. If Microsoft blacklist a
> > distribution's bootloader, that user isn't going to be able to boot
> > Linux any more. How does that benefit our users?
> 
> How does bringing up an unlikely and bogus scenario - and when people
> call you on it, just double down on it - help users?

What's unlikely or bogus about it? There's incentive to breach the 
Secure Boot trust model, and to do that you need signed code that'll run 
unsigned code in ring 0. Why would the black hats bother finding more 
subtle exploits if they can just write a new kexec loader?

>  - a distro should sign its own modules AND NOTHING ELSE by default.
> And it damn well shouldn't allow any other modules to be loaded at all
> by default, because why the f*ck should it? And what the hell should a
> microsoft signature have to do with *anything*?

So far? Nothing.

>  - before loading any third-party module, you'd better make sure you
> ask the user for permission. On the console. Not using keys. Nothing
> like that. Keys will be compromised. Try to limit the damage, but more
> importantly, let the user be in control.

So some sort of blocking insmod that waits for a sysrq input? I spent 
some time thinking about that, but then there's people who want 
automated installs on systems with bizarre storage hardware that depends 
on out of tree drivers. Like I said, *I'm* absolutely fine with not 
supporting out of tree drivers at all.

>  - encourage things like per-host random keys - with the stupid UEFI
> checks disabled entirely if required. They are almost certainly going
> to be *more* secure than depending on some crazy root of trust based
> on a big company, with key signing authorities that trust anybody with
> a credit card. Try to teach people about things like that instead.
> Encourage people to do their own (random) keys, and adding those to
> their UEFI setups (or not: the whole UEFI thing is more about control
> than security), and strive to do things like one-time signing with the
> private key thrown out entirely. IOW try to encourage *that* kind of
> "we made sure to ask the user very explicitly with big warnings and
> create his own key for that particular module" security. Real
> security, not "we control the user" security.

Yes, ideally people will engage in self-signing and distributions will 
have mechanisms for dealing with that.

> Sure, users will screw that up too. They'll want to load crazy nvidia
> binary modules etc crap. But make it *their* decision, and under
> *their* control, instead of trying to tell the world about how this
> should be blessed by Microsoft.

We can block third party modules by default, but they'll still be 
trusting Microsoft by default.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

List:       linux-kernel
Subject:    Re: [GIT PULL] Load keys from signed PE binaries
From:       Linus Torvalds <torvalds () linux-foundation ! org>
Date:       2013-02-26 4:43:59
Message-ID: CA+55aFx9HkRGfMx6pfR2xsTf0vof_yyrT4ks5TzMKoEpS7w=5g () mail ! gmail ! com

On Mon, Feb 25, 2013 at 8:23 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
> If the user has explicitly enrolled a hash then they're stepping outside
> the trust model.

This is the kind of totally bogus crap that no sane person should ever
spout. Stop it.

If the user has explicitly enrolled a hash, then that should be the
*primary* trust model, dammit. That should be very much what you
should care about first and foremost, and that should be your goal in
life. That's when the user says "I'm in control of my own machine, and
I want to trust *this*".

It's not about "stepping outside of the trust model". Quite the
reverse. It's about actually being *part* of the trust model, and
taking control of your own machine. It's the *good* scenario. It's
what you should encourage users to do.

No, it likely can't be the default because we shouldn't expect users
to care enough, but on the other hand the default should definitely
*not* be "enable random third party modules signed indirectly by MS",
which is what your crazy world-view seems to be.

So the first order should be: "we provide modules to cover all normal
users". You use the RH key for that.

The *second* order should be: "we encourage and tell people how to add
their own keys and sign modules they trust".

The third order should probably be "we encourage people to use random
one-time keys - probably with UEFI key checking turned off entirely,
because let's face it, that doesn't really add any real security for
most people". It's what kernel developers and most servers would
probably want to use. They likely don't do the whole UEFI crap anyway,
and random one-time keys are actually better against things like
rootkits etc than *any* centrally administered chain of trust.

Only somewhere really really deep down should the "ok, what about a MS
signature" thing be. It could be part of the user-level application
(part of your distribution) that displays the "are you really sure you
want to load this module with an unrecognized signature? I can tell
that it has a MS signature on it". But by the time you get this far,
you've already failed the first few normal levels.

            Linus