Re: System call instrumentation

[Arjan van de Ven <arjan@infradead.org>]

On Mon, 19 May 2008 23:44:53 -0400
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:

> * Ingo Molnar (mingo@elte.hu) wrote:
> > 
> > * Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> > 
> > > Ideally, I'd like to have this kind of high-level information :
> > > 
> > > event name : kernel syscall
> > > syscall name : open
> > > arg1 (%s) : "somefile"    <-----
> > > arg2 (%d) : flags
> > > arg3 (%d) : mode
> > > 
> > > However, "somefile" has to be read from userspace. With the
> > > protection involved, it would cause a performance impact to read
> > > it a second time rather than tracing the string once it's been
> > > copied to kernel-space.

the audit subsystem already does all of this... why not use that??
(And it goes through great lengths to do it securely)

> > 

> Hrm, a quick benchmark on my pentium 4 comparing a normal open()
> system call executed in a loop to a modified open() syscall which
> executes the lines added in the following patch adds 450 cycles to
> each open() system call. I added a putname/getname on purpose to see
> the cost of a second userspace copy and it's not exactly free.

copying twice does mean that if the user wants, he can cheat you. He
can, in another thread, change the string under you. So say you're
doing this for anti-virus purposes, he can make you scan one file and
open another.


The audit subsystem was carefully designed to avoid this trap... how
about using that?