Re: (OpenBSD)Systrace vs (Linux) SysCallTrace

On Wed, 27 Nov 2002, Dave Feustel wrote:

> An announcement for a new Linux function (SysCallTrace) just appeared

syscalltrace seems to be ktrace with some systrace mixed in. But looking at the release announcement, it seems that they add new syscalls every release. That makes it sound like it's implemented in a non generic way. It's also for x86 only for some reason. why? I haven't looked at the code, but I don't see why it shouldn't just support all syscalls at once. [Actually, I do know why. They're patching the syscall table. systrace intercepts things before that. See note in syscalltrace FAQ.]

More notably, it seems syscalltrace runs entirely in kernel and is only for root. One thing that seems cool about syscalltrace is the "who edited that file?" feature.

> What is the system overhead involved in using these functions?
[assuming you mean systrace]
Depends on your rules. For rules that are simply "permit" it's very low, since the kernel can cache the result. If you are restricting access to certain files though, then every open() requires a context switch and a response from the systrace process. Even then, it doesn't seem too noticeable. Most apps don't sepend much time making syscalls.

--
"I am making this trip to Africa because Washington is an international
city, just like Tokyo, Nigeria or Israel.  As mayor, I am an
international symbol.  Can you deny that to Africa?"
      - M. Barry, Mayor of Washington, DC