Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole

* Markus Gutschke (顧孟勤) [off-list ref] wrote:

On Wed, May 6, 2009 at 14:54, Ingo Molnar [off-list ref] wrote:

quoted

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