On 2/25/07, Liran <liransgarage@xxxxxxxxx> wrote:
Erik Mouw <mouw <at> nl.linux.org> writes: > > > > > > > > >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. > Module A doesn't make changes to sys_read() rather it only needs to get the data regarding it (the file size that was opened, etc) and always returns the original sys_read() anyway. So the whole process should be transparent, even to module B, so I don't see the problem regarding the kernel oops even in that case. If it still applies, please explain why.
Well, it depends on what you want to do: - Replace the original system call (lets say sys_read) process --- (syscall) ---> my_sys_read (and jumping back) - Jump to your own function, then call the original one and then go back process --- (syscall) ---> my_sys_read ---> sys_read (and jumping back) The problem comes during unloading. In the first case, it's completely useless to try to unload the only one sys_read syscall service routine. But in the second case, your module (and your my_sys_read function) could be collecting statistics and then you may want to unload again. What happens if you try to unload your module while one process is executing my_sys_read? Oops. And what happens if one process already executed my_sys_read and now it is inside the actual sys_read? Oops because in the return from the sys_read, your function will be not present. And my question is: Isn't this unsafe also in SMP systems?
Ok so hooking is a bad idea and anyway isn't supported in 2.6 and regarding kprobes, some distros don't shift with it's kernel config turned on. How about resulting back to the LD_PRELOAD idea that was suggested at first?
It's not supported and it is architecture dependant. There is a hack to try to find the syscall table in x86 systems. The syscall table is not exported anymore, but the sys_read, sys_open and others are exported, so you know their addresses. Basically you have to scan the kernel memory space to find the syscall table (comparing the index for sys_open, with the address that you already know) Anyway I think kprobes is really good for this things unless you are trying to do something by your own and just to learn. As far as I know this is the way in which OProfile did this in 2.4 Please, CMIIW Best Regards
Thanks, Liran. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
-- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
