TSYNC Not a Hard Requirement For Google Chrome After All

← Back to Stories (view on slashdot.org)

TSYNC Not a Hard Requirement For Google Chrome After All

Posted by timothy on Tuesday March 10, 2015 @02:29AM from the what-we-meant-was dept.

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.

46 comments

Min score:

Reason:

Sort:

Downgrade? by Anonymous Coward · 2015-03-10 02:38 · Score: 0

TSYNC is supposed to be an improvement upon the thread syncronizing in the case of chrome's sandboxing all their tabs.
They basically made TSYNC what it is today in the kernel. And it would be stupid for them to demand it, at least this early.

Most likely people have conflicts with dev-versions, downgraded or changed kernel configs. Which are "edge-cases" that google's internal testing did not catch.
What's the story? by Pope+Hagbard · 2015-03-10 02:42 · Score: 1

Google Chrome had a bug, it was reported, and it'll be fixed.
1. Re:What's the story? by hyperar · 2015-03-10 02:43 · Score: 2
  
  People, the problem is the people
2. Re:What's the story? by Anonymous Coward · 2015-03-10 02:48 · Score: 0
  
  Google, the problem is the Google.
3. Re:What's the story? by Ixokai · 2015-03-10 02:52 · 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.
4. Re:What's the story? by Anonymous Coward · 2015-03-10 02:56 · 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.
5. Re:What's the story? by hyperar · 2015-03-10 02:57 · Score: 1
  
  That too.
6. Re:What's the story? by Sarten-X · 2015-03-10 03:03 · 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.
7. Re:What's the story? by petermgreen · 2015-03-10 03:18 · 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
8. Re:What's the story? by Anonymous Coward · 2015-03-10 03:29 · Score: 0
  
  Because if this were Windows, we'd be bitching about it for another 3 months.
9. Re:What's the story? by amalcolm · 2015-03-10 03:33 · Score: 1
  
  Grow up
  
  --
  Time for bed, said Zebedee - boing
10. Re:What's the story? by Rob+Y. · 2015-03-10 03:41 · Score: -1
  
  The real story is the wave of reflexive paranoia infecting the free software crowd. First it was "systemd is taking over and destroying Linux as we know and love it". Now it's "Google's really evil... well not evil, but we think it could become evil... well, arrogant and forcing us to adopt new technology before we're ready..."
  Okay, the "Google's evil and handing over your SSN to advertisers" meme's been around for a while now. But seriously, folks...
  
  --
  Posted from my Android phone. Oh, I can change this? There, that's better...
11. Re:What's the story? by Anonymous Coward · 2015-03-10 03:41 · Score: 0
  
  More than clarified, I'd call that retracted.
  The bug report clearly stated that it was closed as WONTFIX because "updating to a new kernel is a reasonable fix".
  That is, someone made a snafu, and some higher up at google told him to revert that decision that cause them to get so much heat. Silently. Call it a "clarification".
12. Re:What's the story? by Anonymous Coward · 2015-03-10 03:48 · 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.
13. Re:What's the story? by Pope+Hagbard · 2015-03-10 04:07 · Score: 1
  
  That kind of reflexive paranoia isn't exactly news, though, if you've been on Slashdot as long as your userid implies.
14. Re:What's the story? by Rob+Y. · 2015-03-10 04:12 · Score: 1
  
  True, true.
  
  --
  Posted from my Android phone. Oh, I can change this? There, that's better...
15. Re:What's the story? by Anonymous Coward · 2015-03-10 04:41 · Score: 0
  
  Google Chrome had a bug, it was reported, and it'll be fixed.
  The Chrome bug was reported 7 months ago -- Google is just now acknowledging it this week. It was probably the bad press from the previous slashdot article that got Google to change their stance on the bug.
16. Re:What's the story? by Anonymous Coward · 2015-03-10 09:29 · Score: 0
  
  The issue report linked from the original story showed people were getting Chrome working with kernels going back to 3.13, so it should have been obvious to anybody with eyes that 3.17 w/TSYNC was not a real requirement.
GNAA has HARD requirements for memberSHIP by Anonymous Coward · 2015-03-10 02:58 · Score: 0

which I don't fulfill.
what is tsync? by bluefoxlucid · 2015-03-10 02:59 · Score: 3, Interesting

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

--
Support my political activism on Patreon.
1. Re:what is tsync? by Anonymous Coward · 2015-03-10 03:10 · 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
2. Re:what is tsync? by ledow · 2015-03-10 03:52 · Score: 0
  
  It's a thread synchronisation instruction available on certain processors.
3. Re:what is tsync? by Anonymous Coward · 2015-03-10 04:57 · Score: 0
  
  Your question was answered below.
For those who don't know what this TSYNC thing is by bigHairyDog · 2015-03-10 03:06 · 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
CNN all over again by LordLimecat · 2015-03-10 03:25 · 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!
Just assure me.. by Chris+Mattern · 2015-03-10 03:42 · Score: 3, Funny

...it won't require NSYNC.
1. Re:Just assure me.. by whovian · 2015-03-10 05:11 · 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 Anonymous Coward · 2015-03-10 05:33 · Score: 0
  
  wrong boy band
3. Re:Just assure me.. by SeaFox · 2015-03-10 07:31 · 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.
but what about my google outrage?! by Gravis+Zero · 2015-03-10 03:44 · 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.
Reasonable conclusion by Anonymous Coward · 2015-03-10 03:51 · Score: -1

Comment from a Chromium developer in the bug report:

#47 asargent@chromium.org
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.
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.
From that comment it wasn't unreasonable to conclude that chrome and chromium would only work on systems running with a kernel version of 3.17 and later, or with older kernels that had backported the patch and had support for the secomp features. Only today was the comment added that corrected that assumption. 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.
1. Re:Reasonable conclusion by Anonymous Coward · 2015-03-10 05:19 · 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.
2. Re:Reasonable conclusion by Anonymous Coward · 2015-03-10 06:39 · Score: 0
  
  Comment from a Chromium developer in the bug report:
  
  #47 asargent@chromium.org
  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.
  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.
  From that comment it wasn't unreasonable to conclude that chrome and chromium would only work on systems running with a kernel version of 3.17 and later, or with older kernels that had backported the patch and had support for the secomp features. Only today was the comment added that corrected that assumption. 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.
  How is this considered trollish? Mod abuse.
3. Re:Reasonable conclusion by Anonymous Coward · 2015-03-10 07:01 · 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.
4. Re:Reasonable conclusion by Anonymous Coward · 2015-03-10 09:13 · Score: 0
  
  It's not "Google's TSYNC" feature.
  Yes it is, the patches came from Google Chrome development team members.
  
  It was harmless, but better to not cause problems in the future.
  Harmless, eh? Then why is the Chrome application broken without it?
  
  he did so because he hates all things Google.
  How about that he hates buggy code, and he is the asshole that protects the LTS kernel from untested drops like this. Its awesome that Google is contributing source code, but do not fault LTS release maintainers when they slow things down. If Google wants their app supported in an LTS distro, then that means their app must continue to run on a kernel level that is still in use 5 years from now -- not running whatever bleeding edge drops that they successfully submitted in the most recent kernels.
At least they try to do their job by jones_supa · 2015-03-10 04:00 · 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 Anonymous Coward · 2015-03-10 04:04 · Score: 0
  
  Wait, Chrome's bug tracker is open source? Where do I find this code?
2. Re:At least they try to do their job by Anonymous Coward · 2015-03-10 04:16 · Score: 0
  
  ...at most I get template answers like "have you tried the latest upstream kernel if it solves the problem".
  You mean answers like this?
  
  #47 asargent@chromium.org
  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.
  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.
3. Re:At least they try to do their job by jones_supa · 2015-03-10 04:28 · 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.
4. Re:At least they try to do their job by Anonymous Coward · 2015-03-10 04:49 · Score: 0
  
  Oh please, that answer is typical of so many open source projects that its a cliche. What's worse in this case is that its the upstream developer recognizes that its a regression (there's no "technicality" about it, it worked once and now doesn't), but goes ahead and says "eh, just upgrade your kernel or fix it yourself. Whereas on launchpad, the vast majority of bug reports are filed against the distributions downstream packages of software, rather than against the upstream who actually has the power to fix the bug. But, when you go and file a bug against the software, what do the upstream developers usually say then? I'll tell you. 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. There's nothing unique about launchpad in this regard. You'll find the problems with any other distro's bug reporting.
5. Re:At least they try to do their job by jones_supa · 2015-03-10 05:39 · Score: 1
  
  Fair counterargument.
6. Re:At least they try to do their job by mangobrain · 2015-03-10 06:59 · 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.
Difficult? by Anonymous Coward · 2015-03-10 04:19 · Score: 0

Apparently it's not difficult. Please carefully choose words so confusion is avoided.
bitch by Anonymous Coward · 2015-03-10 05:20 · Score: -1

ot4er members in you can. When the
Not a hard requirement eh? No shit! by grandmofftarkin · 2015-03-10 07:14 · 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.
Re:For those who don't know what this TSYNC thing by Anonymous Coward · 2015-03-10 19:31 · Score: 0

I still don't understand. Sorry I only have a PhD !