[Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

On Tue, 2015-07-28 at 11:36 -0700, josh at 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.

James