Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[josh@joshtriplett.org]

On Tue, Jul 28, 2015 at 11:44:21AM -0700, James Bottomley wrote:
> On Tue, 2015-07-28 at 11:36 -0700, josh@joshtriplett.org wrote:
> > On Tue, Jul 28, 2015 at 02:36:59PM +0100, David Howells wrote:
> > > Patches are in the works for the provision of signatures for firmware blobs
> > > for the kernel to check, thus allowing the kernel to act as gatekeeper on what
> > > firmware blobs get loaded where.
> > > 
> > > Note that it has been agreed that signatures will be in separate files to the
> > > firmware blobs so as not to potentially corrupt a blob by copying it to an OS
> > > that doesn't expect the signature.  Also, we don't want to modify the blob in
> > > case of IP.
> > > 
> > > We're currently using PKCS#7/CMS messages as the signature format since we
> > > have a PKCS#7 parser and verifier already in the kernel for kexec.
> > > 
> > > Patches have been proposed for inclusion in security/next that allow PKCS#11
> > > to be used to supply h/w keys to the sign-file program and to the kernel build
> > > process.
> > 
> > What's the advantage to using signatures here, rather than hashes?
> > 
> > What if we just made request_firmware take a cryptographically secure
> > hash, and verify that the firmware supplied by userspace has that hash?
> > Ideally, different firmware should have a different version, and often
> > the kernel driver knows the specific versions it works with.
> > 
> > The main advantage of signatures would be the ability to update the
> > firmware *without* updating the driver.  Is that a feature?  Is it
> > really a problem to add a hash to the driver?
> 
> So in that case, what's the advantage of separating the firmware from
> the driver?  If we can't update it without updating the driver, we could
> just build it in and save a huge amount of hassle.

Licensing, which is a large part of why we have request_firmware to
begin with.  Let's not make distribution kernel maintainers' lives more
difficult than they already are.

For the drivers I'm most familiar with, new versions of firmware have
new filenames and are requested from userspace in most-preferred to
least-preferred order.  The expectation of those drivers is that any
given firmware version should be binary-identical.

Are there drivers for which the expected firmware update cycle is *more*
rapid than the kernel release cycle?  That would be quite a surprise,
though not an unpleasant one.

- Josh Triplett