Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757126AbbEVUkp (ORCPT ); Fri, 22 May 2015 16:40:45 -0400 Received: from mail-ie0-f179.google.com ([209.85.223.179]:33995 "EHLO mail-ie0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756720AbbEVUkm (ORCPT ); Fri, 22 May 2015 16:40:42 -0400 MIME-Version: 1.0 In-Reply-To: <20150522141358.2581.qmail@ns.horizon.com> References: <20150522141358.2581.qmail@ns.horizon.com> Date: Fri, 22 May 2015 13:40:40 -0700 X-Google-Sender-Auth: Ob-5nnAmd9Xtptvna1nqe9MSOyo Message-ID: Subject: Re: Should we automatically generate a module signing key at all? From: Linus Torvalds To: George Spelvin Cc: David Howells , David Woodhouse , Linux Kernel Mailing List , LSM List , Andy Lutomirski , 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: 1828 Lines: 37 On Fri, May 22, 2015 at 7:13 AM, George Spelvin wrote: > > 1) Create a tool to canonicalize the kernel and modules, > stripping out the signatures before comparing them. This has > precedent in the way the prelink tool can un-prelink binaries > so that hashes can be verified. So I'd obviously prefer this, so that we have just one model for verification. I forget the exact details of the signature (and am way too lazy to look it up), but for the modules themselves, it's just appended to the module contents. So getting rid of the signature is literally just truncating the module to the original size. For the kernel image, it's a bit nastier, since the public key is just inserted into the object file as variables (system_certificate_list: "__cert_list_start...__cert_list_end:" and the length in "unsigned long system_certificate_list_size"). And because the size of the certificate list is variable, you can't just zero it out or anything like that to make things compare equal. Of course, even just zeroing that out will probably work as long as you use the *same* setup (ie kernels with just the one randomly generated key will probably have the same certificate size - I say "probably" because I didn't check how the encoding might affect it) But we might also simply decide to pack the keys differently. I'd personally be ok with it being in the initrd, for example, although for all I know that might screw up the people who actually want to use the BIOS secure booting thing (I don't know how much that verifies). Linus -- 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/