Linus Torvalds Says Intel Needs To Admit It Has Issues With CPUs (itwire.com) 271
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."
Red Hat screws up their implementaition of the fix (Score:4, Interesting)
Won't boot with a Xen hypervisor (eg. Amazon AWS) [centos.org]
Re: (Score:3)
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.
Re: (Score:2)
I think that the bad kernel package has been withdrawn.
Re: (Score:3)
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
Re: (Score:2)
What? Maybe it compiled just fine!
That'll show 'em (Score:2)
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."
Re: (Score:3)
Not sure how much Intel really cares about threats from the free Linux community - vs Microsoft, etc...
Do they care about selling CPUs? Do they care about the competition who clearly has the advantage now? If they do they better get their shit together and stop pissing off the IT guys that will make or break them.
Re: (Score:3)
What advantage are you talking about and what competitor? Do you mean AMD? I'm sure you do and yes you would be correct they have a slight advantage now but the funny thing is I don't see them running to exploit it. An advantage is nothing if you don't exploit it and that is just what I'm seeing AMD not do.
Re: (Score:2)
Threats from who?
[Intel] was the largest corporate sponsor of new contributions to the Linux computer operating system, according to a report Wednesday morning from the Linux Foundation [oregonlive.com]
Intel is a big part of that community.
They were the top corporate contributor in 2015 and 2016. Before that they were second to Redhat. Before that they were third to Redhat and Novell.
Re:That'll show 'em (Score:5, Insightful)
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...
Out of touch much? Intel now derives a large and expanding portion of its revenue from Linux servers, versus the shrinking Wintel market. Intel cares every much about its image in the Linux community, it is very easy to drive devs away to ARM and AMD. Intel has done a respectable job of keeping that brain drain under control and anything else would just be suicidal.
Re: (Score:3)
Out of touch much? Intel now derives a large and expanding portion of its revenue from Linux servers, versus the shrinking Wintel market
From what I've been seeing over the last 10 years this observation matches what I've been seeing. Not just with intel but with server sales from Dell and IBM too.
Back in 2008 I priced out 150 dell 2950 for a datacenter. The price automatically included a windows license for each server. It it took me 2 weeks to pound it through some thick skulls that we didn't want or going to pay the microsoft tax.
I priced out a few dozen Dell servers a few years back. When I ordered them with Linux on them nobod
Re: (Score:3)
This was said over and over on slashdot: not everyone has your use-case.
Ya, I get that. But I'll note that I'm a system programmer and system administrator and have administered Windows, Unix and Linux on just about everything from PCs to Crays over my 30+ years, so I have a lot of varied use-cases under my belt. I have Intel and AMD systems at home running a mix of Windows, Linux, BSD and vSphere - with a mix on that.
linux dominates the server market. it's installed on all the world's supercomputers. if these have a 5% performance hit because of the intel meltdown bug, you bet your ass it's a big deal (as in very expensive). also all enterprises run linux on servers to a degree.
Sure and many of those system use Intel processors. Sure, they could switch to other architectures or they could just add 5% more Intel CPUs. Perhaps Intel coul
I actually do think the issue is minor (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
the Intel bug does not look like an intentional design decision to me, more like an oversight. the performance win speculating over security domain page boundaries can not be that large, I would guess it should be 1% loss. ...
IMHO someone just did not really think all the details and consequences of this boundary case thru,
Re: (Score:2)
It doesn't matter if Intel intended to open up a security hole or not. The tort system in the U.S. is one of strict liability. If something goes wrong with your product, and you didn't explicitly say NOT to do that, then you're on the hook. It doesn't matter what your intentions were, only the result.
Re: (Score:2)
Your subject line is idiotic. There is nothing minor about millions of computers having authentication secrets exposed.
everything computes (Score:2)
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.
Re: (Score:3)
AMD got lucky with their design decisions, if it was a conscious decision they'd have exposed Intel's flaw themselves.
You're acting like it's possible to make a decision of this magnitude unconsciously. AMD consciously chose to do things the correct way, whether or not they knew what Intel was doing. That they didn't expose Intel's flaw suggests that they in fact did not know that Intel was playing fast and loose there. I'd argue that if they did know what Intel was doing and chose not to do the same, that would be even more laudable, but I am perfectly happy that they chose to do things correctly no matter the reason. It
Re: (Score:2)
Older AMD processors still leaked information between protection domains through the BTB, was that a conscious decision? BTBs have been leaking information into scripting language sandboxes for everyone, they were conscious of that and didn't bother telling anyone nor provide a way to fix it?
I'm sure a lot of people have been sitting on these exploits for a long long time, but I hope AMD designers were not among them. I'd rather have them be blind to it than massive assholes.
Re: (Score:2)
I'm sure a lot of people have been sitting on these exploits for a long long time, but I hope AMD designers were not among them. I'd rather have them be blind to it than massive assholes.
Like I said, I share the belief that their failure to share the information probably means that they in fact did not know. Why wouldn't they have shared this information with us, when they come out looking like geniuses, or at least responsible?
the many forks of speculation (Score:5, Informative)
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 [wikipedia.org] (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.
off-topic quickie (Score:2)
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 [slashdot.org]
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 [reddit.com]
Retguard: OpenBSD/Clang [ycombinator.com]
I know, both
Re: (Score:2)
Are speculative gadgets a problem here? If so, Google's clever patch is going to need a sump pump bolted on the side.
Sure, speculative gadgets are a problem... which is why the Retpoline solution has to be applied to every binary in the system. And it has to be implemented in the code generation back-end. The back-end has to scan for potential gadgets and retpoline them.
And then you get into the whole problem of deterministic compilation [wikipedia.org] 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).
That's an easy problem for Google and, I expect, other big cloud systems. Google builds everything itself, including compilers. If you're big enough and have the engineering resources, that makes sense for lots of other reasons anyway.
For everyone else,
FDIV redeux (Score:3)
https://en.wikipedia.org/wiki/... [wikipedia.org]
Linus being a drama queen again (Score:2)
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 p
Ryzen my friends (Score:4, Informative)
Meanwhile, enjoying my Ryzen, largely unaffected by Meltdown or Spectre [reddit.com] 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... [github.com]>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.
Re: (Score:2)
Agree about the power consumption, that is why I am holding out for the 12nm refresh. Then, there are rumors about 32 core threadrippers, that would hold me for quite some time I think. Also, starting to see 10 Gig ethernet on the threadripper motherboards, that is something to lust after.
where are the patches? (Score:2)
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)
CPU cannot be patched (Score:2)
Re: (Score:2)
Issues (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
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.
Re:Zhaoxin (Score:5, Informative)
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.
Re:Zhaoxin (Score:5, Informative)
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 [wikipedia.org] 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.
Re:Zhaoxin (Score:5, Informative)
Re: Zhaoxin (Score:5, Funny)
He won the name game.
Re: (Score:2)
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?" [justice.gov]
Re: (Score:3)
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 busi
Re: (Score:2)
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.
Re:Zhaoxin (Score:4, Insightful)
Re: (Score:3)
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?
Re:Zhaoxin (Score:5, Informative)
Chinese companies just put in backdoors for the Chinese government, organised crime, your Chinese competitors and so on.
https://thehackernews.com/2015... [thehackernews.com]
http://www.zdnet.com/article/f... [zdnet.com]
http://www.securityweek.com/ap... [securityweek.com]
http://www.businessinsider.com... [businessinsider.com]
https://tvnewswatch.blogspot.c... [blogspot.co.uk]
Re:Zhaoxin (Score:4, Funny)
Re: (Score:2)
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.
Re:Zhaoxin (Score:4, Funny)
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.
Re: (Score:2)
Russian CPU's?
https://thenextweb.com/insider... [thenextweb.com]
""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.""
Re: (Score:2)
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?
Re: (Score:2)
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...
Re:Zhaoxin (Score:4, Insightful)
The patents on the original MIPS architecture have run out by now. And MIPS was both very similar to Alpha and very elegant.
Re: (Score:2)
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.
Re:Zhaoxin (Score:5, Informative)
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/... [wikipedia.org]
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/... [wikipedia.org]
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/... [wikipedia.org]
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/... [wikipedia.org]
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/ [probell.com]
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
Re: (Score:2)
Linux runs/ran on MIPS too.
Re: (Score:2)
Just bring back the Alpha chip. Whoops! Intel owns it.
Not so, it came back as Ryzen. [wikipedia.org]
Comment removed (Score:5, Informative)
ARM has a lot less to lose (Score:5, Insightful)
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.
Re:ARM has a lot less to lose (Score:5, Insightful)
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
You've succinctly explained why Intel is in the troubles they are.
Re: (Score:3, Insightful)
Re: (Score:2)
He has found/created a small pond
The world's most widely-used operating system kernel is hardly a "small pond".
Re: (Score:2)
Some people see this and call him irrelevant. They feel that he shouldn't be allowed an
Re: (Score:2)
Re: (Score:2)
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...
Don't like Linus; Agree with Linus; CEO s/b fired. (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:2, Insightful)
> 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 separati
Re: (Score:2)
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.
Re: (Score:2, Informative)
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
Re: (Score:2)
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.
Re: (Score:2)
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 [apple.com], all of Apple's ARM designs except the watch are vulnerable to meltdown. Also, the Cortex-A75 [arm.com] 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. [intel.com] 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.
Re: (Score:2)
Not about zero defects... (Score:2)
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.
Re: (Score:2)
Most CPU defects can be patched. This one cannot.
According to Intel anyway who, if they did patch it, would own the responsibility for any more problems and/or bricked CPUs resulting from that. Since it affects almost every CPU they've made in the last 20 years, better for them to punt with "fixed in the next release".
Re: Linus love attention more than money (Score:2, Insightful)
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.
Re: (Score:2)
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?
BS - It is serious. (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:2)
on Linux anyway, things like authentication and certificates are handled by other apps, some of which may access syscalls of course, but to repeat - as SO many do - that passwords are part of kernel code is nonsense.
You are the one who does not understand. Every bit of memory on your computer goes through the kernel. As witness that far more clueful people than you regard these issues as deadly serious.
How would you know; when you know - it's too late (Score:2)
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%.
Re: (Score:2)
The odds of a whitehat finding any exploit first -- is probably much less than 50%.
What is your rationale for this claim?
Economics (Score:3)
Re:Economics (Score:4, Interesting)
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.
I work with a lot of such people, and their response is that remuneration on the dark side is iffy and dangerous, and there's the constant threat of getting caught and prosecuted. Their opinion is that -- excluding spook operations -- the black hat side is small and relatively untalented.
I guess maybe it depends how you classify the government-funded stuff. Personally, I don't consider it either white or black, but somewhere in between. And I don't think it attracts the best, though perhaps quantity counts as much as quality. There was a time when the NSA attracted the best, but that was before Snowden.
Re: (Score:2)
Re:BS - It is serious. (Score:4, Interesting)
No known exploits in the wild yet.
How many unknown exploits in the wild?
Oh, right, we don't know. If we did, they wouldn't be unknown.
No issue with Intel and design. (Score:4, Insightful)
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).
Re: kinda naive (Score:2)
Re:kinda naive (Score:5, Informative)
>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?
Re: (Score:2)
Arm A15, A57, A72 and A75 are all impacted by this as well.
Re: (Score:2)
I guess they will have to add journaling to the CPU cache levels.
Re: (Score:2)
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.
Re: (Score:2)
FPGA, Linus, FPGA!
Re: (Score:2)
This is not about Republicans versus Democrats, it is now about saving democracy.
Re: (Score:2)
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.
Re: (Score:2)
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?
Re: (Score:2)
Re: (Score:2)
They probably do think that.
No they don't, they have plenty of competent kernel engineers on staff. Some PHB thinks that.
Re: (Score:2)
nvidia make their own ARM SoC; just sayin'.
Linus is reasonable angry at Intel's response (Score:3)
ARM has been transparent, detailed and transparent about their failings (the lesser of th
professional, detailed and transparent (Score:2)
Linux is transparent and open (Score:2)
Re: (Score:2)