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]

Date:	Tue, 19 May 2015 09:53:51 +0100
From:	David Howells <dhowells@...hat.com>
To:	Andy Lutomirski <luto@...nel.org>
Cc:	dhowells@...hat.com,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Michal Marek <mmarek@...e.cz>,
	David Woodhouse <dwmw2@...radead.org>,
	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@...nel.org> wrote:

> I think we should get rid of the idea of automatically generated signing keys
> entirely.  Instead I think we should generate, at build time, a list of all
> the module hashes and link that into vmlinux.

Just in Fedora 21:

warthog>rpm -ql kernel-modules | grep [.]ko | wc -l
3604
warthog>rpm -ql kernel-modules-extra | grep [.]ko | wc -l
480

So that's >4000 modules, each signed with a SHA256 sum (32 bytes).  That's
more than 125K of unswappable memory.  And it's uncompressible as Dave pointed
out.  And that doesn't include any metadata to match a module to a digest, but
rather assumes we just scan through the entire list comparing against each
SHA256 sum until we find one that matches.

> Then, if anyone actually wants to use a public key to verify modules, they can
> build the public key into a module as opposed to dragging all of the public
> key crud into the main kernel image.

A chunk of the 'public key crud' has to be in the kernel for other reasons
(the integrity stuff, I think, which has to start before you load any modules)
and the public key stuff is used for other things too (such as kexec and may
well be used for firmware validation in future) - though that doesn't preclude
it being modularised, it does mean that you are likely to load it anyway in
future.

> We autogenerate module_hashes.ko

This just makes things worse.  I suspect all distributions would have to load
it anyway - and you don't really win as it will just make the initramfs bigger
instead of the bzImage.

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/