The disappearing sys_call_table export.

What is really needed is some kind of proper generic hooking setup
that could be used both by LSM and other things. People doing this may need to intercept syscalls both on their way to the kernel and on the way back to userland (so they can see return codes.) They may also need to say whether they want to be first or last if there are multiple users of this facility.

But the real question is why the export of sys_call_table was so
gratuitously removed without any kind of replacement being offered. And the attitude of the developers about it is truly awful. ("Oh, so we broke the drivers you depend on for your livelihood? You can just go get a new job -- pounding sand down a rathole.")

I guess something like this:

typedef int (*syscall_hook_t)(void * arg1, void * arg2, void * arg3, void * arg4, void * arg5, void * arg6);

#define HOOK_IN_FLAG 0x1
#define HOOK_OUT_FLAG 0x2

opaquehandle = int register_syscall_hook(int syscall_nr, syscall_hook_t hook_function, int flags);
int unregister(int opaquehandle);

I'd make a stab at it if I knew that it stood a chance of getting accepted.

TJ

_________________________________________________________________________

Terje Eggestad                  mailto:[email protected]
Scali Scalable Linux Systems    http://www.scali.com

Olaf Helsets Vei 6              tel:    +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal                     +47 975 31 574  (MOBILE)
N-0619 Oslo                     fax:    +47 22 62 89 51
NORWAY            
_________________________________________________________________________

I dont think it has.

I think it could, actually - who maintains fortunes these days? It's a bit too long, though...

What really gets to me is that *you* wrote in
(http://www.kernel.org/pub/linux/kernel/v2.5/ChangeLog-2.5.41):

3. Intercept system calls
OProfile (and intel's vtune which is similar in function) used to do this; however what they really need is a notification on certain events (exec() mostly). The way modules do this is store the original function pointer, install a new one that calls the old one after storing whatever info they need. This mechanism breaks badly in the light of multiple such modules doing this versus modules unloading/uninstalling their handlers (by restoring their saved pointer that may or may not point to a valid handler anymore).
Eg the use of the export in this just a bandaid due to lack of a proper mechanism, and also incorrect and crash prone.

So what you're saying here is not that you object to having people doing syscall hooks, just that operating on the syscall_table symbol directly is error prone (to which I wholeheartedly agree).

Then you reject a "proper mechanism".....

TJ

_________________________________________________________________________

Terje Eggestad                  mailto:[email protected]
Scali Scalable Linux Systems    http://www.scali.com

Olaf Helsets Vei 6              tel:    +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal                     +47 975 31 574  (MOBILE)
N-0619 Oslo                     fax:    +47 22 62 89 51
NORWAY            
_________________________________________________________________________

Maybe you have a different notion of proper mechanism then everyone else. BTW, you could easily have fixed your driver in the time you spent trolling on lkml..

Out of personal interest - would a mechanism that promised the following be considered a "proper mechanism"?
1. Work on all platforms.
2. Allow load and unload in arbitrary order and timings (which also means "be race free").
3. Have low/zero overhead if not used

Would you also require:
4. Have reasonable overhead when used
a "must have" demand? Would, on the other hand, a:
4b. Have zero overhead when used for functions not hooked be an alternative demand?

I'm currently trying to work with some other subscribers of this list on a design. Getting 1, 2 and 3 is a complicated enough task, of course. I would like to hear estimates about inclusion chances should we manage to come up with an implmentation that lives up to all the above.

Thanks,
Shachar

Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/

No, the most important point is that a proper meachanism wouldn't replace syscall slots but rather operate on kernel objects (file, inode vma, task_struct, etc..). Linus has expressed a few times that he has no interest in loadable syscalls and any core developer I've talked to agrees with that.

Don't have followed the whole thread, so I don't know if somebody has already said this, but all this thing about hooks looks perfect for projects like bproc or mosix, have you talked to them ?
(perhaps Erik Hendriks <[email protected]> -bproc- is following the thread...;) )

J.A. Magallon <[email protected]>      \                 Software is like sex:
werewolf.able.es                         \           It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.21-rc1-jam2 (gcc 3.2.2 (Mandrake Linux 9.2 3.2.2-5mdk))

thread...;) )

I don't know about bproc, but at least MOSIX is, as it currently stands, a kernel patch. Therefore, they can (and do) hijack the syscall table safely. If I remember the code correctly, they do it in entry.S, not in the sys_call_table itself.

Muli Ben-Yehuda
http://www.mulix.org

For some usages, hijacking syscalls, and not kernel objects, is the desired outcome. For example, ptrace is great for telling you what a given process (or its children) did, but it's entirely inadequate for telling you *which* process did something. Something, in this case, which doesn't have an associated kernel object.

For example, a rogue process is calling settimeofday() on your router once a month(!). How are you going to find it? There's no LSM hook for settimeofday() or any other way to say "don't do that", if it's running as root. Using syscalltrack, or anything else which hijacks system calls, not just kernel object, finding the culprit is trivial.

I've been staying out of this discussion, even though I have an interest in its outcome. Talking about it is completely pointless until someone writes a proper, *technically correct*, system call hijacking interface. Then we can argue about whether or not it should go in.

Muli Ben-Yehuda
http://www.mulix.org

Yes there is. Check the capable hook for CAP_SYS_TIME. LSM modules can get that info quite easily.

thanks,

greg k-h

Indeed, I missed the fact that LSM modules have a capable hook. Nonetheless, my original point stands: LSM and hooking kernel objects are great for security and auditing, hijacking system calls can be quite useful for debugging, both kernel and userspace.

Thanks,
Muli.

Muli Ben-Yehuda
http://www.mulix.org