Subject: Re: LKM support
To: Bill Studenmund <skippy@macro.stanford.edu>
From: Michael Graff <explorer@flame.org>
List: tech-kern
Date: 11/08/1996 15:03:26
Bill Studenmund <skippy@macro.stanford.edu> writes:

> > I was going to suggest the following for this sort of thing:
> > 
> > (1) a command, run at securelevel 0, which does an md5 hash and remembers
> >     the size and name of an LKM, and gives this to the kernel.
> > (2) a userland daemon.  If you want dynamic loading, you run this.
> > (3) a command to load a module which was previously identified in the
> >     kernel.
> > 
> > This would more or less remove security holes from the LKM loading after
> > securelevel 0 is gone part I believe.
> 
> This idea sounds quite workable. I think you're right about closing
> security holes. Would it be reasonable to support multiple versions of the
> same module? The idea would be to support testing of a new module in a
> "real" environment.

Sure.  Just register both at securelevel 0 and load the non-default
one by hand before use.

Also, it was pointed out after talking to a coworker that remembering
the exact state of the inode might be good enough.  That would remove the
need for MD5 in the kernel, although I can see a use for MD5 in other things
as well, like tcp sequence numbers...

--Michael