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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1432225809.2450.11.camel@linux.vnet.ibm.com>
Date:	Thu, 21 May 2015 12:30:09 -0400
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	David Howells <dhowells@...hat.com>
Cc:	"Luis R. Rodriguez" <mcgrof@...e.com>,
	Andy Lutomirski <luto@...nel.org>,
	linux-security-module@...r.kernel.org, james.l.morris@...cle.com,
	serge@...lyn.com, linux-kernel@...r.kernel.org,
	linux-wireless@...r.kernel.org, Kyle McMartin <kyle@...nel.org>,
	David Woodhouse <david.woodhouse@...el.com>,
	Seth Forshee <seth.forshee@...onical.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Joey Lee <jlee@...e.de>, Rusty Russell <rusty@...tcorp.com.au>,
	mricon@...nel.org, Michal Marek <mmarek@...e.cz>,
	Abelardo Ricart III <aricart@...nix.com>,
	Sedat Dilek <sedat.dilek@...il.com>, keyrings@...ux-nfs.org,
	Borislav Petkov <bp@...en8.de>, Jiri Kosina <jkosina@...e.cz>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFD] linux-firmware key arrangement for firmware signing

On Thu, 2015-05-21 at 16:51 +0100, David Howells wrote:
> Luis R. Rodriguez <mcgrof@...e.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/