Re: Fw: signed kernel modules?

[Richard B. Johnson]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/