Slashdot Mirror


TSYNC Not a Hard Requirement For Google Chrome After All

An anonymous reader writes A few days ago it appeared that Google began requiring new versions of the Linux kernel for the Chrome/Chromium web browser. To some people, such requirement smelled funny, and it turns out that those people had the right hunch. Google does not intend for there to be a hard requirement on the latest versions of the Linux kernel that expose SECCOMP_FILTER_FLAG_TSYNC, but instead many users are hitting an issue around it. A Chromium developer commented on the related bug: "Updating the title so that people who have been mislead into thinking non-TSYNC kernels were deprecated immediately understand that there is simply 'some unknown bug' hitting some users." Of course, a user having the TSYNC feature in his kernel will still get a security benefit.

26 of 46 comments (clear)

  1. What's the story? by Pope+Hagbard · · Score: 1

    Google Chrome had a bug, it was reported, and it'll be fixed.

    1. Re:What's the story? by hyperar · · Score: 2

      People, the problem is the people

    2. Re:What's the story? by Ixokai · · Score: 1

      The story is that yesterday (the day before? I dunno, bad with time and don't feel like looking it up) \. reported that Chrome required TSYNC going forward. That was not true, thus, this story correcting that stance.

    3. Re:What's the story? by Anonymous Coward · · Score: 3, Interesting

      The earlier story was trying to make Debian look arbitrary and anti-Google for not making changes to a frozen release.
      It's important to retract that and clarify that this is all about a bug on Google's part.

    4. Re:What's the story? by hyperar · · Score: 1

      That too.

    5. Re:What's the story? by Sarten-X · · Score: 1

      The real story is that Slashdot is actually admitting it was wrong.

      --
      You do not have a moral or legal right to do absolutely anything you want.
    6. Re:What's the story? by petermgreen · · Score: 3, Informative

      Chrome/chromium stopped working properly on at least some systems running kernels without the tsync feature (which is a very new feature). At the time people assumed that google was intentionally requiring the new feature. Chromium is one of those programs where the only reasonable way to support it is to keep upgrading to new upstream versions. Even Debian breaks from their normal policies when it comes to major web browsers.

      It's one thing to break with your normal policies of "security and major bugfixes only" for updates to a web browser. It's altogether more contraversial if doing so requires making changes to core system components to support said web browser hence why this situation blew up a few days ago.

      Google has now clarified that chromium is supposed to work without the kernel feature in question.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    7. Re:What's the story? by amalcolm · · Score: 1

      Grow up

      --
      Time for bed, said Zebedee - boing
    8. Re:What's the story? by Anonymous Coward · · Score: 1

      Actually it makes Debian look even worse. They rushed to spout "Google spyware" nonsense without even checking if the TSYNC feature is actually required or not.

    9. Re:What's the story? by Pope+Hagbard · · Score: 1

      That kind of reflexive paranoia isn't exactly news, though, if you've been on Slashdot as long as your userid implies.

    10. Re:What's the story? by Rob+Y. · · Score: 1

      True, true.

      --
      Posted from my Android phone. Oh, I can change this? There, that's better...
  2. what is tsync? by bluefoxlucid · · Score: 3, Interesting

    Googling for "TSYNC" or "Linux TSYNC" or "what is TSYNC" brings up shittons of news about Chrome, but nothing about tsync.

    1. Re:what is tsync? by Anonymous Coward · · Score: 1

      Have a look at the comments in the previous article, lots of talk about that:

      http://linux.slashdot.org/story/15/03/08/1224210/google-chrome-requires-tsync-support-under-linux

  3. For those who don't know what this TSYNC thing is by bigHairyDog · · Score: 5, Informative

    The linux seccomp feature provides application sandboxing. Chrome uses it to sandbox tabs from each other and native plugins from the rest of the system.

    Seccomp is accessed through the seccomp (2) system call. The SECCOMP_FILTER_FLAG_TSYNC flag is an option to seccomp (2) that transparently synchronises the effect of the call across all sandboxed threads.

    --

    foo mane padme hum

  4. CNN all over again by LordLimecat · · Score: 1

    Just to clarify here, the story is that Slashdot posted an incorrect and hysterical headline a few days ago, that has been refuted, and now Slashdot is making another story about it.

    Its amazing, even when there's no news, Slashdot can use this technique to report complete BS and then report on the expose of said BS! Endless news cycle!

  5. Just assure me.. by Chris+Mattern · · Score: 3, Funny

    ...it won't require NSYNC.

    1. Re:Just assure me.. by whovian · · Score: 1

      But what if Goo-gle wants it thaa-at way?

      --
      To-do List: Receive telemarketing call during a tornado warning. Check.
    2. Re:Just assure me.. by SeaFox · · Score: 1

      ...it won't require NSYNC.

      If it does, you're free to kiss Chome Bye-Bye-Bye.
      But with the Google services integration you might enjoy, this can't exactly be called a No Strings Attached relationship.

  6. but what about my google outrage?! by Gravis+Zero · · Score: 1

    come on, you tell me google is trying to destroy everything good about the world and now you say they aren't? what am i supposed to do with this google outrage now?! editors, this type of sloppiness is OUTRAGEOUS! nevermind... problem solved itself.

    --
    Anons need not reply. Questions end with a question mark.
  7. At least they try to do their job by jones_supa · · Score: 1

    Chrome's is one of the best open source bug trackers in my opinion. There's a lot of activity from Google engineers trying to solve the problems reported. Contrast that to something like Launchpad, where my typical experience is crickets chirping and at most I get template answers like "have you tried the latest upstream kernel if it solves the problem".

    It's good to keep an eye which projects provide the best support, if we want high quality software.

    1. Re:At least they try to do their job by jones_supa · · Score: 1

      That is much more than a template answer. The answer he gave might upset some people, but at least it is a honest answer that clearly explains the situation. Much better than letting the bug just ferment there for months and years without any information about its faith.

    2. Re:At least they try to do their job by jones_supa · · Score: 1

      Fair counterargument.

    3. Re:At least they try to do their job by mangobrain · · Score: 2

      They usually say "that bug was fixed already in our latest version. Go bug your distro to update their packages." And thus the buck is ever passed.

      That is not passing the buck, that is upstream developers correctly leaving packaging up to the distribution maintainers. If I release a piece of open-source software, and it gets packaged (by people other than myself) for multiple Linux distributions, do I - as upstream maintainer - suddenly become responsible for the care and maintenance of those packages, in distributions I may not even be aware were packaging my software, let alone have any sort of commit access to? Would you expect me to go through the rigmarole of becoming a Debian developer, for example, just so that I can ensure the Debian package of my software (which I didn't even create, I just release tarballs of code) is always bleeding edge?

      If a distribution moves too slowly for your tastes, that is a problem with the distribution, and upstream are not beholden to you to fix it.

  8. Re:Reasonable conclusion by Anonymous Coward · · Score: 1

    comment #47 in the Chrome bug report flagged the bug as WONTFIX over 4 months ago -- and now all of a sudden the bug gets activity after the earlier Slashdot article this past weekend. So lets lay the facts out there:

    1) Bug opened against Google Chrome over 7 months ago
    2) About 4 months ago, Google developers closed the bug as WONTFIX and told people to "upgrade their Linux Kernels"
    3) This past weekend, Debian distro (which doesn't even ship Chrome) was asked to backport Google's TSYNC feature into Debian's friggin LONG TERM SUPPORT release, so Chrome could function in that OS release.
    4) Debian kernel maintainer (rightfully) refused to do so.

    Besides, that still doesn't change the fact that a Debian developer rejected the TSYNC flag patch because of his animosity toward Google and not based on any technical merit.

    *shock* why would anyone have any animosity? Goggle sits on their bug for months, and then forces their users to reach out to kernel developers to get Google's application functional.

  9. Re:Reasonable conclusion by Anonymous Coward · · Score: 1

    comment #47 in the Chrome bug report flagged the bug as WONTFIX over 4 months ago -- and now all of a sudden the bug gets activity after the earlier Slashdot article this past weekend. So lets lay the facts out there:

    1) Bug opened against Google Chrome over 7 months ago
    2) About 4 months ago, Google developers closed the bug as WONTFIX and told people to "upgrade their Linux Kernels"
    3) This past weekend, Debian distro (which doesn't even ship Chrome) was asked to backport Google's TSYNC feature into Debian's friggin LONG TERM SUPPORT release, so Chrome could function in that OS release.

    It's not "Google's TSYNC" feature. Debian's kernel already has the secccomp feature (which was developed outside of Google) in it. The patch that came out in July (well before Debian's freeze date of Nov 5th) is simply a corrective to a potential bug.

    http://lkml.iu.edu/hypermail/linux/kernel/1407.2/01728.html

    There was an unneeded sanity check in the TSYNC code that was causing
    the first filter applied to not allow the TSYNC flag. Additionally,
    this optimizes the thread loops to skip "current". It was harmless, but
    better to not cause problems in the future.

    4) Debian kernel maintainer (rightfully) refused to do so.

    He didn't refuse because of the freeze, he did so because he hates all things Google.

    Besides, that still doesn't change the fact that a Debian developer rejected the TSYNC flag patch because of his animosity toward Google and not based on any technical merit.

    *shock* why would anyone have any animosity? Goggle sits on their bug for months, and then forces their users to reach out to kernel developers to get Google's application functional.

    This will affect any application using that particular seccomp features, not just Chrome.

  10. Not a hard requirement eh? No shit! by grandmofftarkin · · Score: 1

    When the first posting came out I tried current Chrome versions from all release channels on a machine with a generic unpatched 3.2.45 Linux kernel and tried installing various extensions. No problems and no error. All the rage and seemingly none of the those commenting bothered to check if the report was true or not.