Messages in this thread |  | | From | Tony.Young@ir ... | Subject | FW: trapping syscall problem - kernel module | Date | Mon, 24 Sep 2001 14:55:51 +1000 |
| |
If anyone here can help with the attached problem I'd appreciate it. Please CC any responses to me as I'm not on the list.
TIA Tony...
> -----Original Message----- > From: Tony Young > Sent: Friday, 21 September 2001 17:24 > To: 'slug@slug.org.au' > Subject: trapping syscall problem - kernel module > > > This is a question for those kernel hackers on the list that > know about developing modules to trap/intercept system calls. > > I'm trying to develop a module that detects calls to > fork/vfork, execve and exit to track processes on the system. > I've implemented a module that will do this on Solaris - it > was relatively simple. However I'm having trouble > implementing a similar module on Linux. > > I've attached my source code and makefile - it should be safe > to compile and load. But I make no guarantees. I've been > testing and developing it on a 2.4.8 kernel - single > cpu(Mandrake 8.1 beta). > <<syscall.c>> <<makefile>> > The module is fairly basic. It replaces each system call with > my own that just displays some information using printk and > calls the original. > The fork, vfork and exit replacements work fine. But I'm > having trouble with execve. > > With the implementation in the code that's currently enabled > (inside #if 1 in newexecve()) any execve results in the > calling process core dumping. The printk's before and after > the call to oldexecve work which implies that the execve > actually worked. But something appears to be going wrong > returning from the function. > > This implementation is similar to the implementation of my > Solaris module. After failure on linux though I went looking > for alternatives and found another way of doing it which > basically just bypasses the sys_execve(oldexecve) syscall > entirely, calling do_execve itself. This method, as expected, > works. However, if the implementation of sys_execve ever > changes I'll need to change my implementation to match - I'd > rather leverage of sys_execve if at all possible. > > So I guess what I'm asking is why my implementation doesn't > work? I'm guessing that something's going on with > sys_execve's use of the registers that's somehow trashing the > stack or return pointer when used my way but I'm not sure. > > I haven't yet tried the kernel debugger to see what's going > on - simply because I've never used it before. > > Any help anyone could provide would be great. > > Thanks. > Tony... > > -- > Tony Young > Senior Software Engineer > Integrated Research Limited > Level 10, 168 Walker St > North Sydney, NSW 2060, Australia > Ph: +61 2 9966 1066 > Fax: +61 2 9966 1042 > [unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream] |  |