Re: secure computing for 2.6.7

[Andrea Arcangeli <andrea@cpushare.com>]

Hi Alan,

On Mon, Aug 02, 2004 at 12:08:00AM +0100, Alan Cox wrote:
> One of the things that you can sensibly do I think which will also avoid
> a performance hit is to use the same kernel path as strace and friends
> do for syscall tracing but capture and verify the syscall in kernel mode
> rather than trapping back out. That will at least keep the usual fast
> path unharmed by the security toys.

The usual fast path is already unharmed by the security toys like
syscall auditing and seccomp mode (my only slowdown I introduced with
seccomp was to replace a testb with a testw, that doesn't count as a
slowdown, does it?). The only way to speedup the usual fast path is by
removing ptrace, everything already hooks into the ptrace testb/w.

About ptrace major issue being speed that's mostly true, but I'm not
sure what happens to uml if the tracer gets killed by oom, maybe it just
crashes at the next syscall, maybe not, dunno. I feel a lot safer in
having the secure computing happening inside seccomp than inside uml
from my part. I considered using uml before doing seccomp, but seccomp
was going to be a lot simpler and safer (and faster but I don't need
throughput in read/write/sigreturn/exit ;).