> Hello guys,
>
[snip]
> So, if anyone is still interested please feel free to download it from my
> web page at <http://www.aivazian.demon.co.uk/tt/tt.html>.
>
> Why is it linux-kernel relevant? Because I think it can also be used for
> illustrating one possible way of patching system calls from a module.
>
But maybe you should add that this kind of patching should only be used
for debugging/developping purposes, i.e. used by people who know what they
are doing because itīs far too easy to crash your system this way. Imagine
two modules, e.g. timetravel.o and tt_with_my_even_cooler_patches.o, both
patching sys_call "essential". Do insmod mod1.o, insmod mod2.o. Then rmmod
mod1, which puts sys_call_table[__NR_"essential"] pointing back to the
standard kernel function. Well, thatīs probably not what you want but
shouldnīt do too much harm. However, should you now think it was a good
idea to remove mod2 as well, it will initialize
sys_call_table[__NR_"essential"] with its saved pointer that is actually
pointing to mod1īs wrapper function which doesnīt exist anymore. Thatīs
when itīs time to remember where that reset button was. (Yes, I tested
this, no, it was not deliberately and no, magic sys keys wonīt work when
your time() is trashed. ;*) )
A secure but imho ugly workaround would be to do a check first in
cleanup_module() if still sys_call_table[__NR_function] ==
(long)my_patched_function; and if one of the tests fails, prevent
unloading with say
printk(KERN_INFO "Sorry, self destruction switch is disabled -
<foo-module> not removed as it might break some other modules\n");
return;
The proper way to solve this problem probably would be to put a queue on
each entry of sys_call_table[] with only the latest entry in the queue
being actually called but ... err, well ... do I have to go on...?
> For those who do not know what I am talking about - Time Travel is a
> kernel module (2.1.x only) that can be used to simulate the environment
> with shifted (in any direction) concept of time, both in the sense of
> system time and filesystem-related timestamps.
Cheers,
Daniel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu