Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264503AbUJNNJ2 (ORCPT ); Thu, 14 Oct 2004 09:09:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264639AbUJNNJ2 (ORCPT ); Thu, 14 Oct 2004 09:09:28 -0400 Received: from chaos.analogic.com ([204.178.40.224]:2688 "EHLO chaos.analogic.com") by vger.kernel.org with ESMTP id S264503AbUJNNJX (ORCPT ); Thu, 14 Oct 2004 09:09:23 -0400 Date: Thu, 14 Oct 2004 09:08:27 -0400 (EDT) From: "Richard B. Johnson" Reply-To: root@chaos.analogic.com To: David Howells cc: Roman Zippel , "Rusty Russell (IBM)" , David Woodhouse , Greg KH , Arjan van de Ven , Joy Latten , lkml - Kernel Mailing List Subject: Re: Fw: signed kernel modules? In-Reply-To: <17271.1097756056@redhat.com> Message-ID: References: <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> <27277.1097702318@redhat.com> <16349.1097752! 349@redhat.com> <17271.1097756056@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3386 Lines: 86 On Thu, 14 Oct 2004, David Howells wrote: > > > I'm trying to understand the reason to stuff this into kernel. Why can't > > this check be done before loading the module into the kernel? If you don't > > trust insmod, how can you trust the build system? > > (1) insmod isn't the only way to load a module. > > (2) This helps limit what an intruder can do; particularly if you combine it > with other measures. > > (3) Who says the kernel RPM is built on the same machine as the one you > really want to deploy this on for the added protection? > > David I think I smell something. We had a perfectly-good way of loading modules. About 99 percent of the code was in user-space. Now, 99 percent of the code is in the kernel. Why? I think this is to "prove" that kernel modules are "kernel" things that require kernel licensing. So, some misguided persons that think they are lawyers and/or are being led by misguided persons that are lawyers??? And, for this we get lawyer-bloat in the kernel. The new build system sucks. The new kernel module loading scheme sucks, pure and simple. In fact, Linux is degenerating into a trash bin of "me-too" hacks. I am now back to Linux-2.4.26 after trying to run a new standard distribution of "Red Hat Fedora" on a completely separate hard-disk. I had to rebuild everything for the third time (reinstall all software) and I'm thoroughly pissed. The Linux-2.6.whatever that comes with that garbage trashes my SCSI disks if I mount them, making them unusable and requiring a complete reinstall of everything. So, keep it up. In a few years Linux will be remembered as a joke. Somebody may fork off something near Linux-2.4.x and make a professional operating system out of it, but right now it's taken a rapid down-turn into the toilet. I strongly suggest that you stop corrupting the kernel and kernel modules and go back to the tried and true Linux-2.4.n methods. Sure there are some bugs (races) that may need to be fixed in the older module loading scheme, but its been workable for many years. The new kernel build environment is also corrupt. On this system, it takes 45 seconds to perform: make clean make bzImage With the new build system, same disk, same kernel configuration, it takes 14 minutes. And, you can't even see what the compiler doesn't like. The build system generates separate command-files, hidden from `ls` by having them start with ".", for every source-file and link action, plus it even makes hidden subdirectories. The modules build even generates its own 'C' source-file for some junk that the new `insmod` needs. It's crap, pure and simple. Damn crap. All of it. This is the best example of technological degeneration I've seen in my 40+ years of professional involvement in engineering. Somebody may write a book and the only fame that will remain will be visual impact of a smoking hole that was once a viable operating system borne on the ideas of thousands world-wide. I qoute; "Have you no shame?" Cheers, Dick Johnson Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips). Note 96.31% of all statistics are fiction. - 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/