Syscall table AKA hijacking syscalls
Hi,
I'm writing some project which needs to hijack some syscalls in VFS layer. AFAIK in 2.6 is this "not-wanted" solution (even that there are some very nasty ways of doing it - see http://mail.nl.linux.org/kernelnewbies/2002-12/msg00266.html )
Also I've found out that Linus stated that intercepting syscalls is "bad thing" (load module a, load module b, unload module b => crash) but I think that there are some very good reasons (and ways) to do it (see http://syscalltrack.sourceforge.net ). My main reason to do it is that I want my GPLed module to be able to modify some VFS syscalls without patching and recompiling whole kernel and rebooting the machine.
So what is proper (Linus recommanded) way to do such a things? Create patches for specific syscalls like "if this_module_installed then call_this_function;" or try to force things like syscalltrack to go into vanilla kernel some time? Because what I've found out there are more projects which suffer from this restriction.
Signature · 1 line
Libor Vanek
Quoted 3 lines · Libor Vanek
Hi,
I'm writing some project which needs to hijack some syscalls in VFS layer. AFAIK in 2.6 is this "not-wanted" solution (even that there are
...
Quoted 5 lines
So what is proper (Linus recommanded) way to do such a things? Create patches for specific syscalls like "if
this_module_installedthencall_this_function;" or try to force things like syscalltrack to go into vanilla kernel some time? Because what I've found out there are more projects which suffer from this restriction.
Maybe:
int (*funcvec_v1)(args); EXPORT_SYMBOL(funcvec_v1);
...
retval = (funcvec_v1) ? (funcvec_v1)(args..) : func_f1(args...);
or something of that kind.
There is, of course, whole slew of politically coloured issues with this chainability.
Quoted 2 lines
Signature · 1 line
Libor Vanek
/Matti Aarnio
Quoted 10 lines · Matti Aarnio
Quoted 4 lines · Libor Vanek
Hi,
I'm writing some project which needs to hijack some syscalls in VFS layer. AFAIK in 2.6 is this "not-wanted" solution (even that there are...
Quoted 9 lines
Quoted 3 lines
So what is proper (Linus recommanded) way to do such a things? Create patches for specific syscalls like "if
this_module_installedthencall_this_function;" or try to force things like syscalltrack to go into vanilla kernel some time? Because what I've found out there are more projects which suffer from this restriction.There is, of course, whole slew of politically coloured issues with this chainability.
I think that issues with chainability are ALWAYS whenever you try to do this hijacking general.
Signature · 1 line
Libor Vanek
Quoted 6 lines · Libor Vanek
Hi,
I'm writing some project which needs to hijack some syscalls in VFS layer. AFAIK in 2.6 is this "not-wanted" solution (even that there are some very nasty ways of doing it - see
http://mail.nl.linux.org/kernelnewbies/2002-12/msg00266.html )
Quoted 6 lines
Also I've found out that Linus stated that intercepting syscalls is "bad thing" (load module a, load module b, unload module b => crash) but I think that there are some very good reasons (and ways) to do it (see
http://syscalltrack.sourceforge.net ). My main reason to do it is that I want my GPLed module to be able to modify some VFS syscalls without patching and recompiling whole kernel and rebooting the machine.
As part of the openxdsm-project we wrote an syscall-intercept module that "solves" the (load module a, load module b, unload module b => crash) part by providing a common infrastructure for intercepting syscalls.
It's available at:
http://cvs.sourceforge.net/viewcvs.py/openxdsm/openxdsm/eventmodule/module/events.c?rev=1.1.1.1&view=auto
Signature · 1 line
Ragnar Kjørstad
Quoted 4 lines
Quoted 4 lines
I'm writing some project which needs to hijack some syscalls in VFS layer. AFAIK in 2.6 is this "not-wanted" solution (even that there are some very nasty ways of doing it - see http://mail.nl.linux.org/kernelnewbies/2002-12/msg00266.html )
Quoted 10 lines
Quoted 3 lines
Also I've found out that Linus stated that intercepting syscalls is "bad thing" (load module a, load module b, unload module b => crash) but I think that there are some very good reasons (and ways) to do it (see http://syscalltrack.sourceforge.net ). My main reason to do it is that I want my GPLed module to be able to modify some VFS syscalls without patching and recompiling whole kernel and rebooting the machine.
As part of the openxdsm-project we wrote an syscall-intercept module that "solves" the (load module a, load module b, unload module b => crash) part by providing a common infrastructure for intercepting syscalls.
The code looks very nice'n'simple but it won't run on 2.6 because mentioned hidden sys_call_table. But I can imagine that this with some small tweaks can be integrated into 2.6 to provide generall infrastructure for syscall hijacking when really needed.
Signature · 1 line
Libor Vanek
Quoted 5 lines · Libor Vanek
Quoted 1 line
The code looks very nice'n'simple but it won't run on 2.6 because mentioned hidden
sys_call_table. But I can imagine that this with some small tweaks can be integrated into 2.6 to provide generall infrastructure for syscall hijacking when really needed.
Repeat: This is a hack, nothing else.
*You* need it for your thesis, so go ahead. The right solution for the problem, which is research, rather than engineering. But don't think this mess should be integrated into mainline, much less tell other people it should.
*Noone* needs it for real code that is supposed to do something meaningful. Some people feel they need it, but they just haven't found the right solution yet and believe this hack to be right. It isn't.
Clear enough?
Jörn
Signature · 4 lines
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. -- Edsger W. Dijkstra
Quoted 5 lines · Libor Vanek
Hi,
I'm writing some project which needs to hijack some syscalls in VFS layer. AFAIK in 2.6 is this "not-wanted" solution (even that there are some very nasty ways of doing it - see
http://mail.nl.linux.org/kernelnewbies/2002-12/msg00266.html )
Why do you need to hijack system calls from a module? 99% of the times, it's the wrong technical solution.
Quoted 5 lines
So what is proper (Linus recommanded) way to do such a things? Create patches for specific syscalls like "if
this_module_installedthencall_this_function;" or try to force things like syscalltrack to go into vanilla kernel some time? Because what I've found out there are more projects which suffer from this restriction.
There is no such Linus recommended way. For 2.6, syscalltrack's hijack module moved into the kernel and will provide such generic functionality one day. But I don't anticipate it every going into the vanilla kernel, due to Linus's well known objections to syscall hijacking in general and making it convenient in particular.
Cheers,
Muli
Signature · 4 lines
Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ "the nucleus of linux oscillates my world" - gccbot@#offtopic
Quoted 9 lines
Quoted 4 lines
I'm writing some project which needs to hijack some syscalls in VFS layer. AFAIK in 2.6 is this "not-wanted" solution (even that there are some very nasty ways of doing it - see http://mail.nl.linux.org/kernelnewbies/2002-12/msg00266.html )
Why do you need to hijack system calls from a module? 99% of the times, it's the wrong technical solution.
I'm working on my diploma thesis which is adding snapshot capability into Linux VFS (so you can do directory based snapshots - not complete device, like in LVM). It'll consist of two separete modules:
Snapshot module:
- will hijack (one or another way) calls to open/move/unlink/mkdir/etc. syscall
- when will detect change to selected directory (which I want to snapshot), it'll copy/move old file/directory to some temporary (selected when creating snapshot) - in fact - copy on write behaviour
UnionFS module:
- will place "temporary" directory with saved files/dirs "over" actual one and result will be read-only snapshot - this can be done without hijacking syscalls probably
- something like overlay fs but a bit different
Signature · 1 line
Libor Vanek
Quoted 9 lines · Libor Vanek
I'm working on my diploma thesis which is adding snapshot capability into Linux VFS (so you can do directory based snapshots - not complete device, like in LVM). It'll consist of two separete modules:
Snapshot module:
- will hijack (one or another way) calls to open/move/unlink/mkdir/etc. syscall
- when will detect change to selected directory (which I want to snapshot), it'll copy/move old file/directory to some temporary (selected when creating snapshot) - in fact - copy on write behaviour
This should be implemented as a stackable filesystem..
Quoted 11 lines · Christoph Hellwig
Quoted 9 lines · Libor Vanek
I'm working on my diploma thesis which is adding snapshot capability into Linux VFS (so you can do directory based snapshots - not complete device, like in LVM). It'll consist of two separete modules:
Snapshot module:
- will hijack (one or another way) calls to open/move/unlink/mkdir/etc. syscall
- when will detect change to selected directory (which I want to snapshot), it'll copy/move old file/directory to some temporary (selected when creating snapshot) - in fact - copy on write behaviour
Quoted 1 line
This should be implemented as a stackable filesystem..
Does this filesystem stack work with multiple mount points?
My guess is that the filesystem change notification would be a better solution, either in userspace or in kernelspace, doesn't matter. But that is far from finished or even generally accepted.
For the diploma thesis, feel free to use any hack you like, including hijacking syscalls. But remember that it is a hack and nothing else, only helping you to remain on schedule and focus more on the real subject. And don't plan on kernel acceptance either, as you will fail either that or the thesis and I'd choose the thesis.
Jörn
Signature · 3 lines
Mundie uses a textbook tactic of manipulation: start with some reasonable talk, and lead the audience to an unreasonable conclusion. -- Bruce Perens
Quoted 10 lines
Quoted 9 lines
Quoted 7 lines
I'm working on my diploma thesis which is adding snapshot capability into Linux VFS (so you can do directory based snapshots - not complete device, like in LVM). It'll consist of two separete modules:
Snapshot module:
- will hijack (one or another way) calls to open/move/unlink/mkdir/etc.
syscall
- when will detect change to selected directory (which I want to
snapshot), it'll copy/move old file/directory to some temporary (selected when creating snapshot) - in fact - copy on write behaviourThis should be implemented as a stackable filesystem..
Does this filesystem stack work with multiple mount points?
I think that stackable filesystem is useless for this. See this:
- I have some BIG (>> 1 TB) filesystem (XFS/ext3/JFS whatever!!!) mounted in /BIG
- I call something like snapshot --what=/BIG/data --where=/OTHER_FS/snap1
- from now whenever I delete/create/modify file/dir in /BIG/data then BEFORE the action the original file/dir should be copyied/moved to /OTHER_FS/snap1
There is no place where can I use stackable filesystem because I'd need to use it on the very beginning of mounting /BIG so instead:
mount /dev/md0 /BIG -t xfs
I'd need to do something like:
mount /dev/md0 /BIG -t snapfs -o fstype=xfs
Which is something I'm trying to avoid as much as possible for many reasons.
Quoted 3 lines
My guess is that the filesystem change notification would be a better solution, either in userspace or in kernelspace, doesn't matter. But that is far from finished or even generally accepted.
This is also something (but just a bit) different - I don't need "change notification" but "pre-change notification" ;)
Quoted 5 lines
For the diploma thesis, feel free to use any hack you like, including hijacking syscalls. But remember that it is a hack and nothing else, only helping you to remain on schedule and focus more on the real subject. And don't plan on kernel acceptance either, as you will fail either that or the thesis and I'd choose the thesis.
You're absolutely right but when I'm going to spent several weeks on something like this I'd like to do something usefull - not something which will be trashed after exam. So I'm trying to find out some "politically correct" way.
Right now I'll code it with the very nasty "find sys_call_table" hack just I can test it without rebooting my machine (attempts to get 2.6.0 running under UML or VMWare failed :-((() and when I'll release some 0.0.1 version and get some good respondce I'll code it as the VFS patch & module.
Signature · 1 line
Libor Vanek
Quoted 7 lines · Libor Vanek
Quoted 4 lines
My guess is that the filesystem change notification would be a better solution, either in userspace or in kernelspace, doesn't matter. But that is far from finished or even generally accepted.
This is also something (but just a bit) different - I don't need "change notification" but "pre-change notification" ;)
"Vor dem Spiel ist nach dem Spiel" -- Sepp Herberger
Except for exactly two cases, pre-change and post-change and the same, just off-by-one. So you would need a bootup/mount/whenever special case now, is that a big problem?
Quoted 10 lines
Quoted 5 lines
For the diploma thesis, feel free to use any hack you like, including hijacking syscalls. But remember that it is a hack and nothing else, only helping you to remain on schedule and focus more on the real subject. And don't plan on kernel acceptance either, as you will fail either that or the thesis and I'd choose the thesis.
You're absolutely right but when I'm going to spent several weeks on something like this I'd like to do something usefull - not something which will be trashed after exam. So I'm trying to find out some "politically correct" way.
Then seperate the two problems. One is to figure out, what has changed and two is to act accordingly. Two should be pretty independent on this threads subject. If that part is really useful, people will help you on problem one. Postpone. :)
Something I learned over time is that the first implementation is almost always crappy, often even righout wrong. It has to be, because noone really knows all the problems yet and thus can design the Proper Solution (tm) yet. Look at the current devfs vs. udev discussion for one example.
Many research people know this and won't give you any source code beyond the official paper simply because it is horrible and the don't want to wear brown paper-bags. There is no shame in a horrible first try, noone could have done that much better than Richard Gooch back then. Simply because noone could learn from his mistakes yet.
Ok, there is shame in a horrible first try, but there shouldn't be, really. The "standing on the shoulders of giants" thing applies, even when standing on the shoulders of dwarves, people should be more polite. :)
And even though he won't read this, thank you Richard! He took the unrewarding role and grew bitter, but he did a good thing.
Ok, back to your problem. Seperation is the way to go. Problem one is a hard one and it takes a lot of time to do right. But hacking it up is quite simple, so you can save time with the hack and do it right only if your solution to problem two proved good enough.
Jörn
Signature · 3 lines
He who knows others is wise. He who knows himself is enlightened. -- Lao Tsu
Quoted 5 lines · Jörn Engel
Quoted 4 lines · Libor Vanek
Quoted 3 lines
My guess is that the filesystem change notification would be a better solution, either in userspace or in kernelspace, doesn't matter. But that is far from finished or even generally accepted.
Quoted 7 lines
Quoted 1 line
This is also something (but just a bit) different - I don't need "change notification" but "pre-change notification" ;)
"Vor dem Spiel ist nach dem Spiel" -- Sepp Herberger
Except for exactly two cases, pre-change and post-change and the same, just off-by-one. So you would need a bootup/mount/whenever special case now, is that a big problem?
Probably my english is bad but I don't understand what are you trying to say (except the german part ;-))
A bit more about pre/post-change (if this is what are you trying to say) - I need allways pre-change because after file is changed I can no longer get original (pre-change) version of file which I need for snapshot.
Quoted 8 lines
Quoted 7 lines
Quoted 5 lines
For the diploma thesis, feel free to use any hack you like, including hijacking syscalls. But remember that it is a hack and nothing else, only helping you to remain on schedule and focus more on the real subject. And don't plan on kernel acceptance either, as you will fail either that or the thesis and I'd choose the thesis.
You're absolutely right but when I'm going to spent several weeks on something like this I'd like to do something usefull - not something which will be trashed after exam. So I'm trying to find out some "politically correct" way.
Quoted 9 lines
Then seperate the two problems. One is to figure out, what has changed and two is to act accordingly. Two should be pretty independent on this threads subject. If that part is really useful, people will help you on problem one. Postpone. :)
...
Ok, back to your problem. Seperation is the way to go. Problem one is a hard one and it takes a lot of time to do right. But hacking it up is quite simple, so you can save time with the hack and do it right only if your solution to problem two proved good enough.
Yes - that's what I'm now doing. Just now I'm going to reboot my machine (<grr>) and try if EXPORT_SYMBOL(sys_open) works as I think it should ;)
Anyway - thanks for hints.
--
Libor Vanek
Quoted 9 lines · Libor Vanek
Quoted 8 lines · Jörn Engel
Quoted 6 lines · Libor Vanek
Quoted 3 lines
My guess is that the filesystem change notification would be a better solution, either in userspace or in kernelspace, doesn't matter. But that is far from finished or even generally accepted.
This is also something (but just a bit) different - I don't need "change notification" but "pre-change notification" ;)
Quoted 8 lines
Quoted 5 lines
"Vor dem Spiel ist nach dem Spiel" -- Sepp Herberger
Except for exactly two cases, pre-change and post-change and the same, just off-by-one. So you would need a bootup/mount/whenever special case now, is that a big problem?
Probably my english is bad but I don't understand what are you trying to say (except the german part ;-))
A bit more about pre/post-change (if this is what are you trying to say) - I need allways pre-change because after file is changed I can no longer get original (pre-change) version of file which I need for snapshot.
then you are off on the wrong track anyway since filedata can change without system call anyway (think mmaped file where the dirtying doesnt' involve a syscall
Quoted 18 lines · Arjan van de Ven
Quoted 16 lines · Libor Vanek
Quoted 13 lines · Jörn Engel
Quoted 5 lines · Libor Vanek
Quoted 3 lines
My guess is that the filesystem change notification would be a better solution, either in userspace or in kernelspace, doesn't matter. But that is far from finished or even generally accepted.
This is also something (but just a bit) different - I don't need "change notification" but "pre-change notification" ;)
"Vor dem Spiel ist nach dem Spiel" -- Sepp Herberger
Except for exactly two cases, pre-change and post-change and the same, just off-by-one. So you would need a bootup/mount/whenever special case now, is that a big problem?
Quoted 5 lines
Quoted 2 lines
Probably my english is bad but I don't understand what are you trying to say (except the german part ;-))
A bit more about pre/post-change (if this is what are you trying to say) - I need allways pre-change because after file is changed I can no longer get original (pre-change) version of file which I need for snapshot.then you are off on the wrong track anyway since filedata can change without system call anyway (think mmaped file where the dirtying doesnt' involve a syscall
I know about this - the only (simple and fast enough) solution is to copy (backup) file whenever it's open for writing and mmap is called.
Signature · 1 line
Libor Vanek
Quoted 12 lines · Libor Vanek
Quoted 10 lines · Jörn Engel
Quoted 3 lines · Libor Vanek
This is also something (but just a bit) different - I don't need "change notification" but "pre-change notification" ;)
"Vor dem Spiel ist nach dem Spiel" -- Sepp Herberger
Except for exactly two cases, pre-change and post-change and the same, just off-by-one. So you would need a bootup/mount/whenever special case now, is that a big problem?
Quoted 5 lines
Probably my english is bad but I don't understand what are you trying to say (except the german part ;-))
A bit more about pre/post-change (if this is what are you trying to say) - I need allways pre-change because after file is changed I can no longer get original (pre-change) version of file which I need for snapshot.
If you take a snapshot on every change within your scope, it doesn't really matter whether you do it before or after the change. Before change n is just after change n-1. All you have to do is take another snapshot before the first change, that is the special case.
If you take snapshots just once in a blue moon, this obviously doesn't work. But I wonder if that approach would make sense anyway, as incremental snapshots are just so much nicer. Actually, I've once written a Pascal program to do just that, for some stupid university credit. It doesn't have the proper kernel hooks and is the wrong language, but it does the incremental snapshot. Documentation is in German, but if you are interested, I will try to find an electronic copy.
Actually, with userspace notification in place, you could even get this with just cvs. Whenever a file is changed, commit. cvs add on creation, etc. Yes, it sucks, but implementation simplicity has it's own beauty and it would only take a few minutes. :)
Jörn
Signature · 2 lines
Geld macht nicht glücklich. Glück macht nicht satt.
Quoted 14 lines · Jörn Engel
Quoted 12 lines · Libor Vanek
Quoted 9 lines · Jörn Engel
Quoted 1 line · Libor Vanek
This is also something (but just a bit) different - I don't need "change notification" but "pre-change notification" ;)
"Vor dem Spiel ist nach dem Spiel" -- Sepp Herberger
Except for exactly two cases, pre-change and post-change and the same, just off-by-one. So you would need a bootup/mount/whenever special case now, is that a big problem?
Quoted 6 lines
Quoted 2 lines
Probably my english is bad but I don't understand what are you trying to say (except the german part ;-))
A bit more about pre/post-change (if this is what are you trying to say) - I need allways pre-change because after file is changed I can no longer get original (pre-change) version of file which I need for snapshot.If you take a snapshot on every change within your scope, it doesn't really matter whether you do it before or after the change. Before change n is just after change n-1. All you have to do is take another snapshot before the first change, that is the special case.
But this special case in fact means to copy all the data, if wanted to do it 100% working ;-) And I suggest that it wont' go through my exam ;)
Quoted 4 lines
Actually, with userspace notification in place, you could even get this with just cvs. Whenever a file is changed, commit. cvs add on creation, etc. Yes, it sucks, but implementation simplicity has it's own beauty and it would only take a few minutes. :)
I've heard about some fs from Microsoft which should have cvs-like behaviour for all the time ("I want this file version from yesterday") - but I haven't had any details (and I suppose performance hit must be big)
Signature · 1 line
Libor Vanek
Quoted 8 lines · Libor Vanek
Quoted 5 lines
If you take a snapshot on every change within your scope, it doesn't really matter whether you do it before or after the change. Before change n is just after change n-1. All you have to do is take another snapshot before the first change, that is the special case.
But this special case in fact means to copy all the data, if wanted to do it 100% working ;-) And I suggest that it wont' go through my exam ;)
Yes, it does. Cannot comment on your exam, though.
Quoted 8 lines
Quoted 4 lines
Actually, with userspace notification in place, you could even get this with just cvs. Whenever a file is changed, commit. cvs add on creation, etc. Yes, it sucks, but implementation simplicity has it's own beauty and it would only take a few minutes. :)
I've heard about some fs from Microsoft which should have cvs-like behaviour for all the time ("I want this file version from yesterday") - but I haven't had any details (and I suppose performance hit must be big)
Not too big, actually. The obvious implementation has to write data twice (plus metadata, but that's minimal), so performance is ~50% of normal. With hard drives and a smarter implementation, you don't have to worry about seek latency too much for the log, so performance is usually better than 50%. Basically, it hurts where you are good enough anyway (large sequential writes) and goes unnoticed where performance is bad (many small scattered writes).
The real problem is storage size. Each write will *permanently* reduce the filesystem size. Maxtor and friends should happily sponsor such development. :)
Seriously, such a thing is the perfect cure for "rm -rf foo /" and similar famous mistakes and you can always just remove the oldest backup data (preferrably after writing it to a tape).
Jörn
Signature · 2 lines
A defeated army first battles and then seeks victory. -- Sun Tzu
Quoted 12 lines · Libor Vanek
Quoted 8 lines
Quoted 7 lines
I'm writing some project which needs to hijack some syscalls in VFS layer. AFAIK in 2.6 is this "not-wanted" solution (even that there are some very nasty ways of doing it - see
http://mail.nl.linux.org/kernelnewbies/2002-12/msg00266.html )Quoted 4 lines
Why do you need to hijack system calls from a module? 99% of the times, it's the wrong technical solution.
Quoted 9 lines
I'm working on my diploma thesis which is adding snapshot capability into Linux VFS (so you can do directory based snapshots - not complete device, like in LVM). It'll consist of two separete modules:
Snapshot module:
- will hijack (one or another way) calls to open/move/unlink/mkdir/etc. syscall
- when will detect change to selected directory (which I want to snapshot), it'll copy/move old file/directory to some temporary (selected when creating snapshot) - in fact - copy on write behaviour
Do it in userspace. Hack a nfs server.
Quoted 18 lines
UnionFS module:
- will place "temporary" directory with saved files/dirs "over" actual one and result will be read-only snapshot - this can be done without hijacking syscalls probably
- something like overlay fs but a bit differentSignature · 9 lines
Libor Vanek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Signature · 3 lines
Eletztrick Computing - Customized Linux Development Stefan Eletzhofer, Marktstrasse 43, DE-88214 Ravensburg http://www.eletztrick.de
Quoted 5 lines
I'm writing some project which needs to hijack some syscalls in VFS layer. AFAIK in 2.6 is this "not-wanted" solution (even that there are some very nasty ways of doing it - see
http://mail.nl.linux.org/kernelnewbies/2002-12/msg00266.html )
And it will fail miserably on many non x86 architectures for various reasons:
1. ppc64 and ia64 use function descriptors
2. sparc64 uses a 32bit call out table
In short its not only an awful hack, its horribly non portable :)
Anton
Quoted 10 lines
Quoted 1 line
I'm writing some project which needs to hijack some syscalls in VFS layer. AFAIK in 2.6 is this "not-wanted" solution (even that there are some very nasty ways of doing it - see http://mail.nl.linux.org/kernelnewbies/2002-12/msg00266.html )
And it will fail miserably on many non x86 architectures for various reasons:
1. ppc64 and ia64 use function descriptors
2. sparc64 uses a 32bit call out tableIn short its not only an awful hack, its horribly non portable :)
But in short you always get some syscall from userspace and have some table with function vectors assigned to each syscall, don't you?
So you can have something like "append_this_function_before_syscall_sys_open" and "append_this_function_after_syscall_sys_open" which would be platform independent but will have platform dependent implementation.
Signature · 1 line
Libor Vanek
Quoted 14 lines · Libor Vanek
Quoted 6 lines
Quoted 4 lines
I'm writing some project which needs to hijack some syscalls in VFS layer. AFAIK in 2.6 is this "not-wanted" solution (even that there are some very nasty ways of doing it - see
http://mail.nl.linux.org/kernelnewbies/2002-12/msg00266.html )Quoted 7 lines
And it will fail miserably on many non x86 architectures for various reasons:
1. ppc64 and ia64 use function descriptors
2. sparc64 uses a 32bit call out tableIn short its not only an awful hack, its horribly non portable :)
Quoted 7 lines
But in short you always get some syscall from userspace and have some table with function vectors assigned to each syscall, don't you?
So you can have something like "
append_this_function_before_syscall_sys_open" and "append_this_function_after_syscall_sys_open" which would be platform independent but will have platform dependent implementation.
Why bother overriding syscalls?
If you want a different sys_open, just modify/rewrite it. Then you get a kernel that works your way without touching the syscall table (or other implementation of it) at all.
Of course this sort of rewrite cannot be acitvated/deactivated by loading/unloading a module. But that isn't necessary, use a writeable flag in /proc instead.
i.e.:sys_open(...)
{
if (activated_in_proc) my_sys_open(...); else standard_sys_open(...);
}
Helge Hafting