Comment That's Easy, Jomo! (Score 1) 255
Keep all of the idiots that want to work for a millionare for nothing. Fire the others.
Anyone with sense has by now joined a non-profit project.
Keep all of the idiots that want to work for a millionare for nothing. Fire the others.
Anyone with sense has by now joined a non-profit project.
Compare-and-exchange and mfence would be doing cache flush all of the way to RAM and global cache line invalidation, wouldn't they? So, they can potentially be used to hammer too.
Multi-threaded programs really do need those cache flushes to implement their interprocessor communications, don't they? It seems to me that they would be the ones most likely to hit this problem.
It has yet to be established whether hammer techniques can result in a correct data+ECC pattern. If so, it should be possible to permute the memory in a way that defeats this, either on the memory module or the memory controller.
That would make a good research paper for someone.
Yes, you beat me to it. A correctly-configured ECC motherboard with real ECC memory would defeat this. Watch out for fake ECC memory that just simulates the correction bits.
Once memory starts being vulnerable to row interference, having a machine without ECC becomes much more dangerous, regardless of this exploit.
I understand the idea, yes. But:
1. Most of the time, it doesn't work. Let's face it, at least 95% of the people looking to buy a laptop don't understand this issue. A good amount of people doesn't care about spying either, because they think they have anything to hide, or because the US government is doing it so it must be good, or because the US government doing it makes it impossible to avoid anyway, or for a myriad other reasons. I think Lenovo would have to be in a very weak state for this to do them under.
2. If it worked, it wouldn't be a good thing anyway. The laptop business is a very expensive to enter and competitive one. If people ran a company out of business every time it displeased them enough, despite trying to rectify their mistake, nobody would want to enter the market. Who would want to risk their money in such a way? So the market would eventually stabilize with 2 or 3 remaining companies which are too big to bankrupt, or who people won't boycott because there's too much inertia and not enough alternatives.
If the market settled for instance on Dell and Apple, boycotting one would require rebuilding your entire infrastructure and way of doing things. This won't happen, so if such a situation is reached they can basically do whatever they want.
If we want a consumer friendly environment we need plenty of competition, and this means that bankrupting a company should be the absolute last resort.
That's a counterproductive way of doing things.
Whenever making that kind of statement towards any sort of business you're telling them that there's no point to try to correct whatever upset you, as all resources spent to that end are going to be in vain anyway.
The spyware gives them some money. If all people who hate it put Lenovo in their blacklist forever, then the most sensible business decision is keeping the spyware. The customers that hate it won't come back, and the ones that remain don't care, so nothing is gained by removing it after losing that part of the customer base.
Right, so here is seems how things are:
1. Google seems to have little regard for long term backwards compatibility, at least on the timeframes Debian wants it. Kernel 3.17 came out in October 2014. Fedora has a new enough kernel, but also doesn't have Chromium officially apparently because Google likes to clone various libraries and do API changes, rather than trying to work with the original developers, distributions, etc. So it seems Google mostly does its own thing and lets other people to deal with it.
2. So Google is now releasing browsers that require kernel 3.17 to work properly. Users want to run it on their systems.
3. But Jessie is frozen and so changes only happen for good reasons. The question is then whether to backport the TSYNC feature. On one hand, it's a new feature and it doesn't go in frozen releases, on the other hand it stops new versions of Chrome from running, which is a security concern. Ubuntu seems to have went with the later logic.
4. Ben's reaction is "1. I don't like Chrome, so no", and "2. Distro is in freeze, there needs to be a formal proposal explaining exactly what patch to merge, and a sympathetic maintainer, which I am not".
So really what's going on is a conflict between organizations. Google wants to move faster than Debian does, and Debian (or at least Ben) doesn't want to give Google special concessions.
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: http://lwn.net/Articles/347547...
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.
You have the Part 15 and ISM services for that. You really can buy a microwave link that's metropolitan-distance and legal to use.
We lost much of our 440 capability to PAVE PAWS in California. Remember, Amateur Radio is not the primary service on many bands. The military is on 440.
If you want that nearly infinite microwave spectrum, you have the Part 15 and ISM services. Absolutely nothing is stopping you. Power is not the issue with those frequencies, it's line of sight and Fresnel zones.
No, I absolutely do not have to prefix my words with anything. You do that by posting as an anonymous coward. I use my real name to indicate that I stand behind my words.
Yes. The usual mechanism here would be WiFi security, with HTTPS or SSL inside of it.
OK, no real technical data and some absurd claims here.
First all-digital transceiver? No. There have been others. Especially if you allow them to have a DAC and an ADC and no other components in the analog domain, but even without that, there are lots of IoT-class radios with direct-to-digital detectors and digital outputs directly to the antenna. You might have one in your car remote (mine is two-way).
And they have to use patented algorithms? Everybody else can get along with well-known technology old enough that any applicable patents are long expired.
It would be nicer if there was some information about what they are actually doing. If they really have patented it, there's no reason to hold back.
What do you mean by tech fetichism? Tech places a huge priority on energy efficiency. Computing is going increasingly mobile, lighting is shifting to LED... all of which is high tech by the way. Do you think old incandescents are better?
From Sharp minds come... pointed heads. -- Bryan Sparrowhawk