Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755425AbbEURPO (ORCPT ); Thu, 21 May 2015 13:15:14 -0400 Received: from lan.nucleusys.com ([92.247.61.126]:44004 "EHLO zztop.nucleusys.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752383AbbEURPK (ORCPT ); Thu, 21 May 2015 13:15:10 -0400 Date: Thu, 21 May 2015 20:14:38 +0300 From: Petko Manolov To: "gregkh@linuxfoundation.org" Cc: "Woodhouse, David" , "linux-kernel@vger.kernel.org" , "seth.forshee@canonical.com" , "zohar@linux.vnet.ibm.com" , "mricon@kernel.org" , "dhowells@redhat.com" , "rusty@rustcorp.com.au" , "linux-security-module@vger.kernel.org" , "jlee@suse.de" , "kyle@kernel.org" , "gnomes@lxorguk.ukuu.org.uk" , "james.l.morris@oracle.com" , "mcgrof@suse.com" , "serge@hallyn.com" , "linux-wireless@vger.kernel.org" Subject: Re: [RFD] linux-firmware key arrangement for firmware signing Message-ID: <20150521171438.GK18164@localhost> Mail-Followup-To: "gregkh@linuxfoundation.org" , "Woodhouse, David" , "linux-kernel@vger.kernel.org" , "seth.forshee@canonical.com" , "zohar@linux.vnet.ibm.com" , "mricon@kernel.org" , "dhowells@redhat.com" , "rusty@rustcorp.com.au" , "linux-security-module@vger.kernel.org" , "jlee@suse.de" , "kyle@kernel.org" , "gnomes@lxorguk.ukuu.org.uk" , "james.l.morris@oracle.com" , "mcgrof@suse.com" , "serge@hallyn.com" , "linux-wireless@vger.kernel.org" References: <20150520140426.GB126473@ubuntu-hedt> <20150520172446.4dab5399@lxorguk.ukuu.org.uk> <20150520164613.GD10473@localhost> <20150521044104.GH22632@kroah.com> <20150521054101.GA15037@localhost> <20150521061453.GC30864@kroah.com> <1432213521.4230.43.camel@linux.vnet.ibm.com> <20150521154508.GA11821@kroah.com> <1432224181.8004.7.camel@intel.com> <20150521170236.GC12932@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150521170236.GC12932@kroah.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -1.0 (-) X-Spam-Report: Spam detection software, running on the system "zztop.nucleusys.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 15-05-21 10:02:36, gregkh@linuxfoundation.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. [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2773 Lines: 55 On 15-05-21 10:02:36, gregkh@linuxfoundation.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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/