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

[David Howells <dhowells@redhat.com>]

Andy Lutomirski <luto@amacapital.net> wrote:

> > The top patch here:
> >
> >         http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=modsign-pkcs7-2
> >
> > allows demand loading of keys based on their SKID into a special keyring from
> > which they get erased after an arbitrary 3 minutes of existence.  This key can
> > then be used to verify a signature instead of using the primary system keyring
> > used for module signature checking.
> >
> > Building on this, a driver could have a SKID compiled into it which could then
> > be used to load a key for request_firmware() to use in verifying the blobs
> > that that driver requires.
> >
> 
> Who signs the vendor key?

From the arguments so far presented, the vendor - but possibly allowing the
linux-fimrware manager to sign in lieu if the admin of a machine running this
stuff allows it.

> Why are we bothering loading device vendor keys into a keyring in the
> first place?

Caching.  Some drivers need more than one firmware blob.

> Why not just have an API to request firmware either signed by a literal key
> provided by the driver *or* whatever keys the system trusts in general for
> firmware signing?

By "a literal key provided by the driver" I presume you mean that the parts of
the key (perhaps an X.509 cert) are actually compiled into the driver.  Yes we
could do this quite easily - key_create_or_update() will turn a binary key
blob into a struct key * that can then be used.  Do we want ~1.5K or more of
undiscardable data per key adding to each module that wants to load firmware,
particularly if it needs to carry several keys just in case one gets revoked?

Objections have been raised against using general keys for firmware signing.

David