Google Chromium drops support for Linux 3.16 and earlier | Hacker News Reader

Google Chromium drops support for Linux 3.16 and earlier

lists.debian.org

139 pointsxai3luGi130 comments

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

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."

At least there seems to be a supported method for updating the 14.04 kernel: https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#LTS_Hardware...

Apparently, Ubuntu 14.04.2 installs a 3.16 kernel by default, and previous 14.04 installs can be updated by installing a bunch of "*-utopic" packages.

This seems like a colossal mess waiting to happen. I'm glad that I read their plan, so that I can completely avoid it.

The allure of Ubuntu LTS releases (currently 12.04 and 14.04) is the extended support cycle -- practically speaking the kernel is the biggest component of this for a lot of people.

If you use the 3.16 kernel (from Ubuntu 14.10) on 14.04, you are now on a 6 month support cycle [1]. One which doesn't even have defined dates (they're all still TBD). Now you have to keep running on the kernel upgrade treadmill to maintain support, moving to backported kernels from progressively newer Ubuntu releases every 6 months.

[1] https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Kernel.2BA...

Overreacting much? The shortened support is limited to the packages you upgrade. It's a 9 month cycle with a new version available every in 6 months. Most importantly, these are just packages, they can be uninstalled of they don't work and you fall back to LTS versions. And this is all the same for 12.04.

> practically speaking the kernel is the biggest component of this for a lot of people.

Really? I mean, step back from your initial gut reaction and ask yourself how many software developers could even name which version of the kernel their code runs on without checking. Most developers never make a syscall directly and, increasingly, aren't even calling something like libc directly because they use higher-level libraries.

Sure, some people really care cause they recently hit an issue with specific drivers and a few people are using a really new feature, but that's a much smaller group than the number of people running code which doesn't even depend on Linux, much less a specific point release.

Looking at the release notes, I'd say there are a LOT more people affected by real bugs which are fixed in 14.04.2 than will be affected by hypothetical bugs nobody seems to have noticed yet:

https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes/ChangeSummar...

For some reason, Chrome seems to work fine with extensions on my Ubuntu 14.04, kernel 3.13.

I agree with those saying this is completely stupid. In corporate environments, there are a lot of Ubuntu LTS, RHEL, and CentOS desktops. They won't be upgraded to >= 3.16 for years.

Edit: oh, wait, this starts in the next version.

Happily there's an even more reasonable workaround of upgrading to a browser that doesn't dictate kernel versions.

Yep, Decisions like "well we broke it but upgrade your kernel to fix it" is why I'm now on Chrome and not Chromium anymore.

Chrome is chromium.

Be careful there. Chrome is based on Chromium.

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.

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.

No, user software should not dictate kernel versions, unless there is no alternative (e.g. security issues). Maybe I'm unique in this, but I don't have a single-purpose workstation. My computer does not exist to run Google Chrome; I have lots of applications I like to use.

Consider a workplace setting where someone may have other software which is much more conservative about using new features. A newer kernel may cause that software to stop working entirely; upgrading a kernel rarely introduces just the feature Google Chrome wants to use. You could tell those people to just use a different browser, but there are a lot of workplace users - is this new feature right now really worth losing those users?

For all the effort the Linux community has put into keeping Linux distributions secure and making them easier to use, now Google is saying Linux users have to either know how to update their kernel outside the provided package manager to use Chrome, or use whatever older version of Chrome still supports their kernel. This is going to frustrate or alienate most new Linux users as well as veteran users who like stability and package management. Is using this new feature right now really worth losing those users as well?

Chrome is arguably the most popular browser on the Internet. They ought to be more conservative about things like this; the right way to handle a new kernel feature is to either delay its use until supported by the majority of your users, or to detect it at runtime and use it if available. IMO, what they have done here is lazy and arrogant. A very poor decision.

Agreed, though I doubt this is going to be a popular opinion. I've been steadily divesting myself of pretty much all Google products because of these sort of arrogant and obnoxious decisions.

First it was the won't fix VPN + countless other Android bugs, then repeatedly breaking Canvas in Chrome (why do I care about this? well Chrome auto-updates for 99% of users, so when they break canvas they're breaking sites) and not least the numerous platforms and products they introduced and then dropped despite vibrant & loyal user bases.

7 months.

Linux 3.16 is 7 months old. The attitude of the Chrome team is extremely obnoxious. Some distributions support versions 10 years and beyond and there are plenty of reasonable reasons to want to use them as such. Requiring a 7 month old kernel is absurd.

I keep getting the feeling that Chrome isn't the browser for me.

Without defending Chrome team here; when a distro provides long time support (say > 1 year) I don't think is upstream responsibility to support the packages for that period of time.

If the distro is upgrading the browser package I think that may break the API/ABI stability that a long time support distribution should provide, so I can't see why this is a Chrome problem.

Also it sounds wrong that a web browser depends on the kernel version; so I'm with you that there are other browsers supporting Linux.

Well put. Although someone makes a LTS distribution, it really does not mean 3rd parties would be compelled or required to support that steadily aging platform.

When you combine the fact that not even Ubuntu developers really support the LTS (9/10 of the developers flock to the newest release, and the bug reports towards LTS get generally ignored - the LTS tagged bug queues are graveyards), I can not see the whole point of making LTS version available in the first place.

That being said, 7 months is a bit small window of support for a specific platform component. I would understand not supporting 1-2 years old kernel/glibc/whatever, but 7 months is really not enough.

Well it's tricky, MSFT actually ties certain vendors to support their OS as long as it's under support. For example if you want to participate in the WHQL program you have to have a version for each supported MSFT OS.

Chrome is still supported on Windows XP, so is FF, on Windows vendors not only do not seem to drop support but actually extend beyond MSFT's requirements.

While canonical is surely not MSFT but when you make an LTS program you either have to get 3rd party vendors on board, or manage and update the packages yourself to make sure they will be compatible with your own software, or to make updates to your LTS distro to keep it compatible with the newer packages.

While the OS is quite important, it's usually not the piece of software neither end users nor corporate users care about, for them it's just a platform to run the software they actually use. And if the platform loses support for a major piece of software after less than a year you can't blame anyone besides the maintainer of that platform.

The Linux community really needs to get their shit together, with every step forward these past few years they've seen to be taking 2 steps back. With PAAS becoming more and more popular, it really should only take Apple to release a general server OS (no OSX Server doesn't count) to push it back completely into the realm of BBS hobbyists these days.

Actually both the bug and the kernel dates back to 7 months old as mentioned in the OP so it would actually be much shorter than 7 months.

I'm sorry, but we ARE talking about arguably the most important piece of software running on an end-user device not being supported on a less than ONE YEAR old distribution. Not 5 years, not 15 years. Less than a year.

The result of your argument is basically returning to dark ages of having to support old broken IE6 because the vendor couldn't be arsed to support an older platform. When did dropping support for a less than a year old product become something to be applauded?

My argument is that open source is what it is. Read the license and you'll find that there's nothing about free support; and if for some reason it breaks... you keep both pieces.

I know this puts distributions in a bad situation, but unless the users can force the upstream project to be more user friendly, I think the only option is to switch to a different software (hint: Firefox).

You seem to think I endorse Chrome team's behaviour on this, and I don't. That doesn't change reality though.

Open source is what it is, but not all open source is equal.

I often see versions of this argument more or less opposing complaints against open source products. It has some merit, depending on circumstances. Circumstances are important.

Chrome isn't some guy's spare time project, or something done by a team of corporate and personal volunteers. Chrome is a product. Looking for Google's valuation comes up with an analysis that it will likely be the first or second company to be valued at a trillion dollars. Chrome enjoys nearly a 50% browser market share. Google has one of the strongest hands in shaping technology today, and it seems they aren't always making the best decisions; not that one would expect such a large company to always make the best decisions (or that there would be a consensus on _what_ is the best decision).

I've never paid for anything made by Google, but I am a customer regardless; so are you. Money hasn't changed hands but they have certainly profited from the relationship, and so have I.

---

"If you don't like it, submit a pull request" -- that response always rubs me the wrong way. To be clear, some of the loudest complainers about open source projects are entirely too entitled, but those that aren't do have a point sometimes. I believe that whether you are a guy with a hobby making $0 or a company valued at $3.8 * 10^11, you owe it to yourself and your users to maintain a certain level of quality if you create a popular product. More of a personal philosophy than the expectation of a legal obligation of course, but I think just as valid.

Good comment, thanks.

I always have mixed feelings when Google has a project with two versions: the open source one and the binary only based on that one. Chrome and Chromium are not quite the same thing after all.

I don't know for sure, but for Google Chrome may be the product and Chromium just a convenient way to make it happen.

A year is not along time 10-20 years is a long time

7 months is too short, but 10 years is too long to go for a workstation, which is where Chrome would be used.

What about Windows XP? It still holds more than 50% Chinese market.

What about XP? It's old, unsupported and littered with security holes. It has 50% penetration in China because it's the last version of Windows with easily circumvented piracy countermeasures and because it runs better on 10-year-old hardware. I don't think it's any guide to how long long-term support should be.

First, I'll note that plenty of people use Chrome without extensions. This issue wasn't a showstopper for any of them.

Second, you cut out the rest of the comment:

"If that causes great hardship for anyone and you want to do the work to figure out what's going on submit patches to fix it, I can provide pointers for where to start looking and code reviews for the patch."

Since that comment has anyone done anything other than updating their kernel and/or complaining? If not, why would the Chromium team think this issue was important?

I wonder if any distro's Chromium package had a patch.

I don't think the other half of that comment affects my point: that the Chrome team is declining to fix bugs that only manifest on older kernels, and hence it's reasonable to call those kernels "unsupported".

I agree that it's the Chrome team's prerogative to decide that supporting those kernels is unimportant.

So you only care about problems if the user is a skilled developer, and then only if they're actively solving the bug (because skilled programmers are never involved in other projects eating their time...)?

I'm pretty sure that's the exact audience they had in mind when opensourcing (note that closed-source Chrome is still available for Linux).

Lots of people are stuck on RHEL6 which means we have to use a wrapper to get chrome installed.

I'm on 3.10 kernel branch and have no issues installing extensions.

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.

The feature might very well be backported to 3.10.

When you commit to a 10-year support cycle, you'd better be prepared to backport quite a few things.

Google's being aggressive about taking advantage of a kernel-level security feature that they developed to solve a real problem. This seems like a good thing overall.

> When you commit to a 10-year support cycle, you'd better be prepared to backport quite a few things.

OTOH, when you make a break-the-world release every six weeks, you can expect lots of breakage when dealing with the rest of the world. From what I can tell, Google pushed a feature they wanted into Linux, then didn't bother to think about backward compatibility. This would be fine if Chrome weren't force-updating software -- people on older kernels could just wait and update when they updated their kernels -- but alas that is not the case.

Chrome doesn't force-update on Linux. You can just install it and not accept any updates.

And if you don't upgrade you get moaned at by gmail et al until you do.

And then people wonder why normal users go for Windows and Mac OS X systems for their desktops.

It'd be nice if they used some of their massive pile of cash to back-port that feature and generate a ton of good will.

Google does a lot of Linux kernel work, a lot of gcc work, a lot of clang work, open-sources monumental amounts of code, pays several hundred students to work on open-source during summer.

If that's not enough to "generate a ton of good will" then doing one more minor thing won't change anything.

If they start giving out hundred dollar bills, you'll be complaining that it's not two hundred dollar bills.

I'm aware of the work they do. A couple of stupid decisions can cancel out a lot of good will. Not back-porting key pieces of tech and sunsetting products without open-sourcing them is going to counteract the good will they generate. I actually don't dislike Google, and appreciate that they've been a decent open-source player.

This is not so minor.

If they start handing out hundred dollar bills I would think they'd gone nuts.

"Google's being aggressive about taking advantage of a kernel-level security feature that they developed to solve a real problem. This seems like a good thing overall."

Yes, it is a good thing for the people who 1) use desktop linux and 2) use a rolling distribution or a distribution that was released within the last year. I suspect that might be a rather small percentage of the Desktop users in the world.

It simply means that people who 1) use a desktop Linux and 2) use a stable distribution can't run Chrome (which I imagine solves the security problem in another way). This fraction of a fraction may be larger (corporate desktops, e.g. RHEL, CentOS, Scientific Linux, Debian stable, Ubuntu LTS &c)

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.

On the flip side, chrome is also one of the tools used to convince people that web should somehow be equivalent to native. Which, really, just doesn't make any bloody sense.

If web pages were content to showing web sites, the vast majority of the motivation for heavy sandboxing, Chrome style, would be irrelevant.

You have code running on your computer for rendering the content. Historically, pictures (GDI+ buffer overflow, and others) and .pdf files has been used for exploiting bugs in that code. Sandboxing would have made that a non-issue, or at least less severe of an issue.

It's still a serious issue even with a sandbox, both because of the endless stream of kernel vulnerabilities and similar issues in userspace processes the sandboxed processes communicate with to get work done.

Chromium's use of seccomp-bpf is solely to crack down on kernel vulnerabilities, as it's an additional layer over a sandbox already providing all of the security boundaries they need. It moves things along pretty far, but there are still at least 1-2 holes found every year.

It's definitely an improvement over browsers like Firefox where there are at least 3-4 unmitigated remote code execution vulnerabilities fixed every six week cycle...

Chrome did? IE7 shipped with pretty tight sandboxing in 2006 — and Chrome was only announced in 2008!

Only on Vista and later though.

well let's see. in 2014 there were 214 code exploits in IE vs 4 in Chrome. I don't think IE's sandbox can really be considered tight

http://www.cvedetails.com/product/9900/Microsoft-Internet-Ex...

http://www.cvedetails.com/product/15031/Google-Chrome.html?v...

Still doesn't change the fact that Chrome did not "pioneer" sandboxing.

If the pioneer dies before he gets to california, he doesn't get the credit.

There is no Windows sandbox (including the Chromium one) that's comparable to the quality of Chromium's Linux implementation.

Note that seccomp is a layer on top of the layer-1 sandbox implementation based on a chroot and namespaces. There is no equivalent to the layer-2 sandbox used to protect against kernel vulnerabilities on other platforms.

Google invented sandboxing in client apps? I don't know who's more arrogant - Google or their fawning fanboys.

Calling comex a "fawning fanboy"? That's ballsy for a throwaway account.

Claiming that Chrome pioneered sandboxing doesn't pass the smell test, irrespective of how many Google employees (according to your profile) are backing you up.

But do you know who comex is? People sometimes are not exactly precise and sometimes make mistakes too.

  But do you know who comex is?

I didn't, and it was not that easy to find out, but I was curious. He is Nicholas Allegra and he is known for jailbreaking the iPhone. See http://www.androidbeat.com/2013/04/google-comex/ and http://www.forbes.com/sites/andygreenberg/2011/08/01/meet-co.... He went on to work for Apple and now for Google, apparently on the Chome or Chrome OS teams.

Damn, now honestthrowaway looks even more foolish. I can understand why he used a throwaway now.

No one is claiming that Google invented sandboxing. You should stop lying to push your bias because it only makes you look foolish.

Wouldn't comex be the "Google" in the comment, rather than the "fanboy"?

comex doesn't work for Google.

Google created seccomp-bpf which is crucial to a meaningful sandbox and has no equivalent on other platforms. It was not an obvious innovation or it would have been done years earlier. It exists because someone paid by Google to improve Chromium security had the epiphany that BPF would be a good way to filter system calls.

Isn't seccomp-bpf similar to OpenBSD's (failed) systrace? Both are basically filters for system calls if I'm not mistaken.

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..)

What comex meant is Chrome pioneered the use of seccomp-bpf. And indeed, Chrome is by far the application using seccomp-bpf in the most advanced way.

> 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..)

You're quite confused. SELinux, AppArmor, SMACK, etc. do not overlap with seccomp-bpf which exists to protect the kernel itself. Chromium has a working sandbox with or without seccomp-bpf based on a chroot, namespaces and IPC protocols. It needs seccomp to mitigate kernel vulnerabilities, which are not at all uncommon.

they actually do the control in a very similar way. its the model of how the control is decided that differs. in other words, they're all blocking syscalls depending on the arguments/syscall name/etc. LSMs and seccomp-bpf alike.

So no, I'm not confused :)

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. 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. "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. "Do not re-invent the wheel: It is tempting to extend the OS kernel with a better security model. Don't.".

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.

RHEL/CentOS 6 has been unsupported for quite a while by chrome before this had happened.

I assume they'll either drop support altogether or will support RHEL 7 until RHEL 8 is shipped like they did with RHEL 6.

They don't care that most people don't jump ship and upgrade RHEL as soon as a new release exists.

I don't think the Chrome dev team would want to drop earlier kernels that easily, but this option must help development a lot. From looking, it seems to be something regarding synchronising SECCOMP filters between different threads (SECCOMP is a security sandbox). I imagine this removes quite a bit of code, or fixes some serious corner cases.

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.

That seems like an exceedingly childish exchange.

It's common way to see things now, although I guess it's pretty normal. I always viewed distro as something people do primarily for themselves, if you want something from particular distro — you join the community. If your wishes are drastically different from what this community accepts — you go to another community or build your own. I'm not saying people should be rude and talk nonsense, but it seems that too many people tend to forget: Debian mailing list (or lkml, or what else people complain about) is not Starbucks or McDonalds where people are paid to smile and do what's requested.

That's been said, I find question about TSYNC completely appropriate, and its support to be expected, but answer about "Google spyware" was funny and enjoyable anyway. So, yeah, maybe childish, but not "exceedingly childish".

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

No. More than it used to be, but it's not comon.

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

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.

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.

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.

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

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.

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)).

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.

I don't really think this is a particularly childish exchange. But either way, it struck me that when you consider the reason for the exchange: a unilateral decision made by Google -- that kind of reminds me of how Google handles support: they don't.

On another note - does chrome/chromium build on freebsd? Is there an equivalent api there?

I certainly sympathize with the chrome/chormium team: they're of course free to abandon users on old kernels/os'. It is a bit odd to demand a new kernel (newer than most Android installs uses) for a browser. We've come to learn to live with not having stable and secure browsers (choose either - usually choosing the updated, secure browser makes more sense). It's a bit more hairy when you need a new kernel. But I suppose newer hardware can just run Chrome (or chrome os) in a kvm vm anyway...

That seemed unprofessional to me too.

But the problem for debian is that Jessie is frozen, they can't make any changes now. They don't want an exception for this.

maks has always been a complete tosser.

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.

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

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...

Google has backported this to ChromiumOS

https://code.google.com/p/chromium/issues/detail?id=430588

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

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

https://lwn.net/Articles/603815/

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

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1379020 http://lists.infradead.org/pipermail/linux-arm-kernel/2014-J...

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

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

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.

it synchronize all the process's threads to use the same seccomp filter (seccomp being a sandbox mechanism - a bit like a firewall for system calls).

Threads on Linux are very close to an equivalent of "separate process" except they share memory. Up to until seccomp tsync, only the thread calling seccomp and it's children would get the seccomp filter.

If you wanted to have seccomp in previously started threads you'd have to handle a broadcast in userspace and ensure all threads actually apply the same seccomp filter.

I bet they ran into issues with that (it's easy to forget a thread or have a new thread someone elses coded that will fail to apply the filter).

tsync is kernel side and explicitly fails/succeeds so its both simpler and safer.

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

[1] https://lists.debian.org/debian-security-announce/2015/msg00...

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.

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.

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

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

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.

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.

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

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.

Ubuntu already backported TSYNC months ago.

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

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).

Some browsers have different goals. Is that a problem?

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.

I'm not sure I would say its supremely arrogant to tell them to upgrade their kernels. I'm sure if they realized that they were breaking sub 3.16 kernels they would of announced it before hand, but they fudged that. So instead of fixing it to not use a kernel feature they wanted to use, they just said "well this sucks"

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.

It is not a regression :)

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.

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.

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

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

Kinda surprising... but not really.

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

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

A security (sandboxing) extension.

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).

Reply on news.ycombinator.com