
Google Chromium drops support for Linux 3.16 and earlier - xai3luGi
https://lists.debian.org/debian-kernel/2015/03/msg00133.html
======
teraflop
Chrome "unofficially" dropped support for pre-3.16 kernels, such as the kernel
in Ubuntu 14.04 LTS, about half a year ago. More precisely, they introduced a
bug that caused installing extensions to fail with that kernel, and then
declined to fix it.

[https://code.google.com/p/chromium/issues/detail?id=401655](https://code.google.com/p/chromium/issues/detail?id=401655)

See comment #47: "Ok, while it sounds like this is technically a regression,
I'm going to mark this as Wontfix because there is a reasonable workaround of
updating your kernel."

~~~
rodgerd
Happily there's an _even more_ reasonable workaround of upgrading to a browser
that doesn't dictate kernel versions.

~~~
blfr
The whole point of even having a kernel is to run the software you like.
Kernel by itself doesn't really do anything for you.

There's a feature of the kernel that Chromium wants to use. That's a perfectly
good reason to upgrade.

User software should dictate kernel versions.

~~~
Lennie
Well, it's a bit more subtle than that. Because it were the Chromimum
developers which created the feature in the first place.

seccomp was introduced in the Linux kernel because the Chromium developers
wanted a good way to reduce the harm Chromium browser processes could do if
they got compromised.

Chromium is pretty much the only user of seccomp right now.

(although for example Docker also has support for it, but I don't think it's
widely used)

Now Kees Cook who implemented TSYNC for seccomp in the Linux kernel works for
Google. The kernel commit even lists his @chromium.org email address.

------
rdtsc
Really, a browser is now dependent on a particular Linux kernel?

For example RHEL/CentOS 7 which was released just last year with at least a 10
year support ahead of it is now obsolete according to them because it has a
kernel version 3.10...

Not that many people are on desktop versions of those OSes, and those that are
will not use Chrome (for example, US govt loves them some Desktop RHEL
systems, but Chrome is usually not allowed there anyway), but just
highlighting how still seems a bit crazy.

~~~
comex
Chrome isn't your average application, though - it pioneered the modern use of
tight process sandboxes in general (in client-side applications, anyway), and
in particular was the biggest motivating client for (and Kees Cook on Chrome
OS Security wrote some of the code for) seccomp-bpf, the ~3-year-old
sandboxing mechanism that allows precise control of permitted syscalls and
syscall arguments. The incompatibility here is related to a new seccomp
feature. I don't know whether it's reasonable to drop support for older
kernels, but it's no surprise that Chrome is using the latest and greatest in
kernel sandboxing support.

~~~
zobzu
Chrome certainly didn't pioneer anything. Google devs brought seccomp-bpf to
the kernel, which is a simpler alternative (but also not always as useable) to
many other mechanisms.

Chrome is one of the first products _on linux_ with a large amount of users to
support a reasonably strong sandbox. But that's not what _pioneering_ means.

Of course, seccomp-nonbpf, selinux and quite a few other mechanisms have been
around for a longer while. In non-Linux kernels in fact, there are FAR more
secure mechanisms (but also, they don't run Linux binaries..)

~~~
pacala
There is no stable sandboxed browser protecting against kernel vulnerabilities
on any platform that I know of prior to Chrome. That's the very definition of
pioneering. Do you have an example of prior art? There may be sandboxing
mechanisms in various kernels, but that's not what browser users care about.

As for the other points:

* "seccomp-nonbpf" is a vastly more limited mechanism than seccomp-bfp, and inappropriate for Chrome use-case. [http://en.wikipedia.org/wiki/Seccomp](http://en.wikipedia.org/wiki/Seccomp). seccomp-bfp is pioneering in Linux kernel space, even if, ironically, the team might not have wanted to spend their time there. See below.

* Popular consumer distribution of Linux doesn't have SELinux enabled by default. [https://wiki.ubuntu.com/SELinux](https://wiki.ubuntu.com/SELinux). "SELinux can be enabled in Ubuntu by installing the "selinux" meta-package". In my bubble we everyone uses Ubuntu on desktop, apologies to other distributions vying for the title of "popular consumer Linux distribution".

* Not sure why we are talking about security mechanisms on non-Linux kernels. Chrome is a browser, the team's job is not to innovate in the kernel space. [http://www.chromium.org/developers/design-documents/sandbox](http://www.chromium.org/developers/design-documents/sandbox). "Do not re-invent the wheel: It is tempting to extend the OS kernel with a better security model. Don't.".

~~~
zobzu
if you give enough details you'll always find a way to work around words. For
example if i ship a copy of webkit with my ui on top with a sandbox I'll
pioneer that. Or a shell. Or a text editor. Or whatever you want. A blue wheel
of 29.0349in on a bike. etc.

I'm not sure why I'm even replying sometimes.

------
jpgvm
Replies so far for the lazy:

On Sat, Mar 07, 2015 at 07:17:13PM +0200, Georgi Naplatanov wrote:

> On 03/07/2015 06:38 PM, Ben Hutchings wrote:

> > On Sat, 2015-03-07 at 16:09 +0100, D. F. wrote:

> >> Hello, Julien Tinnes from google says that next releases of

> >> chromium will drops support for kernels without TSYNC

> >> ubuntu 14.10 already has been patched

> >> Can I to expect that debian 8/jessie will have support for

> >> TSYNC?

> > Sounds like another good reason to not use Google spyware.

> Google Chrome for Linux is the only possibility to use latest version

> of Adobe flash player for Linux as far as I know.

another good reason not to use it.

\-- maks

I guess this is why Gentoo is still my distro of choice after all these years.

~~~
redthrowaway
That seems like an exceedingly childish exchange.

~~~
stingraycharles
I cannot believe these are the actual people responsible for Debian. Is this
unprofessional attitude common in the Debian community?

~~~
xai3luGi
Could you explain what you mean by "unprofessional" here? Personally Google's
business model seems to be the unprofessional thing in this conversation.

~~~
jfoster
If Debian were a business and the original poster were one of their customers,
how would the OP be feeling about that exchange?

It's unprofessional by definition because it is so clear that the person
responding does not consider this their profession.

~~~
adrusi
But it's not a business and that person wasn't a customer. Debian is a
community, bound partially by common technical ideas about packaging,
stability and security, and partially by philosophical ideas about Free
software.

Their goal is not to satisfy everyone who comes to their mailing list, that
would be insanity.

~~~
jfoster
Sure, but most people would consider the original poster's request as quite
reasonable.

Instead of considering it in a balanced way and producing a polite &
considered response, the response was idealistic rhetoric. For better or
worse, I think that does qualify the attitude of response as "unprofessional",
as stingraycharles pointed out.

~~~
chappi42
Google is the unprofessional one. Threaten to not support Jessie, hey? What an
arrogant self-referred world Google lives in?

~~~
davidw
I think Google is more or less "in the wrong" too, but a less snippy, snarky
response would probably do more to convince people of that. "You catch more
flies with honey than with vinegar", as they say.

~~~
chappi42
Probably yes.

As a non-native english speaker it is quite difficult to find an enough but
not too much snippy/snarky response (had e.g. to lookup these words)).

~~~
stingraycharles
What are you implying, that when English is not your native tongue, it is
easier to be snarky?

English is a second language to me, and I cannot imagine this being true.

------
tbrownaw
It's much more interesting to see how useful the replies are.

I assume they're because it's a dumb question, but still. This is an excellent
example of an unwelcoming / hostile culture.

~~~
axlprose
Indeed. The culture was part of the reason I made the switch from debian to
opensuse a while ago.

------
jrockway
I don't think Chromium has dropped support for kernels <= 3.16. ChromiumOS
uses 3.4, 3.8, 3.10, and 3.14 depending on device. All of those are less than
3.16, but as far as I know, ChromiumOS is not going away.

It appears a patch needs to be cherry-picked back; a pretty common task for
people that maintain older kernels. It's very common to backport patches to
drivers you care about (because new kernel versions always introduce bugs in
your obscure hardware, you only backport stuff that doesn't already work).
There is even a system for doing it in an automated manner:
[http://drvbp1.linux-foundation.org/~mcgrof/rel-
html/backport...](http://drvbp1.linux-foundation.org/~mcgrof/rel-
html/backports/)

~~~
scottlinux
Google has backported this to ChromiumOS

[https://code.google.com/p/chromium/issues/detail?id=430588](https://code.google.com/p/chromium/issues/detail?id=430588)

~~~
jrockway
Yup. So it doesn't seem that unreasonable to do the same in Debian. (Though I
already have 3.16 in Debian, so...)

------
ars
Can someone say what TSYNC is? Googling it did not help me, lots of links, but
none that said what it actually is.

~~~
nandhp
It looks like a "thread-sync" feature for seccomp.

[https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1379020](https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1379020)
[http://lists.infradead.org/pipermail/linux-arm-
kernel/2014-J...](http://lists.infradead.org/pipermail/linux-arm-
kernel/2014-July/273472.html)

seccomp ("secure computing") is an application sandboxing mechanism in the
Linux kernel (since 2.6.12, 2005-03-08). seccomp allows a process to make a
one-way transition into a "secure" state where it cannot make any system calls
except exit(), sigreturn(), read() and write() to already-open file
descriptors.

[http://en.wikipedia.org/wiki/Seccomp](http://en.wikipedia.org/wiki/Seccomp)

Chrome uses seccomp to sandbox rendering subprocesses and the Adobe Flash
Player.

~~~
justincormack
It is the seccomp type 2 mechanism, where you choose the system calls and
arguments to allow, not the early seccomp type 1 that only allowed exit, read.
That one would not really need to sync, as you cannot even create threads
afterwards.

------
kasabali
This is not the first time that Chromium team doesn't care about even slightly
older distros. Apart from the infamous RHEL 6 case, there is also the recent
wheezy case.

Back in September, there was a plan for requiring at least GCC 4.9 for
building Chromium, which made building new releases for Debian wheezy in a
pure Debian wheezy environment impossible. [0]

Debian lacks the manpower of RedHat for backporting and supporting new
software (which is GCC 4.9 for this case), so Stable Release Team and Security
Team are not the most liberal teams when it comes to approving new packages
into a stable release, and as a result, Chromium is not supported in Wheezy as
of last month. [1]

[0] [https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=763278](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=763278)

[1] [https://lists.debian.org/debian-security-
announce/2015/msg00...](https://lists.debian.org/debian-security-
announce/2015/msg00031.html)

------
zobzu
Wow that's extreme. They could broadcast seccomp across thread for older
kernels.

One day it's going to be "use Google's fork of the kernel".

Of course, Firefox and others work fine on "older" kernels.

~~~
justincormack
It is a sandbox, you cant trust the threads to apply it I guess, if they have
been hacked.

I dont understand why you need to change the seccomp filter after creation
though.

------
feld
These long term support distros are toxic to everyone except proprietary
software vendors.

~~~
Nux
You are surely joking and you're not good at it.

~~~
feld
Do you trust package maintainers at Redhat/Debian/etc to properly backport
security fixes to ancient branches? They don't exactly have a clean track
record.

Look at the terribly old / EOL software in RHEL4 that is on "extended support"
until 2017:

    
    
      Java 1.4
      SVN 1.1
      Apache 2.0
      Stunnel 4.0.5
      Python 2.3
      Glibc 2.3.4
      Firefox 1.0
    

edit: I stumbled upon some ELSA advisories a few weeks ago where additional
security updates needed to be released for Apache because the CVE for which
they intended to backport a fix was not adequately patched.

That is terrifying. There's a reason why upstream doesn't release fixes for
those old releases.

------
eeZi
The answer seems to be "yes", as Jessie has a 3.16 kernel.

Lots of speculation though - there's no official announcement, as far as I'm
aware, and the OP on the mailing list did not identify as a Google employee.

~~~
scottlinux
I believe this seccomp-tsync feature was introduced in 3.17. I can't find the
exact commit but I'm looking.

Edit:
[https://lkml.org/lkml/2014/7/18/718](https://lkml.org/lkml/2014/7/18/718)

------
pmontra
Most people update the kernel when their distro does. Ubuntu 12.04 LTS is
currently at a .5 version with kernel 3.13. There seem to be no plans for a
12.04.6 with a newer kernel but we'll see.

Maybe TSYNC can be backported to 3.13 (I'm unsure about who has to do it) or
Chromium can be compiled without TSYNC (distro's choice). If nothing happens
this is going to cost Google some users but obviously it's their browser and
their choice of how to implement it and where it can run.

~~~
ali1234
Ubuntu already backported TSYNC months ago.

~~~
pmontra
Great. I didn't know (actually I didn't know about TSYNC until today). Thank
you.

------
cnvogel
So, is this a feature that will also appear in Chrome for Android? Is there
even an overlap in codebase? [I honestly have no idea]

Given that a lot of handsets run ridiculously old Kernels, I assume that this
feature will not be usable for the next few generations of handsets (or will
have to be backported, obviously).

------
bcook
Some browsers have different goals. Is that a problem?

~~~
honestthrowaway
It's supremely arrogant to tell your users to change the kernel they are using
because you couldn't be bothered to fix a regression in your code. The problem
with that approach is self-evident.

~~~
justincormack
Well I guess their argument is they cannot provide secure sandboxing without
this feature, and they do not want to ship it with weaker security.

------
teekert
Perhaps it is a good things. Many kernel devs aparently don't like the method
of back porting fixes for ages the way Debian does. They say the Arch way is
fine and one should not be too afraid to upgrade in between. Perhaps Debian
could start trying this? In other words, is the Debian stable method still
needed in this day and age? Perhaps a good start for a discussion.

~~~
icebraining
Debian has had the "Arch way" before Arch, it's called Unstable :) Personally,
I like running that on my laptop and Stable on my server, since I like being
able to fix security issues without suddenly having some component replaced or
new functionality introduced that breaks the system and requires my
intervention. Add unattended-upgrades, and I can essentially leave it running
alone for months, if not years.

------
nickysielicki
"Most" chromiumOS developers use 14.04 LTS [1]... Which is 3.13.

[1]: [http://www.chromium.org/chromium-os/developer-
guide](http://www.chromium.org/chromium-os/developer-guide)

Kinda surprising... but not really.

------
anarcat
so what's going to happen with chromium in debian?

------
pXMzR2A
The FUCK does a browser want with the version of my kernel?

~~~
q3k
A security (sandboxing) extension.

------
derpsss
Google never gave a single fuck about older distros. It took a few days after
Debian 7 going stable that they stopped supporting Debian 6 (by requiring
newer libc).

