Subject: Re: Handling multiple lkm's
To: Matthias Drochner <email@example.com>
From: Chris G. Demetriou <cgd@Pa.dec.com>
Date: 09/15/1997 11:46:17
> I remember you've anready brought this up at one occasion.
> It's elegant, and it would make LKMs more save and secure.
> But perhaps the code which does the real linking can still be
> outside the kernel, with some access to the kernel's address
> Do you know how DEC's /sbin/loader works?
/sbin/loader is the RTLD-equivalent. Yes, I know more or less how it
works (because I read the paper from OSF which describes how the OSF
loader works, and the DEC OSF1/Digital UNIX /sbin/loader seems to be
derived fro mthat).
As far as I can tell, it's completely orthogonal to loadable kernel
modules, and the relevant manual pages seem to agree on this.
That having been said: Why put the "code which does the real linking"
outside the kernel? The "average" a.out shared loader seems to be
about 65k text + data (OK, OK, average of the i386 and arm32 shared
loaders 8-). A fair chunk of that is code which isn't needed in the
kernel: dl*() implementations, code to handle basic dynamic linker
startup, etc. I think it's quite reasonable to say "if you want LKM
functionality, you have to pay 50k for a loader in your kernel."
(Note that the rest of the LKM machinery -- much more is needed than
is there now, for a good implementation -- will cost something more,
as well.) Theoretically, the benefits of a complete LKM
implementation would outweigh that (by a lot), anyway, right? 8-)
Also, if you do the actual linking outside the kernel, then you
sacrifice what security you can have by doing it inside the kernel.