Date:	Thu, 21 May 2015 20:14:38 +0300
From:	Petko Manolov <petkan@...-labs.com>
To:	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Cc:	"Woodhouse, David" <david.woodhouse@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"seth.forshee@...onical.com" <seth.forshee@...onical.com>,
	"zohar@...ux.vnet.ibm.com" <zohar@...ux.vnet.ibm.com>,
	"mricon@...nel.org" <mricon@...nel.org>,
	"dhowells@...hat.com" <dhowells@...hat.com>,
	"rusty@...tcorp.com.au" <rusty@...tcorp.com.au>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>,
	"jlee@...e.de" <jlee@...e.de>, "kyle@...nel.org" <kyle@...nel.org>,
	"gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>,
	"james.l.morris@...cle.com" <james.l.morris@...cle.com>,
	"mcgrof@...e.com" <mcgrof@...e.com>,
	"serge@...lyn.com" <serge@...lyn.com>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>
Subject: Re: [RFD] linux-firmware key arrangement for firmware signing

On 15-05-21 10:02:36, gregkh@...uxfoundation.org wrote:
> On Thu, May 21, 2015 at 04:03:02PM +0000, Woodhouse, David wrote:
> > 
> > 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
> > :)
> 
> We do?  What devices want this?  That's really a bad hardware design to trust 
> the kernel to get all of this correct.

Which means nearly all hardware we use today is badly designed... :)

> And I say this as someone who is currently working on a hardware design that 
> does just this for a very tiny device.  It's only a few hundred bytes of 
> firmware size to be able to do proper key verification that the firmware image 
> is correct and can be "trusted".

And a "few" more bytes for the hash algorithm along the one for asymmetric key 
computation and management. :)

> > 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.
> 
> Again, why have a detached signature and not just part of the firmware blob?  
> The device needs to be caring about this, not the kernel.

In ideal world this is what should be done.  However, adding the simplest (read 
slowest) MD5 implementation requires a few K's of ram on 32bit cpu.  MD5 is 
dead.  So we need SHA-something, which isn't smaller in terms of code size.  Add 
the asymmetric cryptography to the picture and we've already put away all 
vendors.

> As the kernel doesn't know/care about what the firmware blob really is, I 
> don't see why it should be caring about firmware signing as that's a binary 
> running on a separate "computer".  Do we want to take this the next logical 
> step further and start requiring networked devices to attest their kernels are 
> signed correctly before we can talk to them?

I think it is enough for you to know that your iwlwifi's firmware comes from 
Intel and not from a random Internet punk.  If you trust Intel with your wifi 
adapter you probably trust them to write good firmware for it.


		Petko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists