Linux Sandbox: whitelist arm64 syscalls

Linux Sandbox: whitelist arm64 syscalls

On debian/arm64, two syscalls needed whitelisting for chromium to work with seccomp:

epoll_pwait, replacing epoll_wait which is a legacy syscall not available on arm64. epoll_wait implmentation in glibc calls epoll_pwait behind scenes, so this needs to be enabled.

getrlimit, missing #ifdef for arm64 in several policy definitions. test for arm64 added for each case.

BUG=581018
R=keescook@chromium.org,jln@chromium.org,rsesek@chromium.org
TEST=Start chrome on arm64 with seccomp enabled kernel

Committed: https://crrev.com/4e8083b4ab953ba298aedfc4e79d464be15e4012
Cr-Commit-Position: refs/heads/master@{#378440}

[Kees Cook, 2016-01-21 19:23:57]

lgtm

[Robert Sesek, 2016-01-22 17:14:54]

I'm curious as to why getrlimit is required. Would it be possible to get a
stacktrace showing where that's being called from?

[Riku Voipio, 2016-01-25 13:35:19]

On 2016/01/22 17:14:54, Robert Sesek wrote:
> I'm curious as to why getrlimit is required. Would it be possible to get a
> stacktrace showing where that's being called from?

I didn't get a useful stacktrace when debugging this since the debug symbols
didn't fit the RAM of the dragonboard 410c devboard I used. I'll see if I can
get a stacktrace out using ssh -X to an arm64 server with plenty of RAM.

[Riku Voipio, 2016-01-25 13:35:53]

Description was changed from

==========
Linux Sandbox: whitelist arm64 syscalls

On debian/arm64, two syscalls needed whitelisting for chromium
to work with seccomp:

epoll_pwait, replacing epoll_wait which is a legacy syscall not
available on arm64. epoll_wait implmentation in glibc calls
epoll_pwait behind scenes, so this needs to be enabled.

getrlimit - why this gets used on arm64 but not elsewhere is not
clear. Hence this has been ifdeffed aarch64 only.

BUG=
R=keescook@chromium.org,jln@chromium.org,rsesek@chromium.org
TEST=Start chrome on arm64 with seccomp enabled kernel
==========

to

==========
Linux Sandbox: whitelist arm64 syscalls

On debian/arm64, two syscalls needed whitelisting for chromium
to work with seccomp:

epoll_pwait, replacing epoll_wait which is a legacy syscall not
available on arm64. epoll_wait implmentation in glibc calls
epoll_pwait behind scenes, so this needs to be enabled.

getrlimit - why this gets used on arm64 but not elsewhere is not
clear. Hence this has been ifdeffed aarch64 only.

BUG=581018
R=keescook@chromium.org,jln@chromium.org,rsesek@chromium.org
TEST=Start chrome on arm64 with seccomp enabled kernel
==========

[Riku Voipio, 2016-01-26 06:20:59]

On 2016/01/25 13:35:19, Riku Voipio wrote:
> On 2016/01/22 17:14:54, Robert Sesek wrote:
> > I'm curious as to why getrlimit is required. Would it be possible to get a
> > stacktrace showing where that's being called from?
> 
> I didn't get a useful stacktrace when debugging this since the debug symbols
> didn't fit the RAM of the dragonboard 410c devboard I used. I'll see if I can
> get a stacktrace out using ssh -X to an arm64 server with plenty of RAM.

Here we have a stacktrace:

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
[10695:10695:0129/034232:ERROR:gl_context_glx.cc(55)] Failed to create GL
context with glXCreateContextAttribsARB.
[10695:10695:0129/034232:ERROR:gpu_info_collector.cc(42)]
gfx::GLContext::CreateGLContext failed
[10695:10695:0129/034232:ERROR:gpu_info_collector.cc(96)] Could not create
context for info collection.
[10695:10695:0129/034232:ERROR:gpu_main.cc(433)] gpu::CollectGraphicsInfo failed
(fatal).
[10695:10695:0129/034233:ERROR:gpu_child_thread.cc(243)] Exiting GPU process due
to errors during initialization
[10657:10688:0129/034241:ERROR:browser_gpu_channel_host_factory.cc(132)] Failed
to launch GPU process.
[10657:10688:0129/034241:ERROR:browser_gpu_channel_host_factory.cc(132)] Failed
to launch GPU process.
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf
failure in syscall 0163
Received signal 11 SEGV_MAPERR 0000058070a3
#0 0x00558590c42c base::debug::(anonymous namespace)::StackDumpSignalHandler()
#1 0x007fafca4510 ([vdso]+0x50f)
#2 0x005589881918 sandbox::CrashSIGSYS_Handler()
#3 0x00558987f664 sandbox::Trap::SigSys()
#4 0x007fafca4510 ([vdso]+0x50f)
#5 0x007fad616f08 getrlimit64
#6 0x00558593975c base::GetMaxFds()
#7 0x00558822ae70 content::CompositorOutputSurface::BindToClient()
#8 0x0055862161c8 cc::LayerTreeHostImpl::InitializeRenderer()
#9 0x00558622d65c cc::ThreadProxy::InitializeOutputSurfaceOnImplThread()
#10 0x005585973ce8 base::debug::TaskAnnotator::RunTask()
#11 0x005585927ba4 base::MessageLoop::RunTask()
#12 0x005585927e94 base::MessageLoop::DeferOrRunPendingTask()
#13 0x0055859280a4 base::MessageLoop::DoWork()
#14 0x0055859298e8 base::MessagePumpDefault::Run()
#15 0x00558593af14 base::RunLoop::Run()
#16 0x005585927040 base::MessageLoop::Run()
#17 0x005585957798 base::Thread::ThreadMain()
#18 0x005585953d38 base::(anonymous namespace)::ThreadFunc()
#19 0x007fad6a7e34 start_thread
[end of stack trace]

looks like a arch-indep fallback path in CompositorOutputSurface::BindToClient

[jln (very slow on Chromium), 2016-01-27 00:19:13]

jln@chromium.org changed reviewers:
+ mdempsky@chromium.org, rickyz@chromium.org

[jln (very slow on Chromium), 2016-01-27 00:19:17]

https://codereview.chromium.org/1613883002/diff/1/sandbox/linux/seccomp-bpf-h...
File sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc (right):

https://codereview.chromium.org/1613883002/diff/1/sandbox/linux/seccomp-bpf-h...
sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc:417: case __NR_epoll_pwait:
Why does ARM64 influence this?

https://codereview.chromium.org/1613883002/diff/1/sandbox/linux/seccomp-bpf-h...
sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc:610: case __NR_getrlimit:
getrlimit is already somewhere else in this file. The general policy is that
this file splits system calls into disjoint sets.

If one really decides to allow getrlimit, this should be a baseline policy
change.

[Riku Voipio, 2016-01-27 15:37:27]

https://codereview.chromium.org/1613883002/diff/1/sandbox/linux/seccomp-bpf-h...
File sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc (right):

https://codereview.chromium.org/1613883002/diff/1/sandbox/linux/seccomp-bpf-h...
sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc:417: case __NR_epoll_pwait:
On 2016/01/27 00:19:17, jln (very slow on Chromium) wrote:
> Why does ARM64 influence this?

The glibc function epoll_wait() will call epoll_pwait() syscall on arm64 since
epoll_wait is a legacy syscall that doesn't exist on arm64.

https://codereview.chromium.org/1613883002/diff/1/sandbox/linux/seccomp-bpf-h...
sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc:610: case __NR_getrlimit:
On 2016/01/27 00:19:17, jln (very slow on Chromium) wrote:
> getrlimit is already somewhere else in this file. The general policy is that
> this file splits system calls into disjoint sets.

> If one really decides to allow getrlimit, this should be a baseline policy
> change.

Thanks, this was the part of my patches I was most uncomfortable with.

Following the backtrace in previous mail, does it warrant a change in baseline
policy?

Further tests show that even on arm64/linux chromium works sandboxed without
calling getrlimit(), if the opengl stack is available. If it isn't - due to
using X via ssh -X or because vendor opengl driver are crap, chromium will crash
on the seccomp error on start.

[Robert Sesek, 2016-01-27 16:52:31]

https://codereview.chromium.org/1613883002/diff/1/sandbox/linux/seccomp-bpf-h...
File sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc (right):

https://codereview.chromium.org/1613883002/diff/1/sandbox/linux/seccomp-bpf-h...
sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc:610: case __NR_getrlimit:
On 2016/01/27 15:37:27, Riku Voipio wrote:
> On 2016/01/27 00:19:17, jln (very slow on Chromium) wrote:
> > getrlimit is already somewhere else in this file. The general policy is that
> > this file splits system calls into disjoint sets.
> 
> > If one really decides to allow getrlimit, this should be a baseline policy
> > change.
> 
> Thanks, this was the part of my patches I was most uncomfortable with.
> 
> Following the backtrace in previous mail, does it warrant a change in baseline
> policy?
> 
> Further tests show that even on arm64/linux chromium works sandboxed without
> calling getrlimit(), if the opengl stack is available. If it isn't - due to
> using X via ssh -X or because vendor opengl driver are crap, chromium will
crash
> on the seccomp error on start.

An alternative if we wanted to keep restricting getrlimit would be to cache the
result of base::GetMaxFds() (or base::SharedMemory::GetHandleLimit() which is
calling that function), and then ensure the value is cached as part of sandbox
warmup.

[Riku Voipio, 2016-02-03 13:50:35]

riku.voipio@linaro.org changed reviewers:
+ sky@chromium.org

[Riku Voipio, 2016-02-03 13:51:17]

After looking around I found out that my crash is because getrlimit is allowed
in the renderer policy, but is missing #ifdef for aarch64. I've amended the
patch to enable getrlimit on arm64 in the policies where it is already allowed
on other architectures.

[Riku Voipio, 2016-02-09 18:29:49]

Description was changed from

==========
Linux Sandbox: whitelist arm64 syscalls

On debian/arm64, two syscalls needed whitelisting for chromium
to work with seccomp:

epoll_pwait, replacing epoll_wait which is a legacy syscall not
available on arm64. epoll_wait implmentation in glibc calls
epoll_pwait behind scenes, so this needs to be enabled.

getrlimit - why this gets used on arm64 but not elsewhere is not
clear. Hence this has been ifdeffed aarch64 only.

BUG=581018
R=keescook@chromium.org,jln@chromium.org,rsesek@chromium.org
TEST=Start chrome on arm64 with seccomp enabled kernel
==========

to

==========
Linux Sandbox: whitelist arm64 syscalls

On debian/arm64, two syscalls needed whitelisting for chromium to work with
seccomp:

epoll_pwait, replacing epoll_wait which is a legacy syscall not available on
arm64. epoll_wait implmentation in glibc calls epoll_pwait behind scenes, so
this needs to be enabled.

getrlimit, missing #ifdef for arm64 in several policy definitions. test for
arm64 added for each case.

BUG=581018
R=keescook@chromium.org,jln@chromium.org,rsesek@chromium.org
TEST=Start chrome on arm64 with seccomp enabled kernel
==========

[Riku Voipio, 2016-02-09 18:33:44]

Thanks for all reviews so far. This is the last patch needed close bug #581018
(arm64 sandboxing fixes).

Riku

[mdempsky, 2016-02-09 19:30:17]

The CQ bit was checked by mdempsky@chromium.org

[mdempsky, 2016-02-09 19:30:17]

lgtm

[mdempsky, 2016-02-09 19:30:17]

The patchset sent to the CQ was uploaded after l-g-t-m from
keescook@chromium.org
Link to the patchset: https://codereview.chromium.org/1613883002/#ps20001
(title: "whitelist getrilimit in inherited policies")

[commit-bot: I haz the power, 2016-02-09 19:34:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1613883002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1613883002/20001

[commit-bot: I haz the power, 2016-02-09 19:41:00]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-09 19:41:00]

Try jobs failed on following builders:
  android_arm64_dbg_recipe on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_chromium_gn_compile_rel on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_chro...)
  android_clang_dbg_recipe on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_compile_dbg on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  chromeos_amd64-generic_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  chromeos_daisy_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  chromeos_x86-generic_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_x86-ge...)
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
  linux_chromium_chromeos_compile_dbg_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_32_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
  win8_chromium_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_ng/...)
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Riku Voipio, 2016-02-10 13:42:20]

On 2016/02/09 19:41:00, commit-bot: I haz the power wrote:
> Try jobs failed on following builders:

Rebased against upstream, apparently some files had moved while this patch was
being developed.

[mdempsky, 2016-02-10 21:56:51]

The CQ bit was checked by mdempsky@chromium.org

[mdempsky, 2016-02-10 21:56:51]

The patchset sent to the CQ was uploaded after l-g-t-m from
mdempsky@chromium.org, keescook@chromium.org
Link to the patchset: https://codereview.chromium.org/1613883002/#ps40001
(title: "rebase to apply on head")

[commit-bot: I haz the power, 2016-02-10 22:00:47]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1613883002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1613883002/40001

[commit-bot: I haz the power, 2016-02-10 22:17:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-10 22:17:38]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Riku Voipio, 2016-02-11 14:21:48]

riku.voipio@linaro.org changed reviewers:
+ ben@chromium.org

[sky, 2016-02-11 16:49:01]

sky@chromium.org changed reviewers:
+ erg@chromium.org

[sky, 2016-02-11 16:49:01]

+erg for change to mojo/shell/runner/host/linux_sandbox.cc

[Elliot Glaysher, 2016-02-11 18:39:05]

https://codereview.chromium.org/1613883002/diff/40001/mojo/shell/runner/host/...
File mojo/shell/runner/host/linux_sandbox.cc (right):

https://codereview.chromium.org/1613883002/diff/40001/mojo/shell/runner/host/...
mojo/shell/runner/host/linux_sandbox.cc:80: #if !defined(__aarch64__)
So I'm not an expert on this, but doesn't this mean that access() and open() are
now allowed inside the sandbox on aarch64? (Instead of trapping and sending to
the broker.)

[mdempsky, 2016-02-11 18:48:13]

https://codereview.chromium.org/1613883002/diff/40001/mojo/shell/runner/host/...
File mojo/shell/runner/host/linux_sandbox.cc (right):

https://codereview.chromium.org/1613883002/diff/40001/mojo/shell/runner/host/...
mojo/shell/runner/host/linux_sandbox.cc:80: #if !defined(__aarch64__)
On 2016/02/11 18:39:05, Elliot Glaysher wrote:
> So I'm not an expert on this, but doesn't this mean that access() and open()
are
> now allowed inside the sandbox on aarch64? (Instead of trapping and sending to
> the broker.)

__NR_access and __NR_open don't exist on ARM64.  The userspace access() and
open() functions use the generic faccessat and openat system calls.

[Elliot Glaysher, 2016-02-11 18:53:43]

On 2016/02/11 18:48:13, mdempsky wrote:
>
https://codereview.chromium.org/1613883002/diff/40001/mojo/shell/runner/host/...
> File mojo/shell/runner/host/linux_sandbox.cc (right):
> 
>
https://codereview.chromium.org/1613883002/diff/40001/mojo/shell/runner/host/...
> mojo/shell/runner/host/linux_sandbox.cc:80: #if !defined(__aarch64__)
> On 2016/02/11 18:39:05, Elliot Glaysher wrote:
> > So I'm not an expert on this, but doesn't this mean that access() and open()
> are
> > now allowed inside the sandbox on aarch64? (Instead of trapping and sending
to
> > the broker.)
> 
> __NR_access and __NR_open don't exist on ARM64.  The userspace access() and
> open() functions use the generic faccessat and openat system calls.

I see. dir lgtm then.

[Riku Voipio, 2016-02-16 13:52:13]

On 2016/02/11 18:53:43, Elliot Glaysher wrote:
> I see. dir lgtm then.

It looks like the files 

components/nacl/loader/sandbox_linux/nacl_bpf_sandbox_linux.cc 
mojo/shell/runner/host/linux_sandbox.cc

still need lgtm from owners (jln and rickyz?)

[rickyz (no longer on Chrome), 2016-02-16 20:41:54]

lgtm, thanks!

[Riku Voipio, 2016-02-26 19:29:25]

riku.voipio@linaro.org changed reviewers:
+ mseaborn@chromium.org

[jln (very slow on Chromium), 2016-02-26 19:45:42]

Owner lgtm based on previous reviews.

[Riku Voipio, 2016-02-26 19:49:53]

The CQ bit was checked by riku.voipio@linaro.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-26 19:53:01]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1613883002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1613883002/40001

[Mark Seaborn, 2016-02-26 20:25:30]

https://codereview.chromium.org/1613883002/diff/40001/components/nacl/loader/...
File components/nacl/loader/sandbox_linux/nacl_bpf_sandbox_linux.cc (right):

https://codereview.chromium.org/1613883002/diff/40001/components/nacl/loader/...
components/nacl/loader/sandbox_linux/nacl_bpf_sandbox_linux.cc:110:
defined(__aarch64__)
This implies that we support running this NaCl code on ARM64, which isn't the
case, so it's a bit misleading to add this.  I assume you just added this for
consistency with the other files?

[commit-bot: I haz the power, 2016-02-26 20:46:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-26 20:46:58]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Riku Voipio, 2016-02-29 10:19:13]

On 2016/02/26 20:25:30, Mark Seaborn wrote:
>
https://codereview.chromium.org/1613883002/diff/40001/components/nacl/loader/...
> File components/nacl/loader/sandbox_linux/nacl_bpf_sandbox_linux.cc (right):
> 
>
https://codereview.chromium.org/1613883002/diff/40001/components/nacl/loader/...
> components/nacl/loader/sandbox_linux/nacl_bpf_sandbox_linux.cc:110:
> defined(__aarch64__)

> This implies that we support running this NaCl code on ARM64, which isn't the
> case, so it's a bit misleading to add this.  I assume you just added this for
> consistency with the other files?

Consistency and to have the ifdef already there if/when someone starts working
on NaCl. If Arm64 nacl is considered unlikely to happen, I can drop this file
from the patch sure.

[Riku Voipio, 2016-02-29 19:08:27]

The CQ bit was checked by riku.voipio@linaro.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-29 19:08:35]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1613883002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1613883002/40001

[commit-bot: I haz the power, 2016-02-29 19:17:35]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-29 19:17:36]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Riku Voipio, 2016-03-01 15:51:32]

The CQ bit was checked by riku.voipio@linaro.org

[commit-bot: I haz the power, 2016-03-01 15:51:56]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1613883002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1613883002/40001

[commit-bot: I haz the power, 2016-03-01 16:02:53]

Description was changed from

==========
Linux Sandbox: whitelist arm64 syscalls

On debian/arm64, two syscalls needed whitelisting for chromium to work with
seccomp:

epoll_pwait, replacing epoll_wait which is a legacy syscall not available on
arm64. epoll_wait implmentation in glibc calls epoll_pwait behind scenes, so
this needs to be enabled.

getrlimit, missing #ifdef for arm64 in several policy definitions. test for
arm64 added for each case.

BUG=581018
R=keescook@chromium.org,jln@chromium.org,rsesek@chromium.org
TEST=Start chrome on arm64 with seccomp enabled kernel
==========

to

==========
Linux Sandbox: whitelist arm64 syscalls

On debian/arm64, two syscalls needed whitelisting for chromium to work with
seccomp:

epoll_pwait, replacing epoll_wait which is a legacy syscall not available on
arm64. epoll_wait implmentation in glibc calls epoll_pwait behind scenes, so
this needs to be enabled.

getrlimit, missing #ifdef for arm64 in several policy definitions. test for
arm64 added for each case.

BUG=581018
R=keescook@chromium.org,jln@chromium.org,rsesek@chromium.org
TEST=Start chrome on arm64 with seccomp enabled kernel
==========

[commit-bot: I haz the power, 2016-03-01 16:02:54]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-03-01 16:04:19]

Description was changed from

==========
Linux Sandbox: whitelist arm64 syscalls

On debian/arm64, two syscalls needed whitelisting for chromium to work with
seccomp:

epoll_pwait, replacing epoll_wait which is a legacy syscall not available on
arm64. epoll_wait implmentation in glibc calls epoll_pwait behind scenes, so
this needs to be enabled.

getrlimit, missing #ifdef for arm64 in several policy definitions. test for
arm64 added for each case.

BUG=581018
R=keescook@chromium.org,jln@chromium.org,rsesek@chromium.org
TEST=Start chrome on arm64 with seccomp enabled kernel
==========

to

==========
Linux Sandbox: whitelist arm64 syscalls

On debian/arm64, two syscalls needed whitelisting for chromium to work with
seccomp:

epoll_pwait, replacing epoll_wait which is a legacy syscall not available on
arm64. epoll_wait implmentation in glibc calls epoll_pwait behind scenes, so
this needs to be enabled.

getrlimit, missing #ifdef for arm64 in several policy definitions. test for
arm64 added for each case.

BUG=581018
R=keescook@chromium.org,jln@chromium.org,rsesek@chromium.org
TEST=Start chrome on arm64 with seccomp enabled kernel

Committed: https://crrev.com/4e8083b4ab953ba298aedfc4e79d464be15e4012
Cr-Commit-Position: refs/heads/master@{#378440}
==========

[commit-bot: I haz the power, 2016-03-01 16:04:21]

Patchset 3 (id:??) landed as
https://crrev.com/4e8083b4ab953ba298aedfc4e79d464be15e4012
Cr-Commit-Position: refs/heads/master@{#378440}