Linux sandbox debugging

[Sunny Sachanandani]

Hi security-dev,

We've been seeing a couple of bugs about high cpu usage in the GPU process that involve the GL driver making a syscall that's blocked by the sandbox. We've tried using strace and other tools but it's not clear what the failure is. I understand that seccomp allows some sort of debugging by sending a SIGSYS when a syscall is blocked. It looks like Mozilla uses this for error reporting. Is there something similar in Chrome? Getting a stack trace for each failed syscall would be awesome.

Thanks!

Sunny

[Julien Tinnes]

Hi Sunny,

Yes, we have a similar mechanism in Chromium and many system calls trigger a "crash" by design because we don't expect them to ever be used.

See https://src.chromium.org/chrome/trunk/src/sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc

If you're not seeing a crash, then the syscall is "gracefully denied", meaning we almost certainly return EPERM or ENOENT. The problem is that userland is sadly failing silently without reporting any error where it should.

There is a mechanism in the sandbox that would allow the sandbox to hook every system calls and still make a decision (in userland) on which one to let through or to deny. See UnsafeTrap here: https://src.chromium.org/chrome/trunk/src/sandbox/linux/seccomp-bpf/sandbox_bpf.h

Unfortunately, we've never finished plugging this in a user-friendly way (https://crbug.com/389383) and it would require some manual work to use.

A potentially quicker alternative could be for you to try and bisect allowing some system call ranges in the GPU policy (bpf_gpu_policy_linux.cc) and see if you can figure out which one you need to allow.

Julien

[Ricky Zhou]

Hey, just checking back - did you manage to figure out the offending
syscall here? Happy to come by and take a look if you'd like some more
eyes on it.

Thanks,
Ricky