> Ptrace has performance and/or reliability problems when used to> sandbox threaded applications due to potential race conditions when> inspecting system call arguments. We hope that we can avoid this> problem with seccomp.

ptrace certainly has performance issues. I take it the only "reliabilityproblems" you are talking about are MT races with modifications to usermemory that is relevant to a system call. (Is there something else?)That is not a "ptrace problem" per se at all. It's an intrinsic problemwith any method based on "generic" syscall interception, if the filteringand enforcement decisions depend on examining user memory. By the sametoken, no such method has a "reliability problem" if the filtering checksonly examine the registers (or other thread-synchronous state).

In the sense that I mean, seccomp is "generic syscall interception" too.(That is, the checks/enforcement are "around" the call, rather than insideit with direct atomicity controls binding the checks and uses together.)The only reason seccomp does not have this "reliability problem" is thatits filtering is trivial and depends only on registers (in fact, only onone register, the syscall number).

If you want to do checks that depend on shared or volatile state, thensyscall interception is really not the proper mechanism for you. (Likelyexamples include user memory, e.g. for file names in open calls, or ioctlstruct contents, etc., fd tables or filesystem details, etc.) For thatyou need mechanisms that look at stable kernel copies of user data thatare what the syscall will actually use, such as is done by audit, LSM, etc.

If you only have checks confined to thread-synchronous state such as theuser registers, then you don't have any "reliability problem" regardlessof the the particular syscall interception mechanism you use. (ptrace hasmany problems for this or any other purpose, but this is not one of them.)That's unless you are referring to some other "reliability problem" thatI'm not aware of. (And I'll leave aside the "is it registers or is ituser memory?" issue on ia64 as irrelevant, since, you know, it's ia64.)

If syscall interception is indeed an appropriate mechanism for your needsand you want something tailored more specifically to your exact use infuture kernels, a module doing this would be easy to implement using theutrace API. (That might be a "compelling use" of utrace by virtue of theMidas brand name effect, if nothing else. ;-)