Date: Mon, 17 Apr 1995 14:49:41 -0400 (EDT) From: "House of Debuggin'" <wpaul@skynet.ctr.columbia.edu> To: terry@cs.weber.edu (Terry Lambert) Cc: freebsd-hackers@FreeBSD.org Subject: Re: support for Xircom PCMCIA Ethernet adapters? Message-ID: <199504171849.OAA02953@skynet.ctr.columbia.edu> In-Reply-To: <9504171646.AA08223@cs.weber.edu> from "Terry Lambert" at Apr 17, 95 10:46:34 am
next in thread | previous in thread | raw e-mail | index | archive | help
They say this Terry Lambert person was kidding when he wrote:
> > Somehow this reminds me of an old Steve Martin routine. ("Yes, if you
> > follow these two simple little steps, you can have a million dollars
> > and *never* pay taxes. First, get a million dollars. Second...")
>
> No, it's more like "clean room coding is possible, but free software
> projects typically do not engage in the practice because it requires
> two or more people to work together on something". 8-).
Yeah, well... It's not like I wouldn't mind working together with someone,
but there don't seem to be that many FreeBSD fans here at Columbia. (There
are several Linux fans though, and I take more than my fair share of abuse
from them.)
>
> [ ... on to loadable modules ... ]
>
> > - user loads a module (modload -e pppattach if_ppp_mod.o)
> > - LKM_READY comes up, and we go to call the entry function
> > - call to entry returns with private.lkm_any == NULL -- module is bogus!
>
> FORCE UNLOAD OF MODULE WITH ERROR MESSAGE "module has no identification".
Well, no, see, that's just it: by the time I get to this point (entry
has been called) I *can't* force an unload of the module without
panicking the system. The module has already wired itself in: from
here on, I'm dead meat.
> >
> > It's sort of a 'chicken and the egg' problem: I have to detect the bad
> > module and discard it before I call its entry point, but I have to
> > call its entry point before I can detect and discard it.
>
> Assuming relocation in the kernel, there are two options. The first
> is to allow multiple symbols in the module to be imported by the kernel.
> The current limitation on this is on the basis of the a.out format that
> the module is stored in allowing only a single symbol to be resolved.
Uh, yeah... right.
> The second approach would be to ammend the routines available to the
> module from the single multiplexed entry point to include a seperate
> registration entry point from the "attach" entry point so you can
> insert a validation step into the load/register-init, changing it into
> load/register/validate/init.
This sounds like something I could pull off. It occurs to me that it might
be possible to perform validation in the LKM_RESERVE stage, but I need
to come up with a proper validation method. One of the things
that gets passed to the kernel in the reserv structure is the name of the
linked module (modout -- the name of the module without the .o extension).
Right now, the kernel does nothing with this name. What I want to do is
use it as an identifier and check that a module with the same name
doesn't already exist before passing control to the entry point.
Unfortunately this won't offer any protection if the user renames the
module. A checksum would work much better, but I haven't figured out
a way to compute the checksum yet. I think this would be a good idea
in general: the lkmexists() function checks for pre-existing modules
simply by comparing names, and as such it can easily be fooled: I could
make a duplicate of an existing module and load it using a different name
and lkmexists() would never know the difference.
Even though you and I both know better than to attempt something like this,
the kernel has to be smart enough to protect itself from such abuse.
> Changing the load mechanism itsel is the only way -- I think Garrett (who
> has hacked on that code more recently than me, I assure you) would agree,
> although I don't know if he still disagrees with the idea of putting the
> loader in the kernel itself or not. 8-).
I think it should also be smart enough to protect itself from this kind
of abuse too. :)
> Terry Lambert
> terry@cs.weber.edu
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
-Bill
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~T~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Bill Paul (212) 854-6020 | System Manager
Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Møøse Illuminati: ignore it and be confused, or join it and be confusing!
~~~~~~~~~ FreeBSD 2.1: "We'll kick your operating system's ass!" ~~~~~~~~~~
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504171849.OAA02953>