Re: Two fixes for 2.4.19-pre5-ac3

[Muli Ben-Yehuda <mulix@actcom.co.il>]

On Sun, Apr 07, 2002 at 09:29:01PM +0100, Alan Cox wrote:
> > hijacks syscall entries in the sys_call_table as well, because we
> > want it to work as a module and not require patching the kernel. Our
> > solution to the module unload race on syscall de-hijacking is simple,
> > splitting the system call hijacking code into a single small module
> > which once loaded cannot be unloaded.
> 
> So your small module can export a function called 
> 	patch_syscall(NR_foo, function);
> 
> Now you can put the arch specific syscall patching code into your small
> common module and its cleaner anyway ?

Right, this module (syscall_hijack.o) currently has the interface:

int hijack_syscall_before(int syscall_id, func_ptr func); 
int hijack_syscall_after(int syscall_id, func_ptr func); 

int release_syscall_before(int syscall_id);
int release_syscall_after(int syscall_id);

where 'before' and 'after' correspond to a hook which should run
before the original system call is invoked (allowing it to specify
that the original system call should not be executed) or after the
original system call is invoked (allowing it access to its return
value). 

We only support i386 (and uml) at the moment, because of the problems
with hijacking system calls on other architectures and because none of
us have access to other architectures to test the code on.

I recall reading in the archives that linus objected to modules
hijacking system calls on the grounds that it allows binary only
modules to completely subvert the way the kernel behaves towards
userspace. What if such a mechanism existed, however, and was only
exported to modules with a suitable license (modules which don't taint
the kernel). Would that be feasible?
-- 
The ill-formed Orange
Fails to satisfy the eye:       http://vipe.technion.ac.il/~mulix/
Segmentation fault.             http://syscalltrack.sf.net/