linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: "Luis R. Rodriguez" <mcgrof@suse.com>
Cc: dhowells@redhat.com, linux-security-module@vger.kernel.org,
	james.l.morris@oracle.com, serge@hallyn.com,
	linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
	Kyle McMartin <kyle@kernel.org>,
	David Woodhouse <david.woodhouse@intel.com>,
	Seth Forshee <seth.forshee@canonical.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Joey Lee <jlee@suse.de>, Rusty Russell <rusty@rustcorp.com.au>,
	zohar@linux.vnet.ibm.com, mricon@kernel.org
Subject: Re: [RFD] linux-firmware key arrangement for firmware signing
Date: Wed, 20 May 2015 16:14:19 +0100	[thread overview]
Message-ID: <6810.1432134859@warthog.procyon.org.uk> (raw)
In-Reply-To: <20150519200232.GM23057@wotan.suse.de>

Luis R. Rodriguez <mcgrof@suse.com> wrote:

> This begs the question on how we'd manage keys for firmware signing on
> linux-firmare. Since the keys are x509 keys we need a CA. Based on some
> initial discussions it would seem we'd need the Linux Foundation to create a
> key, this would be embedded in the kernel and that key would be used to sign
> Kyle's key.  Kyle would in turn use his key for signing linux-firmware
> files. David, Kyle, did I summarize this correctly ?

Yes.

> I think we need one change here, we'd need to ensure that such key could
> only be used for vetting firmware files, not modules loaded.  The
> firmware_class could for instance still use all the keys in
> system_trusted_keyring, which would include the UEFI key db, but it does not
> seems reasonable to expect keys used for fw signing to also go into
> system_trusted_keyring to also be used for module signing.

X.509 certificates can take attributes that define what the key held therein
may be used for.

You actually have four categories of key usage, I think:

 (1) Signing modules.

 (2) Signing firmware.

 (3) Signing kernel binaries for kexec.

 (4) Signing other keys that can then be chained to (1) - (3).

For instance, the LF might use their key to sign Kyle's key.  Kyle might want
to replace his key yearly, say, because the more examples of things signed
with it, the more exposed it becomes.  So the kernel would need to carry the
LF key, say, and then the appropriate one of Kyle's keys could be loaded
dynamically.

David

      parent reply	other threads:[~2015-05-20 15:48 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-19 20:02 [RFD] linux-firmware key arrangement for firmware signing Luis R. Rodriguez
2015-05-19 20:40 ` Luis R. Rodriguez
2015-05-19 20:59 ` Andy Lutomirski
2015-05-19 22:11   ` Luis R. Rodriguez
2015-05-19 22:40     ` Andy Lutomirski
2015-05-19 23:30   ` Julian Calaby
2015-05-19 23:42     ` Andy Lutomirski
2015-05-20  0:39       ` Luis R. Rodriguez
2015-05-20  0:41         ` Andy Lutomirski
2015-05-21 22:26           ` Luis R. Rodriguez
2015-05-21 23:15             ` Casey Schaufler
2015-05-21 15:51   ` David Howells
2015-05-21 16:30     ` Mimi Zohar
2015-05-21 16:39     ` Andy Lutomirski
2015-05-21 16:51       ` Petko Manolov
2015-05-21 16:55         ` Andy Lutomirski
2015-05-21 17:44           ` Petko Manolov
2015-05-21 16:43     ` Petko Manolov
2015-05-21 16:48       ` Andy Lutomirski
2015-05-21 16:58         ` Petko Manolov
2015-05-21 16:59       ` Mimi Zohar
2015-05-19 21:48 ` Mimi Zohar
2015-05-19 22:19   ` Luis R. Rodriguez
2015-05-19 23:37     ` Mimi Zohar
2015-05-20  0:22       ` Luis R. Rodriguez
2015-05-20  1:06         ` Mimi Zohar
2015-05-20  1:29           ` Andy Lutomirski
2015-05-20  2:05             ` Mimi Zohar
2015-05-20  2:10               ` Andy Lutomirski
2015-05-20 15:49                 ` Petko Manolov
2015-05-20 16:08         ` Petko Manolov
2015-05-20 14:04 ` Seth Forshee
2015-05-20 16:24   ` One Thousand Gnomes
2015-05-20 16:46     ` Petko Manolov
2015-05-21  4:41       ` Greg Kroah-Hartman
2015-05-21  5:41         ` Petko Manolov
2015-05-21  6:14           ` Greg Kroah-Hartman
2015-05-21 13:05             ` Mimi Zohar
2015-05-21 15:45               ` Greg Kroah-Hartman
2015-05-21 15:53                 ` Petko Manolov
2015-05-21 16:57                   ` Greg Kroah-Hartman
2015-05-26 17:08                   ` One Thousand Gnomes
2015-05-26 19:15                     ` Petko Manolov
2015-05-26 19:52                     ` Mimi Zohar
2015-05-26 23:06                   ` David Howells
2015-05-21 16:03                 ` Woodhouse, David
2015-05-21 16:22                   ` Mimi Zohar
2015-05-21 16:31                     ` Woodhouse, David
2015-05-21 17:02                   ` gregkh
2015-05-21 17:14                     ` Petko Manolov
2015-05-21 18:23                     ` Luis R. Rodriguez
2015-05-21 18:30                       ` Luis R. Rodriguez
2015-05-21 19:32                     ` Woodhouse, David
2015-05-21 17:49                   ` Luis R. Rodriguez
2015-05-21 14:45             ` Petko Manolov
2015-05-21 22:50     ` Luis R. Rodriguez
2015-05-20 20:35   ` Kyle McMartin
2015-05-20 15:08 ` David Howells
2015-05-20 15:47   ` Seth Forshee
2015-05-21 16:23   ` David Howells
2015-05-20 15:14 ` David Howells [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6810.1432134859@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=david.woodhouse@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=james.l.morris@oracle.com \
    --cc=jlee@suse.de \
    --cc=kyle@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mcgrof@suse.com \
    --cc=mricon@kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=serge@hallyn.com \
    --cc=seth.forshee@canonical.com \
    --cc=zohar@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).