Subject: Re: How do shared libs and kernel modules work?
To: None <travis@EvTech.com>
From: Mike Long <mike.long@analog.com>
List: tech-kern
Date: 06/21/1996 13:01:49
>Date: Thu, 20 Jun 1996 13:20:32 -0500
>From: Travis Hassloch x231 <travis@EvTech.com>
>For example:
>How are shared libs mapped into user processes? Via mmap?
Yes, shlibs use mmap(). Run a dynamic executable under ktrace(1) to
see for yourself.
>Are there code stubs to implement this, or are they implemented without
>stubs? Is the memory area used by the stubs reclaimed by the map?
I think it's a jump table.
>Does it involve any self-modifying code? Can the libraries have
>per-process as well as shared data? How is that done?
No self-modifying code (.text is read-only). Data pages are
copy-on-write: The process uses a shared copy of each page until it
writes to it, at which point that process gets its own copy.
>I'm aware of the memory layout for each process, so I'm interested
>to know if the code segments are mapped above the break, or
>"squeezed" between the code and data, or somehow overlaid on the code.
Wherever mmap() puts 'em.
>Likewise, what is the interface to LKMs?
modload(8) and friends.
>Are we susceptible to the same attacks SunOS is, in that hackers can load
>a stealth-module?
Not if you remove 'options INSECURE' from your kernel config. Then no
one (not even root) can load LKMs while the machine is multiuser.
>What kind of kernel functionality can be modified by an LKM?
Almost anything.
>What kind of info can survive a warm boot on the different ports?
That depends on the port. Usually the kernel message buffer survives.
>If this is all in manpages, feel free to just point me there (I can't
>search them from where I am currently).
See ld.so(8), link(7?), ld(1), mmap(2).
--
Mike Long <mike.long@analog.com> <URL:http://www.shore.net/~mikel>
VLSI Design Engineer finger mikel@shore.net for PGP public key
Analog Devices, CPD Division CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
Norwood, MA 02062 USA (eq (opinion 'ADI) (opinion 'mike)) -> nil