Re: seccomp for 2.6.11-rc1-bk8

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > > > Yes, but do you care about the performance of syscalls
> > > > which the program isn't allowed to call at all ? ;)
> > > 
> > > Heh, no, but it's for every syscall not just denied ones.  Point is
> > > simply that ptrace (complexity aside) doesn't scale the same.
> > 
> > seccomp is about CPU-intense calculation jobs - the only syscalls
> > allowed are read/write (and sigreturn). UML implements a full kernel
> > via ptrace and CPU-intense applications run at native speed.
> 
> Indeed. Performance is not an issue (in the short term at least, since
> those syscalls will be probably network bound).
> 
> The only reason I couldn't use ptrace is what you found, that is the oom
> killing of the parent (or a mistake of the CPU seller that kills it by
> mistake by hand, I must prevent him to screw himself ;). Even after
> fixing ptrace, I've an hard time to prefer ptrace, when a simple,
> localized and self contained solution like seccomp is available.

Well, seccomp is also getting very little testing, when ptrace gets a
lot of testing; I know that seccomp is simple, but I believe testing
coverage still make ptrace better choice.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!