Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756043AbbESSvd (ORCPT ); Tue, 19 May 2015 14:51:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49715 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751917AbbESSvb (ORCPT ); Tue, 19 May 2015 14:51:31 -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: References: <31154.1431965087@warthog.procyon.org.uk> <555A88FB.7000809@kernel.org> <1432058889.3277.73.camel@infradead.org> To: Andy Lutomirski Cc: dhowells@redhat.com, David Woodhouse , Linus Torvalds , Andy Lutomirski , Michal Marek , 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: <5347.1432061085.1@warthog.procyon.org.uk> Date: Tue, 19 May 2015 19:44:45 +0100 Message-ID: <5348.1432061085@warthog.procyon.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1215 Lines: 27 Andy Lutomirski wrote: > The actual runtime code needed to implement a hash tree solution is > maybe twenty lines. The bzImage will be smaller, But the initramfs image will be bigger because it will have to carry the entire module hash list just in case any particular module needs to get loaded from the initramfs. You have to carry the entire hash set so that you can hash it and compare against the one hash in the vmlinux file. And that doesn't include the issue of hashing the firmware blobs you might need. > With your proposal, I need to trust that whoever built the actual > running kernel image really did throw away the key. If they didn't, > then under whatever threat model requires that I enable module > verification, I'm screwed -- the bad guy has the private key. Each private key is used for one single kernel, so if they steal one, you can blacklist it if you have the capability (eg. UEFI) and change your kernel. 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/