Re: The disappearing sys_call_table export.

[ebiederm@xmission.com (Eric W. Biederman)]

Steffen Persvold <sp@scali.com> writes:

> On 7 May 2003, petter wahlman wrote:
> 
> >  
> > It seems like nobody belives that there are any technically valid
> > reasons for hooking system calls, but how should e.g anti virus
> > on-access scanners intercept syscalls?
> > Preloading libraries, ptracing init, patching g/libc, etc. are
> > obviously not the way to go.
> > 
> 
> Well, for a system wide system call hook, a kernel mechanism is necessary 
> (and useful too IMHO). However for our usage (MPI) it is enough to know 
> when the current process calls either sbrk(-n) or munmap glibc functions, 
> thus it is sufficient to implement some kind of callback functionality for 
> certain glibc functions, sort of like the malloc/free hooks but on a more 
> general basis since some applications doesn't use malloc/free but 
> implement their own alloc/free algorithms using the syscalls (one example 
> is f90 apps).
> 
> Ideas anyone ?

I think the complete list of functions to be hooked needs to be at least:
mmap(MAP_FIXED), munmap, sbrk(-n), shmat, shdt.  The mapping cases
are needed because a mmap(MAP_FIXED) can implicitly unmap an area under
them, before the new address is used.

This is not a kernel issue as this is purely a user space problem,
the kernel provides all of the necessary functionality.

I suspect what is needed is something like:
int on_unmap(void (*func)(void *start, size_t length, void *), void *arg);

With the function called before the unmap actually occurs, that way
the multi thread case is safe.  It needs to be built so that multiple libraries
can cooperate cleanly.

Ulrich what do you think.  Is the above function reasonable?
Something like it is needed to manage caches of pinned memory for high
performance kernel bypass libraries.

Eric