Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Bug Chrome Google Upgrades Linux

Google Chrome Requires TSYNC Support Under Linux 338

An anonymous reader writes Google's Chrome/Chromium web browser does not support slightly older versions of the Linux kernel anymore. Linux 3.17 is now the minimum requirement. According to a thread on the Debian mailing list, a kernel feature called TSYNC is what makes the difference. When a backported patch for the Debian 8 kernel was requested, there were hostile replies about not wanting to support "Google spyware."
This discussion has been archived. No new comments can be posted.

Google Chrome Requires TSYNC Support Under Linux

Comments Filter:
  • This is unfortunate. I was hoping to not upgrade my Ubuntu 12.04 systems for another year or two, until the systemd dust settles, and I know other people in the same boat.
    • by allo ( 1728082 )

      you can use the debian LTS version of chromium. Where is the problem?

      • Every package is not supported in the LTS distribution. Chromium for example is not supported.

  • by Enry ( 630 ) <> on Sunday March 08, 2015 @08:24AM (#49209099) Journal

    This doesn't pass the sniff test. This 'bug' has apparently been around for months (October/November) and it's just now that people are noticing? And the fix is patching the kernel rather than regressing whatever change was in Chrome that added this?

    • by gl4ss ( 559668 )

      well with chrome you would be shit out of luck to change it if google will not.

      with chromium though there should be a patch... or maybe not. googles answer to their own projects has been to backport the patch.

    • by Anonymous Coward on Sunday March 08, 2015 @09:09AM (#49209225)

      It's not a bug. Google's Chromium team decided the Linux kernel seccomp API wasn't meeting their needs, so they added the TSYNC feature (which makes applying seccomp sandboxing to child threads easier to do securely) to the kernel so they could use it in their code. They just aren't caring about the fact that not a lot of users have good reasons to be running older kernels. And it's complicated by the fact that they didn't get the kernel feature in before Debian jessie's feature freeze. Once again because they don't seem to care about other people's software lifecycles.

      • Re: (Score:2, Informative)

        by Anonymous Coward

        The patch was committed in July, and Jessie's freeze started on the Nov. 5th.

    • by Anonymous Coward on Sunday March 08, 2015 @12:19PM (#49210217)

      People are only noticing now because Google recently announced that future versions of Chromium (and thus Chrome) will only work with kernels that have this flag. It's a silly controversy because a Debian kernel maintainer just categorically rejected adding the patch not on any technical merit, but simply because he doesn't like Google. And as far as rejecting the patch because the freeze, well, that doesn't really fly since this patch was offered back in October of last year. In fact, Ubuntu already backported the patch for 12.04 lts kernel (3.13) and higher. So its not as if Debian couldn't have added the patch before the freeze. Apparently, this patch is simply being rejected because of a pathetic personal animosity towards the developer of patch, or the company he works for (Google).

  • What's TSYNC ? (Score:5, Interesting)

    by itzly ( 3699663 ) on Sunday March 08, 2015 @08:31AM (#49209123)

    Would have been nice if TFS had included an explanation of what the TSYNC feature is.

    • Re:What's TSYNC ? (Score:5, Informative)

      by Eunuchswear ( 210685 ) on Sunday March 08, 2015 @08:40AM (#49209145) Journal

      It's not the "TSYNC feature", it's SECCOMP_FILTER_FLAG_TSYNC []

      (Buggered if I know what it's for, however).

      • Re:What's TSYNC ? (Score:5, Informative)

        by Anonymous Coward on Sunday March 08, 2015 @09:12AM (#49209247)

        It's part of the "sandboxing" mechanism in Linux which allows processes to limit their interactions with the kernel to a subset of API calls by installing filter programs. The purpose of this limitation is known as the concept of least privilege: A process should not have more power to do anything than it needs to do its job. If it has more power, then an attacker can use that power in case he achieves control over that process. That's why you don't run your web server as the root user, for example. Server processes often start as high-privilege processes (for example to be able to attach to network ports lower than 1024), and then shed their privileges by switching to a limited user. Seccomp is a more fine-grained way of limiting the powers of processes. If a process tries to use a kernel API that it has previously denied itself access to, the kernel kills the process. For example, a process which in its normal operation never needs to access the file system can install a filter program which denies it all access to the file system API of the kernel. If an attacker injects code into the process to access the file system, the API call will then get the process killed instead of accessing the file system. The TSYNC feature enables a process to refine (limit more) whatever limited access a group of threads previously had (TSYNC stands for thread synchronization).

        • Thanks. If I understand your summary correctly, this sounds like a good security feature, apart from the "killing the process" bit. This seems like a handy mechanism for DOS attacks. Why not just refuse to do the unwanted thing and ignore it, while perhaps logging the attempt?

          • Re: (Score:2, Informative)

            by Anonymous Coward

            If the process does something that it promised not to do, it can't be trusted anymore and must not be allowed to continue. The first attempt to use an unauthorized API seals its fate. The server or application can just spawn a new process.

          • by arth1 ( 260657 )

            This still doesn't explain why a userland program would require it? Is Chrome trying to foist the sandbox over on the kernel and relying on the kernel killing Chrome if the user installs an extension that isn't kosher?
            If so, it would seem like a good way to get users to stop using Chrome, because there would be no indication that's understandable by a mere user of why the app suddenly quit. Or am I guessing wrong here?

          • I for one hate trying to track oddities and buggy software down which is especially harder when there are no logs or evidence of the mibehavior.

    • Re:What's TSYNC ? (Score:5, Informative)

      by vadim_t ( 324782 ) on Sunday March 08, 2015 @08:49AM (#49209163) Homepage

      Digging around a bit this is what I gathered:

      TSYNC is some flag added to seccomp to aid in something relating to thread synchronization: http://patchwork.linux-mips.or... []

      And seccomp is a security mechanism of the Linux kernel used to implement the sandbox in Google Chrome, which it uses for instance to run the Flash plugin in such a way that it doesn't compromise the system if one of its many security weaknesses: []

      None of this seems to have any relation to spyware, in fact it would seem to have the exact contrary purpose: protecting the system from potentially malicious code and security exploits.

      Unless I'm missing something obvious, it sounds like Ben Hutchins (the Debian mailing list guy who made the comment on spyware) just dislikes Chrome for whatever reason unrelated to TSYNC and decided that it would be a fine way to ensure new versions of Chrome don't run.

      • The actual replies are worse than the slashdot summary; when someone asked for TSYNC support, the answer was "sounds like another good reason not to use Google Spyware". The followup are in the same vein about Flash.
        Now one can have his opinion and think that Chrome/Flash are evil incarnates and must be wiped out from our universe, that doesn't change the fact that Flash still exist, is still in use by an awful lot of websites, and Chrome is the only way to get this content under Linux. Telling people "na
      • Re:What's TSYNC ? (Score:5, Informative)

        by Ben Hutchings ( 4651 ) on Sunday March 08, 2015 @10:18AM (#49209539) Homepage

        I do dislike Chrome and I'm not going to pretend otherwise. Aside from its being spyware (in its default configuration), the Chrome/Chromium developers have previously added requirements that make Chromium unsupportable in Debian 7 []. We could add this kernel feature now, but I strongly doubt that will be sufficient to keep Chrome/Chromium running on Debian 8 until its EOL.

        Please note that I am not NAKing the change, but I'm also not going to be the one to make it happen.

        • Do you honestly think your vocal opposition would not stand in the way of another developer deciding to get it in?

    • by epine ( 68316 )

      Would have been nice if TFS had included an explanation of what the TSYNC feature is.

      This would be inconsistent with masses of people clicking into the discussion thread going "WTF?" and then sticking around to post a comment.

      I'd quit Slashdot in a heartbeat (abandoning what limited loyalty remains) if I were willing to wade through the alternatives in search of an alternative forum in which the paragraph as a unit of discourse has not yet been un-invented.

      Back in grade nine, back in the 1970s, in a school

  • Rather than adding new code to your kernel, why not simply remove new code (whatever breaks without this TSYNC) from your browser? If this code was recently added, it just can't be that difficult to remove.

    You are compiling it yourself, aren't you? I certainly do — that's what source code [] is for. What's the problem?

  • by Anonymous Coward on Sunday March 08, 2015 @08:56AM (#49209181)

    The general issue here is that running a fairly large, popular application now requires a kernel patch that was authored by the same organization that wrote the application. Moreover, the kernel version including this patch is well newer than what's shipped by most mainstream distributions, AND the application vendor is fairly hostile to running older versions of the application software (that wouldn't require this patch).


    1. Vendor isn't willing to think about distribution support timelines
    2. Vendor doesn't seem to care about kernel/userspace boundaries and very happily writes code on both sides to an interface they've designed themselves, for themselves.
    3. Profit?

    Yes, doing it this way is notably easier for Google. This is generally considered one of the selling points of a closed ecosystem: you don't have to care about little things like public interfaces and what's already in the field (and going to be there for a decade): just "move fast and break stuff" because it all works in the environment that you're testing in, and you don't much care about anything else.

    • This would be a non-issue if Google supported some kind of ESR release, as Firefox has. i.e. Firefox is now at 36 but debian stable will ship with the 31.x ESR. (One can pull the 36.0 release from experimental if game)

    • True, but it's not like Chromium isn't open source. If you don't like it, fork it or at least submit a patch to remove tsync support. From some comments in the thread this sounds like a performance issue. It's there to improve multi-threading. I remember the good old days of Desktop Linux when it out performed my Win9x installs on the same hardware by a significant margin. I miss those days, and I wouldn't mind someone bringing them back.
    • by Rich0 ( 548339 )

      2. Vendor doesn't seem to care about kernel/userspace boundaries and very happily writes code on both sides to an interface they've designed themselves, for themselves.

      So, nothing ends up in Linux unless Linus lets it in, and it isn't like this was snuck in.

      Really, Google is doing the right thing here. Instead of trying to hack inter-process security in on the userspace side, they're extending the kernel to improve things. Inter-process communications/relationships/etc is one of the things the kernel is supposed to do.

      This is no more a violation of boundaries than putting modesetting in the kernel instead of running X11 as root and having it set device registers and suc

    • by Punto ( 100573 )

      Don't forget that "feature" they added some months ago where the browser arbitrarily disables add-ons that weren't approved by the vendor, without the option for the user to white list them or explicitly enable them. They're just disabled, for your own good, stop asking questions. So now you're forced to run the "developer version" which allows this, and it aggressively updates itself to the latest version every chance it gets.

    • The feature added is something that is generally useful for a large number of network applications, not just Chrome. Its a sandbox feature that other programs and servers could benefit from, not just Chrome. Given the dangers of the web browser today, you basically shouldnt be running a browser without a sandbox, the security imperative is certainly justified enough for a backporting of the feature to older kernels to add the additional security.

  • by gbcox ( 868098 ) on Sunday March 08, 2015 @09:19AM (#49209265) Homepage
    This is really a non-issue. Chrome decided to use a recent feature in the kernel. This happens all the time. Most distributions that are using the older kernel have patched. If Debian doesn't want to patch, move to another distribution or switch to Firefox. Both Fedora 20 and 21 are on 3.17 - so it isn't an issue there. Debian is notorious for using old stuff, so it may be the kernel they are using requires a multitude of changes and because of their policies they don't want to move to a more recent version. You buy into that logic when you choose to use Debian - so expect this stuff to happen. This has nothing to do with RMS or Google; rather the mismatch of using a slow to update distribution with a browser that is on the fast track.
    • by BitZtream ( 692029 ) on Sunday March 08, 2015 @09:35AM (#49209355)

      Chrome decided to use a recent feature THAT THE CHROME DEVS SUBMITTED TO THE KERNEL ... and isn't in any distribution that matters ... nor will it be for some time to come.

      The issue is that unless your running a dev/unstable branch, you aren't going to have this kernel feature and you're not going to have it in stable/LTS versions ever ...

      The application dropped support for production kernels ... because it wants a patch that isn't yet in production kernels.

      Googles foot ... they just shot a hole in it, fuck'em.

      • by gbcox ( 868098 ) on Sunday March 08, 2015 @10:25AM (#49209577) Homepage
        Oh for pete sake... It doesn't matter who created the feature... it was viewed as relevant and worthwhile otherwise Linus wouldn't have allowed it in the kernel. You'll have the kernel feature if it is backported. This appears to be all about Debian. If they choose not to backport either switch distributions or use another browser. Most people aren't going to be impacted by this. It's kinda of silly... it's the feigned internet outrage of the day.
      • by Rich0 ( 548339 ) on Sunday March 08, 2015 @10:28AM (#49209587) Homepage

        The application dropped support for production kernels ... because it wants a patch that isn't yet in production kernels.

        The feature is in several stable kernel branches. Your distro might just not support them, so either don't use Chrome, or don't use that distro, or figure out how to use a newer kernel on your distro. :)

      • by thegarbz ( 1787294 ) on Sunday March 08, 2015 @10:29AM (#49209595)


        Putting something in bold doesn't in any way make it relevant. Chrome devs didn't put it into the kernel, they submitted it as you said. There's a whole team that look after and maintain the kernel and they don't just blindly let every bit of code in. Most things go through review and go into the kernel only if Linus doesn't castrate the submitter.

        TSYNC is now a current feature of the kernel. Where it came from is entirely irrelevant.

        Also given the market share of Chrome on Linux in the wider scheme of the internet I think they may have only shot off the tip of one toenail. The foot will be fine.

  • It'll get backported (Score:3, Informative)

    by facetube ( 4023065 ) on Sunday March 08, 2015 @09:53AM (#49209437)
    Ubuntu already appears to have a seccomp-tsync backport to 3.16.x: [].
  • I'm on Debian 7 Wheezy, running Google Chrome 40.something

    Is that supposed to not work?

  • by lophophore ( 4087 ) on Sunday March 08, 2015 @12:39PM (#49210303) Homepage

    slashdot needs peer review, or something.

    I'm running Chrome 41 on CentOS 6 -- that has kernel 2.6.32. I followed the link and one of the complaints was that Chrome remote desktop could not be installed. So I installed it. Works fine. No problems here.

    Linux 3.17 clearly is not the minimum requirement.

    (yes, it takes a shim to get Chrome to work on CentOS. It is a pain. see -- he figured out how to make it work, and it works well.)

  • is the reason why you should not let constructive users interact with ignorant technical guys.

    What is so hard about actually believing to a user that if he repots something, it may be important to him (in this case chromium/flash), for reasosn which you or he may or not like, but thich are probably there.

    If you dont like something, act non-constructive and get ideological.

  • by fahrbot-bot ( 874524 ) on Sunday March 08, 2015 @01:04PM (#49210417)
    From TFP:

    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.

    I read that as more snarky than hostile.

  • I even try Konqueror before I resort to Chromium.

The amount of beauty required launch 1 ship = 1 Millihelen