Re: linux-kernel-digest V1 #2090
Matthew Wilcox (willy@odie.barnet.ac.uk)
Sun, 14 Jun 1998 20:35:54 +0100 (BST)
> From: Daniel Kobras <belbo@zxmtj03.extern.uni-tuebingen.de>
> Date: Sun, 14 Jun 1998 18:01:38 +0200 (CEST)
> Subject: Re: (new) Time Travel v2.0 released.
>
> Tigran Aivazian wrote:
> > 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...?
The Right Way to solve this is to do it in each module - not in the
kernel since it's not a recommended thing to do at all. Each module
when asked to unload should check that the vectors it claimed are still
pointing at itself and refuse to exit if they aren't. I assume modules
can refuse to be unloaded.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu