Messages in this thread |  | | | Date | Thu, 7 May 2009 00:13:19 +0200 | | From | Ingo Molnar <> | | Subject | Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole |
| |
* Markus Gutschke (顧孟勤) <markus@google.com> wrote:
> On Wed, May 6, 2009 at 14:54, Ingo Molnar <mingo@elte.hu> wrote: > > Which other system calls would you like to use? Futexes might be > > one, for fast synchronization primitives? > > There are a large number of system calls that "normal" C/C++ code > uses quite frequently, and that are not security sensitive. A > typical example would be gettimeofday(). But there are other > system calls, where the sandbox would not really need to inspect > arguments as the call does not expose any exploitable interface. > > It is currently awkward that in order to use seccomp we have to > intercept all system calls and provide alternative implementations > for them; whereas we really only care about a comparatively small > number of security critical operations that we need to restrict. > > Also, any redirected system call ends up incurring at least two > context switches, which is needlessly expensive for the large > number of trivial system calls. We are quite happy that read() and > write(), which are quite important to us, do not incur this > penalty.
doing a (per arch) bitmap of harmless syscalls and replacing the mode1_syscalls[] check with that in kernel/seccomp.c would be a pretty reasonable extension. (.config controllable perhaps, for old-style-seccomp)
It would probably be faster than the current loop over mode1_syscalls[] as well.
Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |