Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S269852AbUJMVT5 (ORCPT ); Wed, 13 Oct 2004 17:19:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S269853AbUJMVT5 (ORCPT ); Wed, 13 Oct 2004 17:19:57 -0400 Received: from mx1.redhat.com ([66.187.233.31]:31928 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S269852AbUJMVTu (ORCPT ); Wed, 13 Oct 2004 17:19:50 -0400 From: David Howells In-Reply-To: <1097626296.4013.34.camel@localhost.localdomain> References: <1097626296.4013.34.camel@localhost.localdomain> <1096544201.8043.816.camel@localhost.localdomain> <1096411448.3230.22.camel@localhost.localdomain> <1092403984.29463.11.camel@bach> <1092369784.25194.225.camel@bach> <20040812092029.GA30255@devserv.devel.redhat.com> <20040811211719.GD21894@kroah.com> <1092097278.20335.51.camel@bach> <20040810002741.GA7764@kroah.com> <1092189167.22236.67.camel@bach> <19388.1092301990@redhat.com> <30797.1092308768@redhat.com> <20040812111853.GB25950@devserv.devel.redhat.com> <20040812200917.GD2952@kroah.com> <26280.1092388799@redhat.com> <27175.1095936746@redhat.com> <30591.1096451074@redhat.com> <10345.1097507482@redhat.com> <1097507755.318.332.camel@hades.cambridge.redhat.com> <1097534090.16153.7.camel@localhost.localdomain> <1097570159.5788.1089.camel@baythorne.infradead.org> To: "Rusty Russell (IBM)" Cc: David Woodhouse , Greg KH , Arjan van de Ven , Joy Latten , lkml - Kernel Mailing List Subject: Re: Fw: signed kernel modules? User-Agent: EMH/1.14.1 SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Date: Wed, 13 Oct 2004 22:18:38 +0100 Message-ID: <27277.1097702318@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2057 Lines: 55 > Write the code. Then come back and tell me it "isn't that hard". It isn't that hard. > Let me make this clear: I refuse to include any solution which doesn't > protect against accidental, as well as deliberate, corruption. This > means your "canonicalization" code has to be very, very paranoid about > not trusting the data until the signature is verified. The current code > does very simple checks then completely trusts the module contents, > especially the section headers: to make signatures worth anything, your > code must not do this. I've made a patch available to permit module signing in the kernel. http://people.redhat.com/~dhowells/modsign/modsign-269rc4mm1.diff.bz2 I've also put up some example keys: http://people.redhat.com/~dhowells/modsign/kernel.pub http://people.redhat.com/~dhowells/modsign/kernel.sec http://people.redhat.com/~dhowells/modsign/key.h The first two need to go into your kernel root dir; the third needs to go into crypto/signature/. key.h can be generated by something like: gpg --homedir /tmp --export --keyring ./kernel.pub Red | scripts/bin2c ksign_def_public_key __initdata >crypto/signature/key.h You'll need to build the module extractor manually: make -C scripts/modsign mod-extract And sign modules manually: scripts/modsign/modsign.sh net/rxrpc/rxrpc.ko I'd like to automate this in the kernel build process, but it's not immediately obvious how to do this with the kernel's current Makefile stuff. There's also the problem of how to get the keys in the first place. In the Fedora RPMs the spec file generates a single new key pair for every build and discards it later after generating key.h, but that may not be appropriate in all cases (you can have multiple keys, and you may want to get them from a GPG keyring somewhere). 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/