Syscalls and modules

Adam Langley (aglangley@geocities.com)
Sun, 18 Jul 1999 09:49:14 +0000

I notice from kernel traffic that there has been some discussion about implimenting syscalls from loadable modules. At the turn of the year I wrote a wrapper around sys_call_table (which can, itself, be a module) which allows other modules to 'hook' syscalls without ever stepping on each other. I wrote because someone asked for it - it builds fine on 2.2.10-ac7 and runs without any faults (at least on i386). I'm not a kernel-hacker but someone who is might find it usful as a base to work on.

Rather then flood the list I've uploaded sccm.tgz to www.geocities.com/ResearchTriangle/System/4288/sccm.tgz.

P.S: I've just noticed it seems to upset procfs on unload - it might just be my system. Don't insmod this on a system you wouldn't want to cycle.

----snip from sccm.txt----
Notes on design
---------------

SCCM keeps a linked list of syscall_chain structs (pointed to by
syscall_chain_root), each describes a hooked syscall and a double linked
list of syscall_link structs.

Each syscall_link describes a hook to that syscall. When a hook is moved the
pointers in the hooking code (syscall_link.pnt) are updated with new
addresses of the next thing to call.

An entry is made in /proc called sccm which returns a string on reading and
has an ioctl. By calling the ioctl the version, number of chains, last time
of update and each chain can be returned.

A chain can also be force removed, this resores the sys_call_table entry and
dealloc's the chain. This should onbly be done under dire circumstances
(e.g. a module has unloaded without calling sccm_remove_link)
----end snip----

I don't subscribe to l-k. Reply to aglangley@geocities.com

Thanks

Adam Langley

-- 
Microsoft is not the answer.
Microsoft is the question.
NO (or Linux) is the answer.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/