Slashdot Mirror
Linus Torvalds Says Intel Needs To Admit It Has Issues With CPUs (itwire.com)
troublemaker_23 shares an article from ITWire:
Linux creator Linus Torvalds has had some harsh words for Intel in the course of a discussion about patches for two bugs that were found to affect most of the company's processors... Torvalds was clearly unimpressed by Intel's bid to play down the crisis through its media statements, saying: "I think somebody inside of Intel needs to really take a long hard look at their CPUs, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed... Or is Intel basically saying 'we are committed to selling you shit forever and ever, and never fixing anything'?" he asked. "Because if that's the case, maybe we should start looking towards the ARM64 people more."
Elsewhere Linus told ZDNet that "there's no one number" for the performance drop users will experience after patches. "It will depend on your hardware and on your load. I think 5 percent for a load with a noticeable kernel component (e.g. a database) is roughly in the right ballpark. But if you do micro-benchmarks that really try to stress it, you might see double-digit performance degradation. A number of loads will spend almost all their time in user space, and not see much of an impact at all."
Elsewhere Linus told ZDNet that "there's no one number" for the performance drop users will experience after patches. "It will depend on your hardware and on your load. I think 5 percent for a load with a noticeable kernel component (e.g. a database) is roughly in the right ballpark. But if you do micro-benchmarks that really try to stress it, you might see double-digit performance degradation. A number of loads will spend almost all their time in user space, and not see much of an impact at all."
Won't boot with a Xen hypervisor (eg. Amazon AWS)
The real "Libtards" are the Libertarians!
does it have speculative execution? if so, is it also vulnerable in similar way? Intel doesn't have monopoly, they have competitors in mobile, desktop and server spaces.
We clearly don't trust Intel ... why would we trust Chinese CPUs??
Or is Intel basically saying 'we are committed to selling you shit forever and ever, and never fixing anything'?" he asked. "Because if that's the case, maybe we should start looking towards the ARM64 people more."
Not sure how much Intel really cares about threats from the free Linux community - vs Microsoft, etc... To quote Rick Sanchez, "What -- What's this supposed to accomplish? We have infinite grand-kids. You're trying to use Disney bucks at a Caesar's Palace here."
It must have been something you assimilated. . . .
No thanks. We don't need any rice cookers with direct line to Xi Jinping.
His point is more likely the fact that ARM didn't do any sort of PR-bullshit and instead produced a very, very in-depth whitepaper, example-code and whatnot on the whole thing. Their behaviour here is pretty much everything one would hope for in a case like this.
80-90% of x86 CPUs.
80-90% is not a monopoly. If you don't like Intel, there are reasonable alternatives that will run 100% of your current software.
We clearly don't trust Intel ... why would we trust Chinese CPUs??
Who is more likely to put in a backdoor for the NSA? Intel or China?
Wrong, he works for the Linux Foundation, and has since IIRC 2013.
The kernel memory read issue was 90% a design decision to improve performance. I would argue that it should actually be an option in the BIOS. The fact the AMD didn't do this with zen to match Intel is what is really interesting. Intel did a little cheat to improve performance but AMD didn't and chose caution.
To me it's not a clear cut case if you brought a class action into court. The engineers cheated a bit but didn't think it would turn into such a security hole. I can just imagine the closing arguments... point is computers are complicated and not necessarily a guaranteed thing except that they can compute.
I don't think he craves attention; I think he's just a guy who speaks his mind, sometimes a little bit too much. With that said, I don't see why we need to publish so many of his brain dumps; there are many people with a way more valuable opinion on the subject, from a technical, legal or business perspective.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
So you decide to speculate a future instruction.
It happens to be a load.
The address is [ebp+eax]. A recent instruction had the same address field, so you speculate that it remained the same.
Now you need to translate the address. The translate might be in the TLB, but you check, and for some reason it isn't.
So you decide to speculatively trigger TLB load.
Finally, you get a physical address back. A previous write instruction is not yet translated, but it seems unlikely it will translate to the same address, so you decide to speculate the load and you make a cache line request from L1.
It might be in L1, but it isn't. So you decide to speculate again, and request it from L2. Not in L3, either, so finally you speculate the load all the way to external memory. When the cache line returns, you speculatively cache this at all levels. Then you speculatively store the value into the target register. The final step was the least dangerous, because you can dump this later, no harm to the abstract state. But the concrete side effects on the TLB and the three layers of cache are not so easily reversed. In theory, the concrete state doesn't leak into the abstract state. Because we simply don't like to think about time (time, above all things, being never simple; hint: functional programming has no time, only progress).
Not all speculative architectures are created equal. There are many opportunities for an architecture to Just Say No.
With cache coherence, you have the MESI protocol (and its bewildering shoe full of second cousins).
One could apply the same concept of "exclusive" to the page tables, an exclusively mapped page being one mapped only onto into the current process and security context. If TLB speculation hits a different kind of beast, abandon speculation. Same thing with cache fill. Concrete side effects thereby only accrue from speculation to exclusive resources. Share-nothing usually solves most problems in computer science (except performance, which is mainly defined in the time domain).
I'm gong to abandon the back of my envelope here, One has to think really damn hard to take this to the next logical level, and frankly, I don't have a damn to spare right this very minute.
But please, advance the conversation beyond:
[_] has speculation
[_] does not have speculation
Because that is Intel's diabolical trap, for as long as their PR department can continue to get away with tugging their wool in broad daylight.
Just bring back the Alpha chip. Whoops! Intel owns it. That sucks! Once again our technology is crippled by patents and copyrights. We could have a vastly superior chip right now. Oh well...
“He’s not deformed, he’s just drunk!”
Intel of course!
Zhaoxin will more likely do the same for Ministry of State Security or another spy agency in China.
They're both likely to have a backdoor for their own state.
It's not a pure monopoly, but it has a lot of monopoly power. Monopoly is not a binary state, as most lay pedants assume.
Were that I say, pancakes?
ARM (and AMD) may be susceptible to the lesser of the two [evil] exploits... but the impact for that second one is considerably less than Meltdown (which is specific to Intel only). ARM has been very open and detailed with regards to the impact -- and gives every indication it is taking the issue seriously.
... 250,000 all at one time.... is also optically bad. I understand the need to diversify your investments, but he should only be selling at most 25% of his shares on an annual basis.
Intel on the other hand issued a totally bizarre PR spin. Trying to spin it as works as designed (which might be the case, but the design was flawed), trying to distract the public by using 'Look over there...' deflection technique. Then indicating that the earliest architectural change will be later this year (which by the way coincides with the beginning of the next generation release). Processors for one generation of chips tends to be phased in over a two year period - does this mean that they plan to continue selling defective CPUs for the next 2 and a half years?
On top of that the news that the [probably legal] sale share (after the news of the defect, but before it was made public) -- is at least optically horrible. An ethical CEO would have delayed the planned share sale until after the defect was public - and accepted the risk of holding onto the shares during that time. Not to mention selling 889,700 shares and keeping only the absolute minimum to remain CEO
This all put together indicates to me that the current CEO should be fired.
How's that Transmeta business going?
Most CPU defects can be patched. This one cannot.
The lack of acceptance of responsibility, the attempt to deflect responsibility; the lack of transparency on when/how the defect will be fixed. That is why Linus was right to tear a strip off of Intel.
I agree Intel's spin is ridiculous, including trying to claim AMD's CPUs are just as vulnerable. But in typical, Linus hissy-fit fashion he pivots to tangential claims, like how Intel will "sell shit forever" and "never fix anything".
Chinese companies just put in backdoors for the Chinese government, organised crime, your Chinese competitors and so on.
https://thehackernews.com/2015...
http://www.zdnet.com/article/f...
http://www.securityweek.com/ap...
http://www.businessinsider.com...
https://tvnewswatch.blogspot.c...
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
The patents on the original MIPS architecture have run out by now. And MIPS was both very similar to Alpha and very elegant.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
well, the right thing for intel to do IS to recall all CPUs for users that request it. also to NOT downplay the huuuge security issue that they have caused, in their race for corner-cutting. maybe to publish some test results for the patches, maybe open some specs that might help the devs in better patching this issue in software, maybe even dump some cash for the devs. These are just from the top of my head, but you get the picture. The whole fiasco was very badly handled by Intel.
BS. There are already proof of concepts that can be run and are in the hands of a select few for testing purposes. We have no idea if these exploits have been used - only that we have no visibility on it. The only real visibility we have is when a whitehat reports it, or when someone is caught. While personal computers are less impacted, the fact that the browsers will all also have to be patched since it can also be exploited through javascript... problematic.
The issue is that through using the exploits you can have access to things like passwords used in kernel code, certificates, etc. -- and that can get this through pilfering the cache -- which breaks the isolation between user applications and the operating system.... While already bad on a personal computer, it is horribly bad for shared hosting environments -- where some actor can get access to a common computing environment and attack from the inside.
Actually, 83% is often used as a cutoff in both the US and Canada, derived from (US) judge Learned Hand's opinion that a market share of ninety percent 'is enough to constitute a monopoly; it is doubtful whether sixty . . . percent would be enough; and certainly thirty-three percent is not.' [ United States v. Aluminum Co. of Am., 148 F.2d 416, 424 (2d Cir. 1945)]
davecb@spamcop.net
And to be quite honest, that was not how I read Linus thing... Linus can be a wrap the contents of a valid issue in a bit of what some have termed a 'Hissy fit'/'tantrum'. The issue that he seems to have is not that there is a defect, not that it has to be patched in the kernel -- but that Intel's PR is on overdrive and gives no indication of taking responsibility... and not being open and transparent with regards to fixing it and timeline for those actions.
It is not the design / defect that I have lost respect for Intel, nor the technical competence of it's employees... My issue resides with the C-level's response to this defect that I have tot take issue with - and that is how I really read the email. ARM is not defect free, but the difference is that their response to it has been much more professional and transparent.
Being a software developer by trade, I am all to familiar that nothing is defect free... and defects are a part of the process.... the response and how these defects are handled is where you win or lose respect (assuming you are not totally incompetent and the software is not unusable).
The exploit is basically gathering information that could be used to completely invalidate security. Therefore by the time you know you have been compromised the vector that made the that possible would no longer need to be present.
Basically, by the time the world would have visibility - it would already be far too late (and it may be the case). We see the results, but not the attack vector... The odds of a whitehat finding any exploit first -- is probably much less than 50%.
It's too bad Asshole Torvalds isn't still employed by CPU maker Transmeta, so Linus can't tell his loyal following of Linux idiots to boycott Intel crap and buy Transmeta perfection instead. Transmeta CPUs were the bestest ever and that's why Transmeta went out of business, right.
The idea behind the Transmeta architecture may not have panned out, but I'm guessing that it had one redeeming feature compared to the current CPUs on the market: If their CPUs did have this problem, they probably could have fixed them with a firmware update.
> But in typical, Linus hissy-fit fashion he pivots to tangential claims, like how Intel will "sell shit forever" and "never fix anything".
Dude, you and I are seeing this NOW.
But some folks have been aware of that fact since some time, and no solution came up -- because this one is hard... hardware. The bubble just popped because Google decided enough is enough (not to mention this affects their business directly).
And what about the designers? What were they thinking? Don't they know about space separation? My guess is that is became hard to adhere to Moore's law curve and they had to cut some corners.
Linus is referring to the fact that such problems have not been not addressed nor fixed since years ago. He has worked with processors, he knows what he's saying -- he's not just a software guy.
I'd never use such colorful language as his, but this time it is totally justified -- not just because it's a serious problem, but because it seems Intel is totally blasé about it.
He has found/created a small pond
The world's most widely-used operating system kernel is hardly a "small pond".
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I got to thinking about Google's clever Retpoline from the other day.
Google Says CPU Patches Cause 'Negligible Impact On Performance' With New 'Retpoline' Technique
The problem is, this is not invariant under peephole optimization. These instruction sequences need to be handled by the compiler through a very literal minded end-game code generation pass.
Which got me to thinking about RETGUARD gadgets.
RETGUARD, the OpenBSD next level in exploit mitigation, is about to debut
Retguard: OpenBSD/Clang
I know, both of those sites are horrible, but Google fails me here.
Are speculative gadgets a problem here? If so, Google's clever patch is going to need a sump pump bolted on the side.
And then you get into the whole problem of deterministic compilation in order to be certain that the executable you build contains the necessary mitigations (or some tricky post-compile analysis I sure don't wish to develop myself).
What a giant mess.
While ARM CPUs are relatively ubiquitous in smartphones and tablets, those devices aren't nearly as high-value of a target as servers, where Intel CPUs dominate (well over 90% of the market).
Linus is in a unique position - he is an engineer, almost 100% focused on technical solutions, yet he is also a public facing figure and is able to make public comments. He also (to the best of my knowledge) doesn't have to worry about customers, profits, shareholders, etc., things that a for-profit, publicly-traded company does. Most of the time, the engineers aren't the ones making public comments. I haven't heard from any Intel engineers yet, only their PR department, but I would guess the Intel engineers are just as interested in fixing this as he is, but we aren't hearing about it.
Most likely to put backdoors into PLA are ColorFabb, Faberdashery or Proto-Pasta. But you'll have to download a 3D model of a backdoor first.
#DeleteFacebook
FPGA, Linus, FPGA!
#DeleteFacebook
They probably do think that. But I'm hoping that AMD will seize upon the opportunity to post real world comparative figures, with the newly patched kernels. Presumably, for certainly workloads, AMD silicon will utterly spank Intel for performance.
I have to ask... What's the state of play with the recently acquired Imagination now that Apple have stopped licensing their GPU and everyone else switched to Mali long ago?
I would have thought that Canyon Bridge might release a cheap MIPS board as a raspberry pi competitor.
The odds of a whitehat finding any exploit first -- is probably much less than 50%.
What is your rationale for this claim?
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
nvidia make their own ARM SoC; just sayin'.
Interesting, thanks. In return, I offer: the Herfindahl Index. A numerical indicator of how monopolistic an industry is, used in guidance by lawmakers in several jurisdictions.
CentOS's kernel-plus 7.4 boots fine under Xen 4.9 running with Fedora 27, all with the latest patches.
RHAT doesn't give a damn about Xen. Maybe they didn't break it intentionally on 7.4 but they didn't test it either. 'Cause nobody like Amazon uses Xen, right?
But buy their KVM product, it's much less prone to [their] breakage. Hah. Debian isn't hostile to Xen, nor is Arch.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Ask anyone involved - even whitehats - and you are likely to be told that the demand and renumeration for exploits on the open market is higher than it is for submitting it and expecting a bounty. You have state sponsors (some that are closer to mafia states) such as North Korea and Russia financing the finding of exploits. Your own government is also accumulating exploits - but the only time you see them used is when they are leaked - they are not typically submitted to companies - since they want to use them. You have major multinational criminal organizations that make significant amounts of their income through high tech attacks -- which can net billions in a single attack - making the cost of acquiring exploits a rounding error. You have thriving dark web marketplaces for selling these exploits. This industry dwarfs the whitehat industry considerably. Basically, there is more investment on monetizing exploits than there is discovering these exploits for ethical purposes.
MIPS was bought by Imagination Technologies who also own PowerVR (and, oddly enough Pure, a wonderfully geeky DAB radio company)
https://en.wikipedia.org/wiki/...
MIPS/Imagination is heading resolutely for embedded platforms and probably the plughole.
Still the original MIPS architecture is probably patent free. And Loongson make MIPS compatible chips. Unlicensed as far as I know. Not that there is much to licence in the original MIPS architecture
https://en.wikipedia.org/wiki/...
So it's possible for third parties to build MIPS compatible chips. Not MIPS32/MIPS64 but the original 64 bit MIPS III architecture.
https://en.wikipedia.org/wiki/...
Hell skip the patented bits and make them NOPs. Lexra got in trouble not for implementing them but for making them illegal instructions. MIPS's lawyers argued successfully that a system integrator could write an illegal instruction trap handler that implemented the missing instructions in software, in perhaps the most amazing abuse of the patent system ever.
https://en.wikipedia.org/wiki/...
In 1999 MIPS Technologies sued Lexra again, but this time for infringing its patents on unaligned loads and stores. Though Lexra's processor designs did not implement unaligned loads and stores, it was possible to emulate the functionality of unaligned loads and stores through a long series of other instructions. In the opinion of Lexra, the ability to emulate the function of unaligned loads and stores in software predated the grant of the patent in question and could not be viewed as an infringement of the hardware patent by any reasonable interpretation. Also, much earlier than any MIPS Technologies processor, IBM mainframes supported unaligned memory operations. In these earlier IBM processors, unaligned memory operations and partial access to registers were available through microcode and the instruction set architecture. These aspects of earlier IBM processors posed the much greater threat of patent invalidation to MIPS Technologies, compared to the seemingly vacuous MIPS Technologies infringement claim against Lexra.
http://probell.com/Lexra/
If a Lexra processor encountered an unaligned load or store instruction in a program then it did the same thing that it would do for any other invalid opcode, it took a reserved instruction exception. In the second lawsuit between MIPS Technologies and Lexra, filed November 1999, MIPS Technologies claimed that because exception handler software could be written to emulate the function of unaligned load and store hardware, using many other instructions, Lexra's processors infringed the patent. Upon learning of this broad interpretation of the patent, Lexra requested that the US Patent and Trademark office (USPTO) reexamine whether the patent was novel when granted. Almost every microprocessor ever designed can emulate the functionality of unaligned loads and stores in software. MIPS Technologies did not invent that. By any reasonable interpretation of the MIPS Technologies' patent, Lexra did not infringe. In mid-2001 Lexra received a preliminary ruling from the USPTO that key claims in the unaligned load and store patent were invalid because of prior art in an IBM CISC patent. However, MIPS Technologies appealed the USPTO ruling and, in the mean time, won a favorably broad interpretation of the language of the patent from a judge. That forced Lexra into a settlement that included dropping the reexamination request before MIPS Technologies might have lost its appeal.
It was never determined that processors that execute the MIPS-I instruction set, but treat unaligned loads and stores as reserved instructions, infringed the '976 patent. The patent exp
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
I am not aware of Linus hating Intel, he definitely hates the way Intel has tried to BS / Spin / deflect blame / avoid responsibility. If you appreciate companies that spend more time on BS / Spin / deflecting blame and avoiding responsibility rather than being transparent about their own failures and how THEY plan to address it... then Intel is the company for you (under this CEO anyways - we will see if he lasts).
ARM has been transparent, detailed and transparent about their failings (the lesser of the defects) and deserves respect for that.
I think that the bad kernel package has been withdrawn.
The real "Libtards" are the Libertarians!
https://en.wikipedia.org/wiki/...
Uh, Linux geek since 1999.
oops, transparent was duplicated
The Linux kernel development is transparent - you can go see every issue that is logged and needs to be fixed. next.
His quote: "Or is Intel basically saying 'we are committed to selling you shit forever and ever, and never fixing anything'?"
I think the record until now clearly shows that Intel's CPU products have actually been generally pretty good and that they actually do release fixes for their fuckups.
Let's put this into perspective: its a security hole not a major functional failure. People are having to get amazingly creative in finding new ways to break into anything. Basically anything even slightly complex has potential exploit risks, including Arm64 CPUs.
Linus needs to get real and give Intel a chance to do their thing.
No, Linus doesn't hate Intel. He hates dishonest people. And yeah, every article talks about "it" affecting AMD because the people writing them doesn't have a clue, and take Intel's words at face value.
And it's not "some of this". AMD is "affected" by spectre, if you can find a way to exploit it. The researchers couldn't. Meltdown is the real, immediate problem and that one is very, very much an Intel problem, despite what Intel would want you to believe.
Oh, it is even later than that - since that is the photo I setup facebook with almost a decade ago. It is the same photo until I die... though I don't feel threatened at all... since there are always two guards at the gate to protect me :o
Intel chip designer that can't even use capital letters properly? Checks out.
Meanwhile, enjoying my Ryzen, largely unaffected by Meltdown or Spectre in spite of some well meaning or self-serving FUD to the the contrary. Yes, I got an early part with the segfault bug, but AMD RMAed without fuss when presented with appropriate https://github.com/suaefar/ryz...>test data to eliminate the possibility of bad motherboard, memory or overclocking. Quite different attitude compared to Intel! And the Ryzen is sweet - 16 high performing CPU threads, tiny power consumption at idle and respectable under full load. Integer performance, iow, compiling is stellar and floating point is not shabby. Basically, Ryzen out-cores Intel's competing i7 parts by a wide margin, acquits itself well in single-core too and draws so little power that the CPU fan is off or barely turning for most normal desktop usage. And when all 16 threads are going full blast, iow doing real work, total system power is around 120 watts, the system still runs nearly silent. Can't say enough good things about it.
If you do step up to Ryzen, be aware of two things: 1) Check the production week stamped on the CPU, it has the form 17xx where xx is the week... make sure this is higher than week 25, otherwise run kill-ryzen.sh to verify the segfault bug and get an RMA promptly from AMD's only support site, if you see it. Windows users need to boot Linux to do this, get a live iso on a usb stick to do this in maximum comfort, and preferably, just overwrite Windows when done :-) Most of that early production is sold out already, so the chance of getting a bad part is slim, but be aware. Windows users for the most part don't seem to see any issue even with the early parts. Good for them, but it goes along with significantly lower performance without the upgrade to LInux :-) 2) Be aware that Ryzen has no on-board GPU, in spite of the fact that your Ryzen motherboard has video connectors... these are for AMD's APUs, which use the same socket. Respectable chips in their own right especially in terms of value for money, but when you run Ryzen you need to run a discrete GPU too. This is what you want anyway, because what is the point of crippling your high end desktop processor with a mickey mouse embedded GPU? To be specific: AMD's fattest APU has eight compute units (512 stream processors) vs 64 in the current Vega part, plus uses processor memory instead of higher bandwidth dedicated graphics memory.
Of course, what I really want is a threadripper... that's next.
When all you have is a hammer, every problem starts to look like a thumb.
He won the name game.
It's not a pure monopoly, but it has a lot of monopoly power. Monopoly is not a binary state, as most lay pedants assume.
There is no such legal concept as "pure monopoly". There is only anti-competitive behavior as defined in America by the Sherman, Clayton and FTC acts which includes such concepts as market power. There is endless confusion about this simple fact: a monopolist need not control 100% of a market to violate anti-trust laws. Usually much less than that, less than 50% is not at all uncommon. What matters is breaking the law or not.
When all you have is a hammer, every problem starts to look like a thumb.
Redhat's support is very selective these days. There is a clear imperative to more quickly support products that they can wrap a support contract around like RHEL. I understand that since they've got Wall Street to please, salaries to pay, etc., but it would not be a lot of extra effort to also support the free products in their ecosystem at a similar cadence. As a result, I have been weaning applications off Redhat products. The availability of support is great, but the vast majority of my applications don't require it so I've been leaning more towards the Debian ecosystem where my particular nits have been more quickly addressed and I don't feel like I'm going to be held hostage to ponying up for a support subscription to get a critical bug fix in a timely manner.
Perhaps. However if you're buying hardware from a company like HP they might not support a non-intel choice for the particular servers you want/need. Try getting one of their commodity DL360/380 servers with a non-Xeon part.
Personally, I welcome the addition of competition in the server market. Epyc looks like it will be a boon to folks who need more threads and more memory and who don't want to pay the huge Intel premiums for their highest core counts.
Actually, 83% is often used as a cutoff in both the US and Canada, derived from (US) judge Learned Hand's opinion...
Hand's opinion is certainly not the last word on the subject. From the horse's mouth: "Somebody has 40 percent of the market but everybody else has one percent each."); id. at 52 (Sidak) ("Would we infer that there is not a problem because the market share is only 40 percent and that is way below Judge Hand's ALCOA threshold or would we look at a price increase or loss of competitor market share and say that is a more direct set of facts that elucidates what the price elasticity of demand is?"
When all you have is a hammer, every problem starts to look like a thumb.
Just bring back the Alpha chip. Whoops! Intel owns it.
Not so, it came back as Ryzen.
When all you have is a hammer, every problem starts to look like a thumb.
And, to be honest, the larger world has no idea who the guy is nor to they pay any attention to what he has to say no matter how much attention he seeks. He has found/created a small pond, and careens around like a shark in a goldfish bowl. That's not particularly bad or at all unique, but certainly no one at Intel gives a crap what he thinks, and to expect any different shows a lack of perspective.
Guess what? Nobody give a shit what you think either. As the software he writes and manages runs most of the devices on the planet and is the world's most widely used OS, some of us actually care what he thinks. You, not so much...
"Those that start by burning books, will end by burning men."
This is not about Republicans versus Democrats, it is now about saving democracy.
When all you have is a hammer, every problem starts to look like a thumb.
The problem is that Linus doesn't quite have the maverick cachet that Gates, Jobs, or Musk do. Torvalds has equal or better technical chops but he divorced himself from "the rat race" for lack of a better term. Jobs was the rock star, filling stadiums with screaming fans. Torvalds is the street performer who plays a little better but didn't care enough about gratuitous adulation or "being #1" to make it to the stadium.
...Most of them anyway. I guess there's a few swayed by MS or Apple salesmen.
Some people see this and call him irrelevant. They feel that he shouldn't be allowed an opinion, or that it should be worth less, because he's not on the Forbes list. Thankfully, they take a more objective, impersonal assessment when it comes time to choose which OS to run on their servers.
what about the designers? What were they thinking? Don't they know about space separation?
You seem less than clear on the details. There is nothing wrong with Intel's privilege separation, however nobody anticipated that timing attacks could be so effective, even the researchers. It came down to luck more than anything: AMD, by luck more than anything, implemented algorithms that avoid the worst of it, but bad luck for Intel. Hard to fault the Intel engineers, but one can certainly fault the managers for a less than forthcoming response.
When all you have is a hammer, every problem starts to look like a thumb.
They probably do think that.
No they don't, they have plenty of competent kernel engineers on staff. Some PHB thinks that.
When all you have is a hammer, every problem starts to look like a thumb.
Intel has said they are working together with oem partners blah blah but i have yet to see their microcode patches posted on their website. I build my own machine, i can't contact Lenovo (who haven't even acknowledged most of their products are vulnerable)
Open Source Java Web Forum with LDAP authentication
Backdoor for domestic police state? That would be China. At least the USA has structural separation between businesses (like Intel), and the government. And is a country of laws.
Like all pain, suffering is a signal that something isn't right
In this case the CPU cannot be patched. This defect is permanent, it can never be fixed in the current processors. When new processors come out (assuming the next gen uses the same socket -- a crap shoot) you could replace the CPU. The fix is for the OSes to basically compensate and work around the defects - which may have moderate to severe performance penalties depending on CPU and what you are doing. What Intel is saying is actually a lie, they are helping the OS or "bios" vendors basically duct tape over the defect and hide it. Intel has indicated the earliest you will see "patched" CPUs is the end of the year - which depending on the CPU - could be end of the year or end of the follow year if they follow any type of release cycle (likely to be next gen CPUs only). So updating your motherboard to the latest firmware and installing the latest version of the OS is all that you can do for now.
>you heard me. he may be a great programmer, but he doesn't know DICK about how hard it is to make a CPU
Did you forget that Linus worked at Transmeta?
Russian CPU's?
https://thenextweb.com/insider...
""Ruselectronics also said that the chip contains features that “guarantees its users a high level of information security,” although it’s not immediately obvious what these are.""
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Arm A15, A57, A72 and A75 are all impacted by this as well.
It seems you're not clear on the details, actually.
Literally any logical person can see that Intel's suck-it-and-see approach is terrible. AMD's (and everyone else's) engineers specifically addressed the issue by using the correct logic. That's not luck. That's called doing it right.
Logical order of operations:
1) Begin speculative execution
2) Encounter ring-0 request
3) Check for ring-0 permission
4) Only allow speculative operation to be processed if permission is allowed
Literally everyone but Intel does it this way because they're smarter than Intel.
Intel's janky-ass order of operations:
1) Begin speculative execution
2) Encounter ring-0 request
3) Allow request to be processed, no matter what
4) When resolving branching, check if requester has ring-0 access and invalidate the results if not
The trouble comes with: 3.5) Unprivileged requester inspects artifacts (registers, cache values, etc.) of processing prior to speculative branch resolution.
The blame for this lays at the feet of Intel's engineers as much as anyone else. Granted, it's possible they found this a while ago and wanted to fix it, but were thwarted by management. Everybody knows that management sucks in every company, and they probably were the most recent roadblock to progress here. But this design got to production in the first place, and that's the engineers' fault.
> DL380
Yes, you cannot order a DL 380 with an aMD chip. You will have to settle for an HP DL 385 instead. Almost like it has a different part number as a result of having a different CPU, motherboard, Virtualization model, and instruction set support.
1 If the patch is in software, in the OS, can't malicious code (e.g. after privilege escalation exploit) undo any OS patch and then go wild on other people's memory? Basically yes, but you have to have another OS based exploit to piggyback on -- but in reality the privilege escalation by itself would probably be sufficient in itself - so the chip level one would more or less be overkill. 2 Does this also bypass Intel SGX isolation? I don't think you would say bypass, but it would likely impact the security of SGX as well -- since your leaking kernel data into user spaces.
The air in your room is constantly computing, the electrons in all matter
on earth are constantly computing.
The point with processors like Intel's is that it is easier to control
the computation with standard, widely available methods (software). This bug inhibits this control. Which was their only point to begin with, as compared to "computation" devices like air.
Bingo Dictionary - Pragmatist, n. A myopic idealist.
If it's so obvious then why did it take nearly two decades for anyone to notice?
I like this comment "Don't these kernel updates get any testing? I realize that CentOS may have very limited resources for testing, but doesn't Red Hat test these updates?".
What? Maybe it compiled just fine!
Slashdot, fix the reply notifications... You won't get away with it...
We clearly don't trust Intel ... why would we trust Chinese CPUs??
Because you trust already many stuff made in China. Have you a smartphone?
Slashdot, fix the reply notifications... You won't get away with it...
Since this news broke, I've been sitting on one question that bothers me, and I can't figure out the answer:
How much would this kind of global, hard-to-find, not-so-hard-to-exploit-once-you-know-what-to-look-for issue been worth to an interested party in 1995?
Assorted stuff I do sometimes: Lemuria.org
So if I am big bad hacker, how do I use this vulnerability? Through a tedious process (carefully arranging for page faults and cache misses in speculatively executed code), I can determine bit by bit the value of other processes memory (which the OS and hardware should not allow); but I don't get a snap shot of the complete state of memory. Instead I get a peak at the value of the memory I should not have access to, word by word, memory which is changing as I am looking at it. How useful is this? Just figuring out what other process is running on the machine with you is tough, but can be done using this process. Of course by then, the other process has exited or been moved. Maybe worth doing if you know there is a program running with very sensitive data on the machine you are using; but why are they letting you on their machine in the first place? To prevent this difficult-to-use security leak, we can and should take the performance hit and disable this optimization on shared machines (such as in the cloud) where strangers programs are running on the same machine. But for privately owned machine running time-critical code, I would expect we'd recognize there is no risk here and continue using the fastest machines, with this security-risking vulnerability in place, along with its speed boost. I can imagine the cloud users would demand that the vendors supply them machines where the cpu is not shared with un-trusted players; and in the meantime Intel will come out with new chips that close this vulnerability; and before that Linux and Microsoft and Apple et al will deploy patches that mitigate the problem.
ARM (and AMD) may be susceptible to the lesser of the two [evil] exploits... but the impact for that second one is considerably less than Meltdown (which is specific to Intel only).
That's incorrect. Per Apple's statement, all of Apple's ARM designs except the watch are vulnerable to meltdown. Also, the Cortex-A75 is vulnerable to meltdown. I agree that the initial PR spin from Intel was pretty ridiculous, but the good news is it looks like some engineers at Intel released a actual technical response. Reading through the whitepaper, it looks like Intel has figured out how to patch both meltdown and spectre on existing chips using a combination of microcode updates and OS updates.
We clearly don't trust Intel ... why would we trust Chinese CPUs??
Who is more likely to put in a backdoor for the NSA? Intel or China?
Yes.
Not really. Everyone is allowed their opinion. And if he speaks out about OS design, coding standards, or even processor architecture, I’d listen, since he knows a fair bit about those subjects. If he voices an opinion on how to manage a FOSS community, I’d still listen even though I don’t agree with his management style, because he ostensibly has experience on that front either. But if he tells others how to run their business or how to handle PR or legal matters, then yeah, he is largely irrelevant. Because he didn’t join the rat race, and those things lie outside his area of expertise.
His opinions on those matters might still be interesting and insightful, but they don’t really have any more weight than those of the rest of us.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Excellent capsule summary of the issue, by the way. But you still can't blame the engineers... at the time, this kind of timing attack was not a thing. Nobody had a crystal ball, nobody saw it. Maybe you did, and you just forgot to send the memo.
When all you have is a hammer, every problem starts to look like a thumb.
I think that Meltdown is more architectural and OS problem than just Intel's flaw. CPUs have always been designed to be as fast as possible. If you want fast - you might have to sacrifice the security. If you need secirity - do things right and slow.
How could a recall even be possible at this time? To me a recall implies that it is possible to repair the fault, which is clearly not possible now and for some time to come. As for the other things that you mention, they take time. Nothing happens instantaneously.
Yes, and if they recall the cpus, what will you do with the motherboard and the other periphery?
Linux runs/ran on MIPS too.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
I guess they will have to add journaling to the CPU cache levels.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
It's hard to imagine any objective observer not already having enough evidence at hand to know that America is currently under the control of a criminal gang of thugs.
Now that is certainly true; as it has been true every year since the 1950s, and probably long before.
I am sure that there are many other solipsists out there.
And another publicly known fact is that there are a bunch Russians slimeballs with skin in the game, going so low as to troll-mod community sites like Slashdot. Understand this Ivan: you just provide more evidence every time you do it.
Can you cite the slightest piece of concrete evidence for this lurid fantasy?
I am sure that there are many other solipsists out there.
It's a monopoly. Intel found this out as well when they tried to move to the Itanium. It's a better chip with a better future. However managers wouldn't buy it because it wasn't the X86. Even though Windows would run on it. Same thing with the digital equipment corp Alpha processors. Way better, however penetrating the market was nearly impossible. I'd bring it up and managers wouldn't even consider it.
Sort of like Standard Oil 100+ years ago. If you bought anything other than standard oil your house could burn down. A lot of people thought that because it happened. Many people wouldn't even think about buying anyone else's kerosene.
The deal with Centos has always been that it gets the same support that RHEL gets, but later.
It is a pretty good deal, actually. They don't hold fixes back, but don't expect their engineers to be doing overtime and getting called in on the weekend to massage a free patch. That's exactly what support subscriptions are for!
Centos will get all the fixes, and they will work well. History teaches this clearly.
Thanks!
davecb@spamcop.net
No, there is quite a balancing process to be done by the courts, but the context of the comment was to address a claim that 80-90% was not a monopoly. In fact, it could easily be, depending on the size and market penetration of others in the market.
davecb@spamcop.net
You might have misunderstood what you're citing, as being a monopoly is totally legal in the US and so Judges aren't generally ruling on that. There is probably a different thing, worded differently, that the ruling involved. Specifically, they were accused of being a type of monopoly that violates section 2 of the Sherman Act.
First of all, rulings have context. The context of United States v. Alcoa that you cite was the aluminum market. It isn't presumed to be a one-size-fits-all answer. Certainly for businesses similar to aluminum manufacture, those types of numbers are considered relevant. Specifically, they found that Alcoa would substantially increase their own production capacity in anticipation of competition, and that they did so successfully in a way that prevented competitors from becoming established. The large capital investment required in the aluminum industry is very important to this.
Compare that to Intel's situation, where they compete very hard but companies like ARM who don't own a single factory can not only compete, but dominate some niches. They're not going to measure Intel based on whatever accusation you make, Intel will respond pointing to the whole computer processor market, and the Court will have to accept some portion of that definition. Who the customer is, or if the product goes in your pocket or on your desk, those are not real differences that the court will take seriously as being separate markets. It isn't enough to show that there is a monopoly, you have to show a monopoly that harms competition. If competition requires a giant factory, then 90% market share is going to get you there for obvious reasons, but if no giant factory is required, and an office with a handful of engineers can actually design a new product and sell it just fine, then 90% would be meaningless.
Like with Microsoft; having lots of market share wasn't the problem, competitors who failed to get access to that market due to behavior by Microsoft, in the context of microsoft's market share, was the problem. Compare that to Google's market share in their market; Google doesn't do anything to keep people out, their market partners aren't encouraged to sign lock-in agreements or anything. A company partnering with Google this year might partner with Bing next year, and they don't get punished in the market for that. So it doesn't matter how high Google's market share goes.
Another thing the courts look at is if a monopoly is a natural monopoly or not. If it is natural, then they don't care. If you had to do things to create it, then they do care. If you're the only person who has Magic Foo Rocks on your land, because they only come from one place, and you therefore have 100% of the Magic Foo Rock market, you have a natural monopoly and it is totally legal. Lack of competition isn't something you did, it flows naturally from the nature of your business. Whereas if you go out and buy up all the Magic Foo Rock mines, and now own them all, then that is not a natural monopoly but a created one. A more common natural monopoly is utility delivery, where it is impractical to have multiple sets of water pipes going to homes, and the investment in new pipes only makes sense when there is a lack of existing pipes. In that sort of case, a monopoly is totally legal and doesn't harm competition. Note, however, that if prices are too high you can still have problems because it is illegal for monopolies to harm competition, or customers. The remedy for high prices would likely only be partial refunds, though, not substantial changes to business practices.
Also, "80-90% of x86 CPUs" is like saying, "McDonalds has a monopoly on restaurants named McDonalds." Sure, it sounds good, but whatever "monopoly" means there, it doesn't mean any of the things talked about in the Sherman Act. Their market would include not only all the x86 CPUs, but also all the alternatives like ARM and MIPS. While it may be true that AMD's market share isn't enough to prevent Intel from being a monopoly, ARM's market share is easily enough to make it a joke. You'll be sitting there in a courtroom where most of the people in the room have an ARM CPU in their pocket, after all. Some lawyer will likely point that out.
That's very long and informative, but regrettably off-topic. I was actually replying to a chap who appeared to think that you needed to have 100% of a market to be a monopoly.
davecb@spamcop.net
You either didn't read Apple's statement before linking it, or you didn't understand it.
What it actually says is that Apple's ARM designs are all vulnerable to [Meltdown or Spectre]. So you got the most important part muddled.
And another publicly known fact is that there are a bunch Russians slimeballs with skin in the game, going so low as to troll-mod community sites like Slashdot. Understand this Ivan: you just provide more evidence every time you do it.
Can you cite the slightest piece of concrete evidence for this lurid fantasy?
Why don't you just go ahead and cite your concrete evidence that Russian slimeballs are not slithering around this site, Igor.
When all you have is a hammer, every problem starts to look like a thumb.
Nice description. Now tell me how knowing the _addresses_ in L[123] cache is any kind of exploitable breech? No-one is talking _data_, and the 'sploit described (history dumped) is pure userspace, most likely a cleverly crafted URL like file:///C\:Users\ .
If you're as worried as Theo, just turn off RDTSC (seccomp) as MS did long ago (Win98?), likely to disable a less-than-favorable benchmark.
Right, but it wasn't off-topic. I didn't mean to imply that all my comments were uniquely tailored as a narrow response to you. You brought up Alcoa but cited it in a weird way for this context, and didn't explain why it would be relevant. The short answer is just that it isn't relevant, but bare conclusions have less value than explanations. I really don't care if the guy you were replying to was even more wrong. Lots of slashdot readers don't remember the details and haven't read any explanations since the MS antitrust trial, and it has been a couple years now.
If I saved one neckbeard from blathering on about how Intel is going to get in trouble and making a fool of himself, it is a successful public service for the listeners spared. :)
"It's a better chip with a better future."
When Itanium showed up the prime factors against using it weren't "It's not x86"
They were that it was far more expensive than the x86, ran slower for most workloads, generated a LOT more heat and were primarily targetted as server CPUs (no desktop/laptop CPUs) - meaning you had to run multiple architectures across your fleet, which most managers don't like doing.
If you want to sell a new architecture, then making it hard/expensive for developers to actually have test systems, etc is not a good way to go about it.
Intel discovered very quickly that they couldn't leverage their near-monopoly on x86 supply into market dominance in another processor type based on the manufacturer name alone. Even IBM stopped being able to sell simply on the strength of their name decades ago.
Sounds to me that you're not that familiar with the Alpha. Here is the DEC Alpha Multia - http://www.computinghistory.or... . They would run Windows NT, also Linux which is what I used them for. That's a desktop, made to be a desktop and used as a desktop. It even had the sound card. It was a really nice neat little box.
I used to buy these. I had no trouble buying them for less than the slower intel desktops at the time. The Intel boxes were not just a bit slower, they were clearly a lot slower. Annoyingly a lot slower.
I have a lot of experience with the alpha, from the Multia up to big mainframes. That multia even when you could buy them as surplus machines would still beat the current Intel boxes. We did extensive testing on it. It wasn't until around 2000 that Intel finally caught up enough that I was willing to part with the multia. When processors were moving towards the 1ghz range. The frames we kept around until 2013. Not that they were faster, they weren't for years, however moving off was tough.
"at the time, this kind of timing attack was not a thing."
It's a classic race condition.
Any time there's a possibility of a race condition, sooner or later it will bite you in the ass. The only way to win is to ensure there's never a race to be won.
"The right thing for intel to do IS to recall all CPUs for users that request it."
Are you kidding?
This is the same Intel who released Atom chips which _will_ drop dead at ~2 years of runtime and will only exchange them if they do so within the warranty period.
It's a classic race condition.
Not it isn't, it's a statistical timing thing.
When all you have is a hammer, every problem starts to look like a thumb.
I'm very familiar with the Alpha thanks - and still have a couple of ancient DS20s that are on life support.
Itanium was no Alpha.
| Not it isn't, it's a statistical timing thing.
What do you think a race condition is?
Backdoor for domestic police state? That would be China. At least the USA has structural separation between businesses (like Intel), and the government. And is a country of laws.
Do you mean like the separation between the NSA and RSA, Inc.?
Please stay far away from any code I care about.
When all you have is a hammer, every problem starts to look like a thumb.
Ubuntu has fixed kernels in testing now for 14.04. I don't see any final release date slated. They're not currently available via the standard package trees. You need to add a PPA to get the testing version. Ubuntu SecurityTeam Spectre and Meltdown
IANAL, but I don't think "natural monopoly" matters here. It is illegal to leverage a monopoly in one area to get an unfair advantage in another. Certain forms of anticompetitive behavior are illegal, monopoly or not. It's legal to have a monopoly, but your actions will be followed much more attentively.
Also, the x86 market includes almost all of the laptop, desktop, and server markets, and those are distinct from the tablet and phone markets (almost all ARM). An ARM tablet won't run a large amount of software that can be business-critical, for example, so it's not an acceptable substitute.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Okay, so why isn't this a race condition, and what IS the difference between a race condition and a statistical timing condition?
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Linux has a problem with OS's.
My concern is that since AMD CPUs are (nearly completely) immune from these issues, will software patch/band-aids for these issues also affect software on AMD platforms?
Self-importance and self-indulgence is the root of ALL evil.
Then you should know. Did you buy the machines? Well Never mind I suppose. I always have been known to get a great deal. I always thought they were competitively priced for what was out there at the time. It's a DEC, just like HP, IBM, they put good parts in them. I never did have one go bad.
The Itanium had a lot of the Alpha technology in it believe it or not. DEC was bought by Compaq that was bought by HP and HP teamed up with Intel on the Itanium. I met a lot of those guys that did the work in NY State someplace. I'm friends with a super HP fan. He and I still have a HP3000/III nameplate. I was thinking this new processor will be it. HP Superdome.... to replace the PA chips... Should Rock. It'll get adopted into data centers.... Didn't. Face plant into the pavement.
Sooner or later we'll get away from the X86.... I keep thinking that. Maybe before I retire? I used to wonder why the MC88000 didn't take off and rule the world.
The timing thing is about a side channel. Race conditions are not about side channels, they are about lack of essential synchronization.
When all you have is a hammer, every problem starts to look like a thumb.
It predates me. This is running VMS for support of ancient spacecraft software. We had a farm of DS10s and DS20s at one point. The only reason it survives is that keeping it is cheaper than moving to a VMS emulation environment.
I know the history of the Itanium. Sat, watched and waited for it. x86 is a mess and needed replacement even then.
(Hell, we would have bought more alphas if we could, but x86 won the war on both the bang-per-buck front and being the default for the original PC. This isn't so much VHS beating Beta as a souped up, revved out audio cassette format beating Beta.)
Was bitterly disappointed when it showed up with stupidly high pricing, high power consumption and relatively poor performance figures that precluded us buying any, quite apart from the inability to actually get any in Europe for quite a while.
In the meantime AMD released x86-64 CPUs which solved the 4GB barrier, then Intel bowed to pressure and crosslicensed them.
X86 Prices stayed low, relative performance kept climbing and Itanium effectively fell further and further behind, being repositioned from the idea of a general 64-bit server CPU to a high end one, then into niche spots like the Nonstops.
Itanium could have taken the market if Intel had been willing to sell it at a loss for a while. Yes there was resistance from the x86 desktop crowd but what ultimately sank it was the poor bang-per-buck it provided. Intel's marketing always seemed to lack conviction and once they crosslicensed x86-64, the writing was on the wall.
It's not as if it's the only Intel CPU that tanked over the years. The x86 is their moneymaker and what they've always come back to, despite its instruction set being a pile of fetid dingo kidneys. The sad truth is that they've never tried particularly hard to replace it because to do so would damage existing sales, even when they had better architectures to offer.
Itanic sank on the x86-64 iceberg.
OMG, hell... You just brought back a flood of memories. A bunch from 35+ years ago. VMS, probably fortran. I was thinking Tru-64. I used to know vms 3.8-4.0. We moved all of our stat stuff up to Linux. Not hard going from Fortran to something like C or perl. Not hard for me at least. They have a descent Fortran compiler for Linux now. I think Microfocus' might work for you if you're interested. Maybe it's too risky to move to something else? I have a feeling it's very risky to continue to run it under VMS. The pool of people that even know what VMS is has to be small and shrinking. Good luck! I hope you find something that works and isn't so expensive.
Ok, so you're talking about the later boxes. Hell yes, you're right. The later ones they wanted a kidney and a date with your wife expensive. We couldn't support it either and moved on. In our case everything worked out and our refrigerator size Alphas went to GSA surplus.
You're allowed to have advantages, and it doesn't have to be fair.
What you can't do is harm competition, or harm the customers. If you don't raise prices, you can do a lot to maintain market advantages.
"I was thinking Tru-64"
We turned those ones off about a decade ago.... :)