Linux sandbox: Restrict sched_* and ioprio_* calls in the cros arm GPU policy.

sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc

Index: sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
diff --git a/sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc b/sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
index de59dd888d8f123c7cb7fa9eb6a778c5c33b2940..301e78719c8e82a7536d2769a2e479a1acb45965 100644
--- a/sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
+++ b/sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
@@ -249,6 +249,14 @@ ResultExpr RestrictGetSetpriority(pid_t target_pid) {
       .Else(CrashSIGSYS());
 }
 
+ResultExpr RestrictIoPrioGetSet(pid_t target_pid) {
+  const Arg<int> which(0);
+  const Arg<int> who(1);
+  return If(which == PRIO_PROCESS,
+            If(who == 0 || who == target_pid, Allow()).Else(Error(EPERM)))

[jln (very slow on Chromium), 2014/10/09 00:31:24]

No case spotted of who == gettid() ?

That's good news. Did you get any sense of what wraps these calls in practice?
Could they be directly used by a GPU driver?
If we don't feel confident it can't happen, I wonder if we shouldn't have a
SIGSYS again here to support this case.

+      .Else(CrashSIGSYS());
+}
+
 ResultExpr RestrictClockID() {
   COMPILE_ASSERT(4 == sizeof(clockid_t), clockid_is_not_32bit);
   const Arg<clockid_t> clockid(0);