SECCOMP-BPF: Added support for greylisting of system calls.

sandbox/linux/seccomp-bpf/syscall.h

Index: sandbox/linux/seccomp-bpf/syscall.h
diff --git a/sandbox/linux/seccomp-bpf/syscall.h b/sandbox/linux/seccomp-bpf/syscall.h
new file mode 100644
index 0000000000000000000000000000000000000000..932e398015881d710759dd9295cc9fdabccb41fd
--- /dev/null
+++ b/sandbox/linux/seccomp-bpf/syscall.h
@@ -0,0 +1,23 @@
+// Copyright (c) 2012 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef SANDBOX_LINUX_SECCOMP_BPF_SYSCALL_H__
+#define SANDBOX_LINUX_SECCOMP_BPF_SYSCALL_H__
+
+#include <signal.h>
+#include <stdint.h>
+
+namespace playground2 {
+
+// We have to make sure that we have a single "magic" return address for
+// our system calls, which we can check from within a BPF filter. This
+// works by writing a little bit of asm() code that a) enters the kernel, and
+// that also b) can be invoked in a way that computes this return address.
+// Passing "nr" as "-1" computes the "magic" return address. Passing any
+// other value invokes the appropriate system call.
+intptr_t SandboxSyscall(int nr, ...);

[jln (very slow on Chromium), 2012/11/21 23:04:46]

The Argument type should be specified here.

[Markus (顧孟勤), 2012/11/22 00:29:23]

Can you elaborate what you want here. This is the same API that glibc's
syscall() exposes. And it has pretty much the same caveats.

It's somewhat dangerous to use and requires an understanding of how the kernel
and the ABI passes arguments. It is the caller's responsibility to be make sure
that it passes arguments that the ABI will handle correctly.

For x86-32 this means any 32bit integer type is probably OK. But trying to pass
a 64bit type is pretty much guaranteed to cause a bug.

For x86-64 this means that it has to be a type that will be passed in one of the
integer CPU registers. Both 32bit and 64bit is typically OK. The only caveat is
the sixth argument which will be passed on the stack. If this is a 64bit type,
it has to explicitly passed as such. I believe, the only time when this matters
is when passing a NULL. As C++ defines it as "0", the compiler would erroneously
forget to zero out the MSB. So, NULL should always be cast to (void *)NULL. For
the first five arguments this probably doesn't matter as x86-64 adds missing
zero bits when setting CPU registers. syscall() has the same problem.

For ARM, it has to be a type that will be passed in one of the regular 32bit CPU
registers. In practice, this means any 32bit type is fine. Don't know what ARM
64bit will look like yet.

I understand that this API is problematic. But I am not sure there is a good
alternative unless we want to force callers to always pass in six "void *"
arguments. This would require explicit casting. Often, it would be difficult to
do with C++ casts (see my other comments). And in fact, it is almost as easy to
introduce subtle bugs. I had to fix a bunch of those in existing code.

Also, it would differ from the API that users are used to see (i.e. glibc's
implementation of syscall()).

The upside of all of this is that this is an internal API that we don't plan on
exposing. ForwardSyscall() is a much easier to use API, that has most of the
same functionality.

[jln (very slow on Chromium), 2012/11/22 01:12:39]

Yeah, I took a somewhat long look at it today, and I thought that in our high
level, C++ implementation of SandboxSyscall() we should try to aim for better
type checks that glibc's syscall().

glibc's syscall() is implemented per-architecture (for instance see
sysdeps/unix/sysv/linux/x86_64/syscall.S), while ours is portable, between
already three architectures. However, you got me somewhat convinced that it
would look ugly no matter what.

+
+}  // namespace
+
+#endif  // SANDBOX_LINUX_SECCOMP_BPF_SYSCALL_H__