On Sun, Feb 25, 2007 at 02:32:07PM +0100, Fernando Apestegu?a wrote: > On 2/25/07, Liran <liransgarage@xxxxxxxxx> wrote: > >Avishay Traeger <atraeger <at> cs.sunysb.edu> writes: > > > >> Does it need to be in the kernel? A couple user space options are: > >> - use ptrace, but that has some limitations (you can only trace child > >> processes). > >> - use LD_PRELOAD > >> > >> To do it from the kernel, you can create a module that: > >> - on loading, replaces the existing system call pointers to functions > >> that collect the desired data and calls the original functions. > >> - on unloading, restores the original system call pointers. > > > > > >I will examine the LD_PRELOAD idea, seems like it could work. > >Regarding the kernel module idea by replacing an existing function, > >doing some stuff and then restoring the original system call - is > >this a normal way of approaching it? Would it be considered ok? > > No. It is dirty and unsafe in SMP systems. If you want to do that use > kprobes. It's only unsafe on uniprocessor systems. Load module A, which hooks into sys_read(). It stores the location of the original sys_read to restore it at unload. Load module B, which also hooks into sys_read() and stores the location of the previos sys_read (which is actually module A's implementation of sys_read()). Now unload module A. Next process that will call sys_read() will cause a kernel Oops. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
Attachment:
signature.asc
Description: Digital signature
