Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755409AbbESIzF (ORCPT ); Tue, 19 May 2015 04:55:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60666 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753711AbbESIy5 convert rfc822-to-8bit (ORCPT ); Tue, 19 May 2015 04:54:57 -0400 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <555A88FB.7000809@kernel.org> References: <555A88FB.7000809@kernel.org> <31154.1431965087@warthog.procyon.org.uk> To: Andy Lutomirski Cc: dhowells@redhat.com, Linus Torvalds , Michal Marek , David Woodhouse , Abelardo Ricart III , Linux Kernel Mailing List , Sedat Dilek , keyrings@linux-nfs.org, Rusty Russell , LSM List , Borislav Petkov , Jiri Kosina Subject: Re: Should we automatically generate a module signing key at all? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29741.1432025631.1@warthog.procyon.org.uk> Content-Transfer-Encoding: 8BIT Date: Tue, 19 May 2015 09:53:51 +0100 Message-ID: <29742.1432025631@warthog.procyon.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1804 Lines: 42 Andy Lutomirski 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/