lkml.org 
[lkml]   [2015]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFD] linux-firmware key arrangement for firmware signing
From
Date
On Thu, 2015-05-21 at 16:51 +0100, David Howells wrote:
> Luis R. Rodriguez <mcgrof@suse.com> wrote:
>
> > I had this planned out because regulatory.bin used its own simple RSA key
> > with no x509 juju magic. I also envisioned it being easier for Kyle for
> > instance to use his own PGP key to sign linux-firmware files to start off
> > with than some complex x509 thing. Based on discussions with David, Seth,
> > and Kyle though it seems we were going to be happy with trusting Kyle's key
> > for regulatory.bin, since that will be done Kyle might as well sign all
> > linux-firmware files and folks who trust that can use it.
>
> To go down the signature root, what the kernel needs is:
>
> (1) A way to get a key into the kernel. We're currently using X.509 for this
> for module signing and kexec.
>
> (2) A way to get a signature into the kernel with sufficient metadata to
> select the key to use. Currently, kexec uses PKCS#7 for this and module
> signing uses a private format which I'm intending to change to PKCS#7.
>
> For firmware, I think Andy is right and we also need to include in the
> metadata something that says under what circumstances the firmware can be
> used - likely the name that is passed to request_firmware() - which must
> also be included in the digested data.
>
> I don't believe that module signing actually requires a hint of this type
> since we have to permit insmod to work and there won't be a hint we can
> trust. Besides, once verified, modules have to be loadable by the module
> loader which is probably a sufficient restriction in itself.
>
> I don't believe that kexec signing requires a name hint either since I
> think the only restriction on what we're allowed to kexec is that it must
> be bootable from the beginning - and must be a PE binary on x86 type
> platforms.
>
> I do have patches to parse PGP key data and add the public keys found therein
> onto the kernel keyring, but that would mean adding an extra key data parser.
>
> You could probably do this with the integrity functions - but turning them on
> has a performance cost and you have to load things in the right order as I
> understand it.

The only ordering is loading the keys before verifying the signatures.
Have you recently done any performance testing?

Mimi



\
 
 \ /
  Last update: 2015-05-21 19:01    [W:0.102 / U:0.948 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site