On Sat, Jan 21, 2006 at 01:10:13PM -0800, Kevin Van Vechten wrote:
> If you're not trying to corral a hostile environment, a simple way to
> intercept syscalls is to override them at the Libsystem layer.
> Define your own functions in a dylib, and then se the
> DYLD_INSERT_LIBRARIES and DYLD_FORCE_FLAT_NAMESPACE environment
> variables.
>
What I'm trying to do is create something like this:
http://www.cse.nd.edu/~ccl/software/parrot/
I want to be able to capture the I/O calls of an application and then
ship them back over the network to be handled by another machine.
I work on a distributed computing system (similiar to XGrid) and we
want to able to run jobs on machines that don't have access to the
same shared filesystem, so we trap system calls, send them back to the
"submitting machine" and execute them there. The remote job, as far as
it can tell, has access to all of the files as it would on the submitting
machine (yes, obviously the idea is that the compute time to system call ratio
is high, because remote system calls are many many times slower, and yes we
take care of security)
The problem with replacing at the library level is that the libraries
may have private interfaces - finding all of the call points that I need
to interpose on can be hard, and if I miss just one the game is over.
We've been doing this for years on Linux, and for the longest time we
did interpose at the library level - and every time a new Linux distro came
out and it used a new libc, we'd have to figure out what new interfaces it
was using - besides open, we needed to catch __open, __open2,
__open3OnlyUsedInOnePlace, and __somethingCalledFooButReallyOpen
Because those calls are all at user level, there was no way for us to find out
if one of them got called by some code path we didn't catch.
The system call interface was much narrower, so there are far fewer things
we need to trap. Even better, because it's a trap, we could capture ALL
of them, and anything we didn't know what to do with we could detect at
runtime. It's much slower, but we're dominated by the network latency
anyway so we didn't care.
We want to stay out of the other processes address space as much as possible,
and we certainly want to avoid executing code in the other processes address
space (I took a look at APE - as an application writer it made my skin crawl :)
Similarly, I want to avoid trapping in with a KEXT - I want to convince
other people to use my software at low-risk to themselves, and asking them
to install a KEXT doesn't jive with that. It would also mean that I'd see
every system call on the machine, which I don't want. The ideal system
lets my tracing process capture the system calls of another process running
at the same privilege level - that way, if I'm running as use 'batchsystem',
the only processes I can capture are 'batchsystem' processes.
It also seems like Apple could keep the system call interface stable
between versions - the great thing about system calls is if you need to
change the meaning of one, you can just create another system call with
a different name. You can leave the old one stable, and just change the
framework to call the new one - if someone has found a way to call the
actual system call, the can keep using it.
Thanks,
-Erik
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden
This email sent to email@hidden
