Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268977AbUJKPSN (ORCPT ); Mon, 11 Oct 2004 11:18:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268972AbUJKPQx (ORCPT ); Mon, 11 Oct 2004 11:16:53 -0400 Received: from mx1.redhat.com ([66.187.233.31]:36768 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S269072AbUJKPMC (ORCPT ); Mon, 11 Oct 2004 11:12:02 -0400 From: David Howells In-Reply-To: <1096544201.8043.816.camel@localhost.localdomain> References: <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> To: "Rusty Russell (IBM)" Cc: dwmw2@redhat.com, Greg KH , Arjan van de Ven , Joy Latten , linux-kernel@vger.kernel.org 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: Mon, 11 Oct 2004 16:11:22 +0100 Message-ID: <10345.1097507482@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1696 Lines: 39 > Sign the whole thing. Use a signature format which doesn't suck (ASN1 > parsing in the kernel? Hmm...). Have your build system spit out two > RPMs, one with full debug modules, and one without. This is not rocket > science. You make it sound so simple... I've adapted my patches to sign the whole thing 'cos I know you're just going to fight it otherwise[*]:-) However, I'm having trouble getting it working... I didn't realise just how many strips get applied to the module before it gets loaded into the kernel (when making initrd's for instance):-/ The old way of just signing the stuff that is required is definitely more robust against all the valid things people want to be able to do to modules, especially those involving strip for the purposes of producing initrds and stuff. Some of this is done upon or after installation where it isn't possible to get hold of the private key[**]. I could make the signature section non-ALLOC, but that would just mean that any stripped module is unsigned. Since much of ELF is an arch-independent format, I think my latest "signing only the requisite bits" method _is_ sufficient. You say that you can see a gaping security hole - please elaborate... it may not be what you think. David [*] You're still wrong, of course, but that's your prerogative:-) [**] Before anyone suggests it, no, I'm not going to ship the private key just so that the module can be re-signed after stripping. - 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/