TSYNC Not a Hard Requirement For Google Chrome After All 46
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.
What's the story? (Score:2)
Google Chrome had a bug, it was reported, and it'll be fixed.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
The real story is that Slashdot is actually admitting it was wrong.
Re: (Score:2)
That kind of reflexive paranoia isn't exactly news, though, if you've been on Slashdot as long as your userid implies.
Re: (Score:2)
True, true.
Re: (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.
Re: (Score:1)
Re:What's the story? (Score:4, 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.
Re: (Score:1)
what is tsync? (Score:4, Interesting)
Re: (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
Re: (Score:1)
It's a thread synchronisation instruction available on certain processors.
For those who don't know what this TSYNC thing is (Score:5, Informative)
The linux seccomp [wikipedia.org] 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) [man7.org] 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.
CNN all over again (Score:2)
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.. (Score:4, Funny)
...it won't require NSYNC.
Re: (Score:1)
Re: (Score:2)
...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?! (Score:2)
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.
Re: (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'
Re: (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
At least they try to do their job (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
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
Not a hard requirement eh? No shit! (Score:2)
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.