Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755739AbbEVALW (ORCPT ); Thu, 21 May 2015 20:11:22 -0400 Received: from mail-la0-f48.google.com ([209.85.215.48]:36543 "EHLO mail-la0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754061AbbEVALR (ORCPT ); Thu, 21 May 2015 20:11:17 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150521235430.24546.qmail@ns.horizon.com> From: Andy Lutomirski Date: Thu, 21 May 2015 17:10:54 -0700 Message-ID: Subject: Re: Should we automatically generate a module signing key at all? To: Linus Torvalds Cc: George Spelvin , David Howells , David Woodhouse , Linux Kernel Mailing List , LSM List , petkan@mip-labs.com, "Theodore Ts'o" , Mimi Zohar 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: 1791 Lines: 40 On Thu, May 21, 2015 at 5:03 PM, Linus Torvalds wrote: > On Thu, May 21, 2015 at 4:54 PM, George Spelvin wrote: >> >> The annoying thing is that it's a two-pass process: the kernel has to >> have the hashes of ALL of the modules to generate the sibling hashes >> for ANY of them. > > It's also very annoying because the whole build gets much nastier, > particularly if you want to have modules in external trees. > > In short, I don't see any actual *advantages* over just using signed > modules. Signing is much more flexible, and thanks to that extra > indirection (the signing key), there are no ordering constraints on > generating modules vs the kernel. > > I realize that people have political objections to signing, but it's > the better technology, for chissake! I still claim that reproducible builds are technical, not political. CONFIG_MODULE_SIGN_ALL=y is literally the only thing in the kernel that's incompatible with reproducible builds. Yes, the build gets messier, but it's not that bad. It's even less bad if we'd be willing to accept kmod changes as a prerequisite (so kmod would generate the proofs on the fly from a little database instead of appending the proof to each .ko file There's even a (nasty) implementation: https://wiki.debian.org/SameKernel I'm sure we could make it much cleaner (and even make it a normal config option that would generate a bzImage that depends only on the kernel tree and exact toolchain version) if we put a bit of effort in. --Andy -- 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/