Linux: Seccomp TSYNC kernel support and Chromium

[Julien Tinnes]

Hi Michael,

I thought I would reach out to you to explain a few things about Seccomp TSYNC:

- If TSYNC support is detected, Chromium will use it.

- No version of Chromium (including the latest M42 version) currently requires TSYNC (chrome://sandbox "adequately sandboxed" report does not currently depend on TSYNC being there or not).

- We have seen kernels in the wild that do not report "ENOSYS" on unimplemented system calls. This can trip our kernel features detection mechanism (trigger a CHECK() to fail and a crash). See sandbox/linux/seccomp-bpf/sandbox_bpf.cc:KernelSupportsSeccompTsync().

It happened in https://crbug.com/439795 and my fear is that some other distributions might have similar kernel bugs.

Julien

[Mike Frysinger]

it's not just distros that can break this :(

linux-3.15 had a broken audit implementation that caused unknown syscalls to do badness:

  https://bugs.gentoo.org/513308

and i think the stable team backported it to a few versions too before it was caught :/

fwiw though, it seems to be a relatively uncommon issue.  Gentoo has a check specifically for syscall(<bignum>) to make sure ENOSYS is returned.  and the thing about Gentoo is that (1) we don't mandate a kernel, so users run a lot of different ones and (2) the Gentoo/prefix project runs Gentoo in a user's homedir on a diff distro, so we've gotten feedback wrt random kernels (RHEL/CentOS/etc...).

might be worth adding an explicit syscall(10000) check and making sure it returns ENOSYS ?  should be pretty cheap.

-mike

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Julien Tinnes]

What would you do if it does not return ENOSYS, crash?

I could indeed make it more obvious what's going wrong and we could print "kernel does not return ENOSYS on unimplemented system calls, aborting".

Besides crashing, I'm not sure what we would want to do. Working around kernel bugs is dangerous and can introduce complexity and bugs.

Thanks,

Julien

[Mike Frysinger]

since the check is at build time, we effectively crash -- we display an error message and exit (1). thus it's now the user's problem to fix their kernel. Gentoo has this liberty though as a from source distro.

if there's fallback logic to handle unavailable TSYNC already, then also running that path when syscall is broken sounds reasonable. not sure if it's possible to throw up a butter bar somewhere without completely spamming things. maybe do it when chrome first starts up independent of the sandbox? have it say something like your kernel is broken and link to a page on dev.chromium.org to explain in more detail?

I agree that in general we don't want to get into the business of trying to recover from a broken kernel. each case would be a judgement call and weigh the pros/cons. but if it's easy to detect & warn, I'd lean that direction.
-mike