linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: "Woodhouse, David" <david.woodhouse@intel.com>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"seth.forshee@canonical.com" <seth.forshee@canonical.com>,
	"mricon@kernel.org" <mricon@kernel.org>,
	"dhowells@redhat.com" <dhowells@redhat.com>,
	"rusty@rustcorp.com.au" <rusty@rustcorp.com.au>,
	"linux-security-module@vger.kernel.org"
	<linux-security-module@vger.kernel.org>,
	"jlee@suse.de" <jlee@suse.de>,
	"kyle@kernel.org" <kyle@kernel.org>,
	"gnomes@lxorguk.ukuu.org.uk" <gnomes@lxorguk.ukuu.org.uk>,
	"james.l.morris@oracle.com" <james.l.morris@oracle.com>,
	"mcgrof@suse.com" <mcgrof@suse.com>,
	"serge@hallyn.com" <serge@hallyn.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [RFD] linux-firmware key arrangement for firmware signing
Date: Thu, 21 May 2015 12:22:20 -0400	[thread overview]
Message-ID: <1432225340.2450.6.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <1432224181.8004.7.camel@intel.com>

On Thu, 2015-05-21 at 16:03 +0000, Woodhouse, David wrote:
> On Thu, 2015-05-21 at 08:45 -0700, Greg Kroah-Hartman wrote:
> > On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote:
> > > Signatures don't provide any guarantees as to code quality or
> > > correctness.   They do provide file integrity and provenance.  In
> > > addition to the license and a Signed-off-by line, having the 
> > > firmware provider include a signature of the firmware would be 
> > > nice.
> > 
> > That would be "nice", but that's not going to be happening here, from
> > what I can tell.  The firmware provider should be putting the signature
> > inside the firmware image itself, and verifying it on the device, in
> > order to properly "know" that it should be running that firmware.  The
> > kernel shouldn't be involved here at all, as Alan pointed out.
> 
> In a lot of cases we have loadable firmware precisely to allow us to
> reduce the cost of the hardware. Adding cryptographic capability in the
> 'load firmware' state of the device isn't really compatible with that
> :)
> 
> In the case where kernel and modules are signed, it *is* useful for a
> kernel device driver also to be able to validate that what it's about
> to load into a device is authentic. Where 'authentic' will originally
> just mean that it's come from the linux-firmware.git repository or the
> same entity that built (and signed) the kernel, but actually I *do*
> expect vendors who are actively maintaining the firmware images in
> linux-firmware.git to start providing detached signatures of their own.

That's great!  What format do you expect the detached signatures to be?
Where will they reside?

Mimi


  reply	other threads:[~2015-05-21 16:23 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 [this message]
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

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=1432225340.2450.6.camel@linux.vnet.ibm.com \
    --to=zohar@linux.vnet.ibm.com \
    --cc=david.woodhouse@intel.com \
    --cc=dhowells@redhat.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --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 \
    /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).