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]

Date:	Fri, 22 May 2015 00:50:30 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Seth Forshee <seth.forshee@...onical.com>,
	linux-security-module@...r.kernel.org, james.l.morris@...cle.com,
	serge@...lyn.com, linux-kernel@...r.kernel.org,
	linux-wireless@...r.kernel.org,
	David Howells <dhowells@...hat.com>,
	Kyle McMartin <kyle@...nel.org>,
	David Woodhouse <david.woodhouse@...el.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Joey Lee <jlee@...e.de>, Rusty Russell <rusty@...tcorp.com.au>,
	zohar@...ux.vnet.ibm.com, mricon@...nel.org
Subject: Re: [RFD] linux-firmware key arrangement for firmware signing

On Wed, May 20, 2015 at 05:24:46PM +0100, One Thousand Gnomes wrote:
> On Wed, 20 May 2015 09:04:26 -0500
> Seth Forshee <seth.forshee@...onical.com> wrote:
> 
> > On Tue, May 19, 2015 at 10:02:32PM +0200, Luis R. Rodriguez wrote:
> > > This begs the question on how we'd manage keys for firmware signing on
> > > linux-firmare. Since the keys are x509 keys we need a CA. Based on some initial
> > > discussions it would seem we'd need the Linux Foundation to create a key, this
> > > would be embedded in the kernel and that key would be used to sign Kyle's key.
> > > Kyle would in turn use his key for signing linux-firmware files. David, Kyle,
> > > did I summarize this correctly ?
> > 
> > I raised the question of key revocation when we discussed this on irc,
> > but it wasn't answered to my satisfaction. If a key signed by the
> > kernel-embedded key is compromised, how can that key be revoked so that
> > it is no longer trusted?
> > 
> > Someone mentioned UEFI blacklists, which I don't know much about, but
> > not all systems have UEFI. The only reliable option that comes to mind
> > for me is an in-kernel blacklist of keys which should no longer be
> > trusted.
> 
> More to the point why do you want to sign firmware files ?

This would add support to firmware loading the same dog and pony show as used
by the module and kexec code, sharing as much dog and pony as is possible. This
also allows us to phase 802.11's dog and pony show which is sitting on the side all
on it own and implicates distros to do more work.

 Luis
--
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/