linux-kernel - Re: Should we automatically generate a module signing key at all?

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: <9984.1432224618@warthog.procyon.org.uk>
Date:	Thu, 21 May 2015 17:10:18 +0100
From:	David Howells <dhowells@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	dhowells@...hat.com, David Woodhouse <dwmw2@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	Michal Marek <mmarek@...e.cz>,
	Abelardo Ricart III <aricart@...nix.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Sedat Dilek <sedat.dilek@...il.com>, keyrings@...ux-nfs.org,
	Rusty Russell <rusty@...tcorp.com.au>,
	LSM List <linux-security-module@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>, Jiri Kosina <jkosina@...e.cz>
Subject: Re: Should we automatically generate a module signing key at all?

Andy Lutomirski <luto@...capital.net> wrote:

> Suppose you have a depth-k tree (i.e. up to 2^k modules).  We'll
> compute a 32-byte value Tree(d, i) for each d from 0 to k and each i
> from 0 to 2^d-1.  First you assign each module an index starting at
> zero (with the maximum index less than 2^k).  Then you hash each
> module.

Now you've got a different problem.  Unless you want to load the entire tree
in one go (in which case you're back to the kernel space issue), the kernel
now has to be able to pull it piecemeal from storage and the initramfs builder
either has to pull in the entire tree or select a subset.  Further, if the
initfamfs only contains a subtree, then the kernel has to be able to switch to
the full tree as some point.

> > And that doesn't include the issue of hashing the firmware blobs you might
> > need.
> 
> As before, that's true.  To verify firmware, either you need to hash
> it, use a termporary signing key, or use a long-term signing key.
> Choose your poison.  I still prefer a hash over a temporary signing
> key.

>From a distribution point of view, a hash list of all known firmware is icky
as all the kernels maintained by the distribution would have to be updated
each time a new firmware blob needs listing.  Further, all past known firmware
would have to be kept in the list and could never be discarded lest you
prevent someone's machine from booting.

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