Re: [RFD] linux-firmware key arrangement for firmware signing

[Mimi Zohar <zohar@linux.vnet.ibm.com>]

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