Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756220AbbEUQvM (ORCPT ); Thu, 21 May 2015 12:51:12 -0400 Received: from mail-lb0-f178.google.com ([209.85.217.178]:35907 "EHLO mail-lb0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752173AbbEUQvI (ORCPT ); Thu, 21 May 2015 12:51:08 -0400 MIME-Version: 1.0 In-Reply-To: <9984.1432224618@warthog.procyon.org.uk> References: <31154.1431965087@warthog.procyon.org.uk> <555A88FB.7000809@kernel.org> <1432058889.3277.73.camel@infradead.org> <5348.1432061085@warthog.procyon.org.uk> <9984.1432224618@warthog.procyon.org.uk> From: Andy Lutomirski Date: Thu, 21 May 2015 09:50:46 -0700 Message-ID: Subject: Re: Should we automatically generate a module signing key at all? To: David Howells Cc: 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2255 Lines: 56 On Thu, May 21, 2015 at 9:10 AM, David Howells wrote: > Andy Lutomirski 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. Each module would just package its proof as part of the module file. After the kernel build is done, no one ever needs to see the whole tree at once. > >> > 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. > Sorry, I mis-spoke. I don't think we should use a hash for firmware, except possibly for Atomic-like systems, in which case we should really just turn off firmware signature verification entirely in favor of using IMA, dm-verity or similar to verify the entire root fs. --Andy > David -- Andy Lutomirski AMA Capital Management, LLC -- 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/