Questions about utrace

[Ali Polatel]

Ananth N Mavinakayanahalli yazmış:
> On Sat, Sep 05, 2009 at 06:01:58PM +0300, Ali Polatel wrote:
> > Hey everyone,
> > I've been writing a ptrace based sandboxing tool, called sydbox¹, and I
> > want to explain about some of my bad experiences with ptrace and whether
> > utrace will fix these deficiencies.
> > 
> > First of all ptrace() makes it rather hard writing portable code that
> > will work for every architecture. You have to find out registry numbers
> > for every architecture. It would be really nice if there were a common
> > interface like utrace_get_syscall(), utrace_set_syscall() that
> > works for every architecture supported.
> 
> Have you looked at using syscall_get_(nr/error/arguments/return_value)
> et al in arch/<arch>/include/asm/syscall.h

This is exactly what I wanted!

> > Basically sydbox intercepts some system calls and checks their
> > arguments. Using ptrace, however, it's not possible to stop the children
> > only at the entry of system calls we are interested in but we have to
> > stop them at _every_ system call and check for the system call number.
> > Because of this threaded applications run very slowly under sydbox as we
> > have to stop them at every sched_yield(). I know that utrace will split
> > PTRACE_SYSCALL into two calls SYSCALL_ENTRY and SYSCALL_EXIT and this is
> > really cool but maybe the ability to stop the children only at system
> > calls the caller is interested in is a better idea.
> 
> Utrace engine callbacks happen in the traced task context and as such,
> are extremely fast. For the case you have, it isn't difficult for your
> ops->report_syscall_entry to either do a UTRACE_STOP/UTRACE_RESUME
> depending on what syscall_get_nr() returned.

Sounds cool.

> Aside, have you looked at seccomp? The utrace/seccomp branch on the
> utrace git tree has some work Roland had done earlier to make seccomp
> use utrace.

I've just checked it out and the interface looks a lot cleaner.
I'm really impressed, thanks for the hard work!
Are there any assumptions when utrace will be merged?

> Ananth
> 

-- 
Regards,
Ali Polatel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/utrace-devel/attachments/20090907/198a7a00/attachment.sig>