Subject: Re: Apollo keyboard, serial drivers (announce)
To: Bill Studenmund <>
From: Chris G. Demetriou <>
List: tech-kern
Date: 04/16/1997 15:36:03
> > 
> > > > There's a problem even with the lkm approach:
> > > > 
> > > > You only can load LKMs during single user mode.
> > > 
> > > Why is this?  I don't understand...
> > 
> > Because if you can load LKMs at a higher security level, those LKMs
> > can then disable the security level checking.  (LKMs loaded at
> > single-user mode, or from rc, can reasonably be considered 'trusted.')
> I think this has been mentioned before (and is a slight subject drift),
> but what about the idea of "Identifying" lkm's to the system from rc,
> and then letting root load them later.

So, I'm not particularly keen on this.

Once all ports move to ELF, I'd like to see a scheme in which a small
ELF shared library loader is put into the kernel (#ifdef LKM, of
course 8-).  That would allow it to do all the relocations, etc., and
remove the need to trust the linker to do the right thing.

This allows you to do all sorts of 'interesting' things, like:

	(1) software fault isolation, if you want to put something
	    that complex into your kernel,

	(2) it allows you to easily get message digests of 'trusted'
	    modules, and stuff them into the kernel to be allowed
	    later.  (the acceptable digests could be loaded into the
	    kernel from rc.)

	(3) it allows you to create 'trusted people/groups' who are
	    known to release "good" LKMs, which can be
	    cryptographically signed and verified. (acceptable keys
	    could be loaded into the kernel from rc.)

It also can solve problems about symbol loading, symbol finding, etc.

You can do things like the latter two points above if you're willing
to do something like pre-link the modules against the kernel at
rc-time, then 'sign' them as valid (or whatever), but that's really
just a hack.

Given that the entirely LKM framework needs to be heavily reworked
(better support for loading multiple types of things at once;
reference counting all around, so that you know when it's safe to
remove modules; 'real device' driver loading and attachment, etc.),
the person doing it might as well do the architecturelly sound thing,
rather than the quick hack.