[lkml]   [2009]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole

* Markus Gutschke (顧孟勤) <> wrote:

> On Wed, May 6, 2009 at 14:29, Ingo Molnar <> wrote:
> > That's a pretty interesting usage. What would be fallback mode you
> > are using if the kernel doesnt have seccomp built in? Completely
> > non-sandboxed? Or a ptrace/PTRACE_SYSCALL based sandbox?
> 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. It is very attractive that kernel
> automatically terminates any application that violates the very
> well-defined constraints of the sandbox.
> In general, we are currently exploring different options based on
> general availability, functionality, and complexity of
> implementation. Seccomp is a good middle ground that we expect to
> be able to use in the medium term to provide an acceptable
> solution for a large segment of Linux users. Although the
> restriction to just four unfiltered system calls is painful.

Which other system calls would you like to use? Futexes might be
one, for fast synchronization primitives?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-05-07 00:23    [W:0.104 / U:5.904 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site