Slashdot Mirror
Google Chrome Requires TSYNC Support Under Linux
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 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?
I thought T'Sync was Spock's aunt.
Would have been nice if TFS had included an explanation of what the TSYNC feature is.
Not that I was going to use a system that kowtows to RMS by calling itself GNU/Linux anyway, but the OS is there to support the software I use, and I use Chrome on Linux. If the OS won't support it, then I won't use it.
So, you tell us you are not going to use a system that you weren't going to use.
And we should give a fuck, why?
Watch this Heartland Institute video
Debian 8 was a lost cause long before this nonsense. It will be the first "stable" version of Debian to include systemd. Systemd was forced upon Debian users thanks to some dirty politics, and has generally been unwanted by most of the Debian community. It already caused numerous problems for those running the unstable and testing versions of Debian, including systems that would no longer boot. The fact that systemd is still under very heavily development additionally means that it has no place in a stable Linux distro release, especially a Debian stable release. Many Debian users, especially those running servers, have realized that they need to discard Debian in order to maintain the stability of their systems. We've seen lots of these people move to the BSDs, in fact. All of that aside, Debian 8 is shaping up to be one of the most disappointing Debian releases ever, if not the worst, and it's all thanks to the bad decision to include systemd.
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?
In Soviet Washington the swamp drains you.
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).
So,
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.
Because it's yet another reason not to use them.
Disinfect the GNU General Public Virus!
LTS as a practice, is against Google's best interest - Google is attempting to leverage Chrome to turn all software into insecure, auto-update, phone home garbage - just like all other web applications. They don't want to use the workaround, they want you to update.
It's a detail of how sandboxing works on Linux. Other OSes have theirmown sandbox mechanisms. Microsoft cares about Windows having the necessary features because they use a sandbox in IE. The Linux sandbox mechanism that Chrome/Chromium uses appears to be an API at least partially developed by Google. TSYNC is a feature Google recently added to the sandboxing API in Linux because they intended to use it in Chrome.
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.
To each his own.
However, for folks who want their OS to actually pay attention to their needs, it's yet another nail in Debian's coffin.
Disinfect the GNU General Public Virus!
Ubuntu already appears to have a seccomp-tsync backport to 3.16.x: https://lists.ubuntu.com/archi....
Chrome is by definition, spyware.
It does everything in its power to relay information about your activities back to Google, right down to what you click and when, if you allow it.
Most of these 'features' require you to opt-in, but some just happen right out of the box.
If you don't realize that the entire existence of Chrome and Chromium is to get information about you, you're an idiot with your head in the sand.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
You know what? I'm not paranoid about Google. They don't care about me individually, and I opt out of their ad targeting. The rest I just don't care about.
You're can't be paranoid about google, paranoia is thinking that someone's watching you, with Google, they boldly state they're watching you and in your case you're aware of that. I personally do care what Google knows and have taken steps to limit that significantly, by using as little of their services as possible and making tracking me much more difficult. A random Jane or John at Google shouldn't be able to tell you you're on your period this week, for instance.
The cesspool just got a check and balance.
Sounds like Firefox may get a bump in NetStat numbers, however small, and Chrome will drop. I still don't get why anyone would use that phone home spyware, but over 40% of the market can't be wrong, can it? Think about the windows users!
The cesspool just got a check and balance.
I don't know what the fuck TSYNC is, but I'm confident that the BSDs, OS X, and Windows probably don't offer it, especially if only recent Linux kernel versions support it.
So how the flying fuck can Chrome run on these other systems that don't offer this functionality? What in shit's name is preventing those workarounds from being used on these older Linux systems?
Shorter AC: I have no fucking idea what this is all about, but it fucking enrages me! Raaaugh!
If I understood the bug report correctly this only affects users that uses extensions.
"TSYNC is a new sandboxing flag for seccomp that was recently added to the Linux kernel." -- from the description of the change to Chromium
Sounds like more browsers should be using it.
Disinfect the GNU General Public Virus!
The issue not google chrome, but SystemD bloatfest
Not referring to chrome issue, rather that giant greasy dump by Poettering into the open source pool known as SystemD
No, not at all. In this case, though, it's not going in because of the animosity of one developer to all things Google. He didn't even bother to see what the change was about before shooting it down in flames.
The OS people are quite often right. Not this time, though.
Disinfect the GNU General Public Virus!
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 chrome.richardlloyd.org.uk -- he figured out how to make it work, and it works well.)
there are 3 kinds of people:
* those who can count
* those who can't
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.
It must have been something you assimilated. . . .
Here is the kernel commit message:
seccomp: implement SECCOMP_FILTER_FLAG_TSYNC
Applying restrictive seccomp filter programs to large or diverse
codebases often requires handling threads which may be started early in
the process lifetime (e.g., by code that is linked in). While it is
possible to apply permissive programs prior to process start up, it is
difficult to further restrict the kernel ABI to those threads after that
point.
This change adds a new seccomp syscall flag to SECCOMP_SET_MODE_FILTER for
synchronizing thread group seccomp filters at filter installation time.
When calling seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, ...) has been set on the calling thread, no_new_privs will be set for
filter) an attempt will be made to synchronize all threads in current's
threadgroup to its new seccomp filter program. This is possible iff all
threads are using a filter that is an ancestor to the filter current is
attempting to synchronize to. NULL filters (where the task is running as
SECCOMP_MODE_NONE) are also treated as ancestors allowing threads to be
transitioned into SECCOMP_MODE_FILTER. If prctrl(PR_SET_NO_NEW_PRIVS,
all synchronized threads too. On success, 0 is returned. On failure,
the pid of one of the failing threads will be returned and no filters
will have been applied.
The race conditions against another thread are:
- requesting TSYNC (already handled by sighand lock)
- performing a clone (already handled by sighand lock)
- changing its filter (already handled by sighand lock)
- calling exec (handled by cred_guard_mutex)
The clone case is assisted by the fact that new threads will have their
seccomp state duplicated from their parent before appearing on the tasklist.
Holding cred_guard_mutex means that seccomp filters cannot be assigned
while in the middle of another thread's exec (potentially bypassing
no_new_privs or similar). The call to de_thread() may kill threads waiting
for the mutex.
Changes across threads to the filter pointer includes a barrier.
https://git.kernel.org/cgit/li...
New things are always on the horizon
It means it makes Chrome more secure.
This sort of thing is why Debian is so often seen as a realm of knee jerk lunatics. Debian isn't keeping up with features Chrome needs to be more resistant to browser exploits (which are used to install ACTUAL spyware) and the answer is "Chrome gathers statistics on how it's used so it's evil and we don't care if it breaks". WTF?
I even try Konqueror before I resort to Chromium.
I do not fail; I succeed at finding out what does not work.
That's your prerogative, but keep in mind you're throwing a tantrum over a issue that does not affect the server market. No one in their right mind install a GUI on a Linux server, so again, not a issue for the server market.
Well, I can appreciate the reasons for this argument, but I also routinely do the opposite: I have many servers installed on my own "workstation" machines, which of course came with GUIs.
Of course, by "server" you were presumably referring to hardware, while for many of us software types, a "servers" is a piece of software that can run wherever we're able to compile it. So technically, we don't install GUIs on our servers; we install GUIs and other servers on our machines. They're really independent chunks of software, and they can easily cohabit on a single machine these days.
One basic reasoning behind all this, of course, is for testing purposes. After all, no one in their right mind installs untested web software on a client-facing server (machine). We install it on our workstations, where we have all the software (including browsers that require a GUI) to do thorough testing, and we test the hell out of it before inflicting it on unsuspecting Web visitors.
(Actually, who am I kidding? I install small edits on "live" web servers all the time. This is rarely a problem, it turns out. But YMMV. I did this numerous times in the past week, because the server admins - in their wisdom - were installing upgrades on the server without first testing them on hidden machines. You wouldn't believe all the web site's stuff that this broke. I found it better to actively watch the web stuff that I was responsible for, and when it broke, try some quick fixes - or apologetic top-of-page messages - for the duration. And I'm still on good terms with those admins, who appreciated my occasional emails about what was currently broken. ;-)
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Chromium is the opensource chrome, that's it. It does not have spyware and not the nasty habit of chrome to mess with your package manager to update by itself (i mean, really WTF?)
This needs some serious modding up. ... as a lead developer who was instrumental in moving us from debian (which until the last year or two, I had been evangelizing and supporting for almost a decade) to FreeBSD for over 10,000 servers (two entire clusters) and hundreds of workstations (test/dev machines of developers/scientists/etc).
We're starting to see similar things from our peers as well, debian/centos/rhel/ubuntu being dropped pretty rapidly within our circle of influence - they don't listen to users/customers (really bad RHEL wise, when you're paying them hundreds of thousands of dollars), they fail on security (something debian was once great at), and they're moving linux into a direction that's frankly - undesirable for serious servers, HPC, etc.
Debian is dead, stop giving it attention, we've all moved on - so should the conversations.
Ah looks like Ubuntu fixed it, things change I guess :-)
Perhaps I read it after you did, but *one* maintainer said he wouldn't support it, and called it spyware. (I don't know whether it is or not.) Another said that if it turns out to be needed and someone submits a "quality patch" then he would submit it. (He also said that if Chromium needed it, he would revert the patch that made it a requirement, but that Chrome was a binary that he [and implicitly Debian] had no control over.)
I think we've pushed this "anyone can grow up to be president" thing too far.
Moved on to....
I think we've pushed this "anyone can grow up to be president" thing too far.
Moved on to....
I wish I could mod you up. I was curious about the same thing. So many people saying they've moved on from Debian but never ever saying which distro they moved to.
I seriously question any one who would complain about this. They really must not understand how Debian releases work. Debian Jessie is frozen, which means there is a stringent process to go through in order to add changes, we have known it was going to be frozen for months and months. Their testing releases always go through a freeze period before it moves into stable. Stable means that typically the only changes are security fixes. Expecting Debian, a distro which really doesn't like non open source software anyway, to unfreeze for something like Chrome is just an odd request. If you need bleeding edge, you should move to a bleeding edge distro, I can recommend Arch as being fantastic for bleeding edge, there are plenty of others as well. Stable/LTS releases are not ever bleeding edge. In fact, stable/LTS releases are usually significantly behind. Or even better, they can go back to Windows. Wouldn't even notice if they left.
That doesn't make sense. TSYNC is a security-enhancing feature.
Chrome uses seccomp-bpf for Sandboxing.... that is isolating certain threads from the system.
TSYNC facilitates software correctness with regards to the security. Without TSYNC, there is a greater likelihood of problems in the application leading to system compromise.
So I'm quite satisfied by Google's choice to refuse to run their browser on kernels that don't support current security features.
Firefox, Konqueror, Midori, Epihani, Opera, Arora, etc, should do the same.
Of course, they will have to implement multi-threaded Sandboxing functionality first.
I'm instead amazed by Google's arrogance in stating that RHEL 6 is "too old" for Google Chrome. It's been that way since at least last summer, so my RHEL teaching cluster and workstations just don't have chrome installed.
Actually, that's not quite true - one user manged to get Chrome working, but it regularly consumes all system resources and crashes the PC. Result.
All in all, I'm happy to do without Chrome on RHEL 6. Will I try to get it working when I roll out RHEL 7 this summer? Possibly, but moves like this make me wonder if Google's a company whose products I want to install at all. Firefox ESR may have its faults, but it basically works, and I can trust it'll stay working.
Oh arse
Does it, though? I've seen loads of claims of this behaviour, but usually it's just some muppet complaining about malware protection or getting confused about something.
Chrome's entire existence is to provide a good experience using Google's websites, some which people pay for (and so are not "the product", as the trite saying goes), and some which are ad supported.
You might want to slow down on the idiot-calling - you might end up being called one yourself.
There's a number of ways it phones home, some of which at least can be mitigated: spell check, url suggestions, and default search from the address bar which is my personal pet peeve, what was so hard about hitting the TAB key to go to the search field from the address field so I can control what I search for?
However, ask yourself this, what reason did Google have for making a better independent browser than Firefox, which was at 30+% market share at the time and used Google as it's default search engine? It wasn't altruism, so there must have been a driving reason for it.
The cesspool just got a check and balance.