Chrome/Chromium To Require Newer Version Of Linux Kernel

Written by Michael Larabel in Google on 8 March 2015 at 09:37 AM EDT. 32 Comments
Those using the bleeding-edge version of Google's Chrome/Chromium web-browser are discovering you need to be using a relatively new version of the Linux kernel to avoid issues.

Those running pre-3.17 kernels are discovering that for Chrome 39+ you need to be using Linux 3.17 or newer otherwise any Chrome extension or app will report a error about the process crashing. Many early adopters have encountered this issue and have been forced to upgrade their Linux kernel, per this Google Chromium issue report.

The reason for Chrome/Chromium breaking on older kernels is the need for SECCOMP_FILTER_FLAG_TSYNC, which is only found in recent versions of the Linux kernel. Kees Cook of the Chromium team was the one originally publishing the TSYNC code for the Linux kernel. Kees explained in the patch implementing SECCOMP_FILTER_FLAG_TSYNC:
Applying restrictive seccomp filter programs to large or diverse codebases often requires handling threads which may be started early in the process lifetime (e.g., by code that is linked in). While it is possible to apply permissive programs prior to process start up, it is difficult to further restrict the kernel ABI to those threads after that point.

This change adds a new seccomp syscall flag to SECCOMP_SET_MODE_FILTER for synchronizing thread group seccomp filters at filter installation time.

When calling seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, filter) an attempt will be made to synchronize all threads in current's threadgroup to its new seccomp filter program. This is possible iff all threads are using a filter that is an ancestor to the filter current is attempting to synchronize to. NULL filters (where the task is running as SECCOMP_MODE_NONE) are also treated as ancestors allowing threads to be transitioned into SECCOMP_MODE_FILTER. If prctrl(PR_SET_NO_NEW_PRIVS, ...) has been set on the calling thread, no_new_privs will be set for all synchronized threads too. On success, 0 is returned. On failure, the pid of one of the failing threads will be returned and no filters will have been applied.
The alternative to upgrading the kernel version would be patching the older kernels with this feature, to which Ubuntu 14.10 and other distributions have already started doing so. There's this mailing list post requesting said support from the Debian camp for 8.0 Jessie, but the Debian developers seem less enthusiastic about porting this TSYNC support to their kernel for Google.
Related News
About The Author
Author picture

Michael Larabel is the principal author of and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via

Popular News This Week