Nope, No Intel Chip Recall After Spectre and Meltdown, CEO Says (cnet.com) 372
Hoping the Meltdown and Spectre security problems might mean Intel would be buying you a shiny new computer after a chip recall? Sorry, that's not on the cards. From a report: Intel famously paid hundreds of millions of dollars to recall its Pentium processors after the 1994 discovery of the "FDIV bug" that revealed rare but real calculation errors. But Intel CEO Brian Krzanich said the new problems are much more easily fixed -- and indeed are already well on their way to being fixed, at least in the case of Intel-powered PCs and servers. "This is very very different from FDIV," Krzanich said, criticizing media coverage of Meltdown and Spectre as overblown. "This is not an issue that is not fixable... we're seeing now the first iterations of patches." On Thursday, Intel said it was aiming to fix 90 percent of all Intel products that have been introduced within the past year by end of next week. CNET asked if the company was looking at older Intel processors? From the report: "We're working with [computer makers] to determine which ones to prioritize based on what they see as systems in the field," an executive at the company said. Intel also is fixing the problem in future chips, starting with products that will arrive later this year. Intel is effectively taking the software fixes being released now and building them directly into hardware, he said.
It isn't his decision (Score:5, Insightful)
Re: (Score:2)
As the AC correctly points out bugs are to be expected and are known to exist. Just read the amount of "will not fix" erratas published by Intel and realize that most erratas that will get fixed will be in later revisions (steppings) and not in currently available chips. The things that do get fixed in released systems are things microcode or feature control hardware can touch.
This isn't unique to Intel of course.
Re: (Score:3)
Re: (Score:3, Interesting)
Once the lawsuits come rolling in he won't have a choice. This isn't fixable. The best you can do is mitigate the damage.
It turns out that these new methods of attack affect AMD x86 CPUs, and ARM non-x86 CPUs as well,
so it's a multi-platform weakness that the only hardware safe against are essentially iPad and iPhone.
Someone may TRY to sue Intel over this, but I suspect they will not be successful, since this
isn't defective hardware per se, but hardware that doesn't resist a new kind o
Re:It isn't his decision (Score:5, Insightful)
Re: (Score:2, Informative)
WRONG. The Meltdown attack ONLY AFFECTS INTEL
False; Non-Intel platforms are affected by the same form of problems. The security issue related to Processor Speculation has been Acknowledged by ARM [arm.com],
and furthermore, even the Meltdown paper [meltdownattack.com] points out the same issues existing with at least several example attacks working reliably on the ARM and AMD platforms regarding out-of-order executions And instructions past illegal memory accesses.
Re:It isn't his decision (Score:5, Informative)
Re: (Score:2)
Citation please
Re:It isn't his decision (Score:5, Informative)
https://spectreattack.com/ [spectreattack.com]
Which systems are affected by Meltdown?
Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors.
Really, are you that ill-informed?
Re:It isn't his decision (Score:5, Informative)
FROM THE PEOPLE WHO ACTUALLY FOUND THE FLAW:
The GP's "Citation please" was referring to the fact that "MELTDOWN is INTEL ONLY." AFAICT. Which it is. From Section 6.4 of the Meltdown paper:
We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD.
In summary:
* Meltdown: Intel-only
* Specture: everyone
Re:It isn't his decision (Score:4, Informative)
That is not contradictory information; it is just out of date. "Currently [as of the time the paper was written], we have only verified Meltdown on Intel processors.
The information cited does NOT support your claim that Meltdown is Intel Only; nor were the authors even claiming they believed Meltdown to be Intel-Only --- the authors showed information to indicate AMD/ARM would also be vulnerable, but they were primarily interested at the time in demonstrating the exploit on Intel processors and made minimal at best efforts to fully demonstrate and exposit the problem on ARM/AMD despite showing these affected.
Current security bulletins include more up-to-date information than the Authors' whitepaper.
Re: (Score:3)
Why quote some 3rd party FAQ rather than the original paper which is linked to in your citation?:
The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.
Re: (Score:3, Informative)
No. ARM has confirmed that Meltdown (i.e., Variant 3 and 3a) also affects some of their processors.
https://developer.arm.com/supp... [arm.com]
Please stop lying. You are a despicable liar.
Re: (Score:2)
Spectre vs Meltdown, you are picking nits: (Score:4, Informative)
mysidia said "Non-Intel platforms are affected by the same form of problems" (emphasis mine). This doesn't seem like a lie: Understanding Meltdown & Spectre: What To Know About New Exploits That Affect Virtually All CPUs [anandtech.com]
I'm not a CPU architect, and perhaps you are, which would explain why you seem to take the differentiation of these bugs and exploits so seriously. Or perhaps you are paid by AMD or an ARM vendor.
Or maybe it's that your statement: "the world revolves around me" [slashdot.org] suggests that there might be other issues behind your comments [wikipedia.org]
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Intel new about this defect in June. In the seven months since then, it's sold hundreds of millions of CPU it knew were defective, but chose not to disclose that fact. "Caveat Emptor" is not a defense to fraud.
Re: (Score:3)
Re: (Score:2)
Re: (Score:3, Funny)
Just like all the Equifax execs rotting in jail now...
Re: (Score:2)
It's arguable that the product isn't "defective." It's operating properly and as designed... It just happens that the design has a serious but unintended consequence.
If someone uses a screwdriver to pry open a lock we don't say the screwdriver and/or lock is "defective." Inadequate maybe, but not defective.
=Smidge=
Re: (Score:3)
Re: (Score:2, Interesting)
No it isn't. One of the key features of the processor was memory access management. This is a HUGE bug.
It's a bit subtle. The architectural requirements of the memory access management are entirely being met. The values in every register (etc) are exactly what they should be according to the ISA, The bugs work by causing a change to what data is cached, based on memory values they cannot actually access and then measuring load times for the data to see what is in the cache. There is, I suspect nothing in the ISA specification which says that this shouldn't happen.
It also seems that there are genuine software
Re: (Score:3, Insightful)
Re: Lawsuits on what grounds? (Score:4, Insightful)
It's Hillary "Correct the Record" levels of horseshit.
Re:Lawsuits on what grounds? (Score:5, Informative)
This design error contains at least three features worthy of "www.wtf.com":
That is the three no-nos we know about. There must be at least one more we don't know being held back because it is even worse.
Whoever designed this stuff MUST have known it would behave like that, same way the Volkswagen engineers knew what was going on. Someone signed the designs into production. Presumably the first time round it was "let's chance it" and subsequently "well, we got away with it last time".
I am guessing quite a few people knew about some of it - like people debugging the compilers for example.
If you want to know why NDAs should not be permitted this is it! Use an Open Source architecture if you want accountability.
Re:Lawsuits on what grounds? (Score:5, Insightful)
I'm guessing you don't work on this stuff do you...
I never worked on the CPUs (I was chipsets), but I certainly have plenty of experience with unintended effects.
* That it trains on other data is a non issue.
* That it allows privileged access as part of a prediction is a mild (at best) issue.
* That it doesn't have a prediction fail recovery mechanism (e.g. zero the cache for the failed prediction) is a minor issue.
HOWEVER
When these component issues combine together it is a *huge* flaw.
How can this happen?
* designers are idiots?
-no, if they were idiots they certainly wouldn't have a working part at all. This stuff is _complex_
* different smart designers worked on different parts, but in isolation?
-ding! winner. It is highly likely that there was more than one team involved and as a result each validated their block works, and they validated that the system works. No one person saw the *whole* picture and as a result this vulnerability exists.
Now, once a designed block is done, the industry standard is to leave it the fsck alone! So this block of VHDL likely was re-used and tweaked for process changes, but never actually fully re-factored, so no one ever saw the big picture at all.
That is how bugs like this come to be.
If you want to beat people up about it, it's not the engineers that should be beaten, it is management that keeps the engineers under such schedule pressure that there is *never* a window to review and refactor something unless it's flatly broken. Beat up senior management for how they're handling this whole thing...
But leave the guys in the trenches out of it. I guarantee you they were doing their best.
Re:Lawsuits on what grounds? (Score:5, Insightful)
Well your guess is partly right. I am retired now. However, I did work designing CPUs, and I was specifically employed to debug pipelining snafus, so yes, I do know something about the subject. (I did not work for Intel).
The "training on other threads' data" is not in itself a very serious security issue, but it is certainly an information leak between threads, and would probably be acceptable if the data leaked was the value of a random byte, as it might have been 20 years ago.
The problem here is serious because this situation allows deliberate (mis-)training of performance in the other guy's thread! - That is not what is being complained about in Meltdown or Spectre and is not necessarily a security risk, but it is not good news if some-one else's C library calls can screw the performance of my thread. Meltdown specifically describes shared C libraries as a source of predictable data to screw with.
In the present situation, where the CPU speculatively executes hundreds of instructions at a time, it gives a massive surface of attack which simply should not be there.
I give you "designers working in isolation" is going to lead to trouble, as is too much focus on schedule, but re-using vhdl blocks you don't understand counts as idiot behaviour in my books - although re-using blocks you know are "a bit iffy" is possibly worse: people must have known that kernel memory could be accessed speculatively. I would not have knowingly bought a processor that allowed that for cloud type uses. There is a risk of billion dollar law suits involved.
As I have said elsewhere, I would expect reading the pipeline contents for speculative execution that is abandoned to be restricted to (a) kernel mode, AND (b) only when in a debug mode. There simply should not be a way for user mode threads to see this data at all in normal operation - it is only needed to debug the speculative execution engine. I would not expect the data to be able to leave the CPU in normal operation. In fact, I would expect to need jtag to read it. The car analogy is driving your van away with the back doors open. Sure, the parcels might not fall out! (Just because its still your thread does not mean you want an information leak: this is the browser risk).
Re:Lawsuits on what grounds? (Score:5, Interesting)
I read more, and it's actually a timing attack combined with a cache read.
So...
A little more problematic than I initially indicated because the cache does flush, but they're snagging it sooner. Linus has the right answer: Disable speculation when going into kernel/protected memory space. https://lkml.org/lkml/2018/1/3/797 [lkml.org]
As to the block reuse issue, it's simply impossible for the system level design engineer to fully understand all those blocks, just like the the block level designers can't understand the entire system(s) that their block is used in. Intel's model is a library of known good blocks, system level designers then integrate these together.
The issue is that all this is working "as designed" and there is a fundamental design issue (easy fix by Linus noted above). That this issue made it into a VHDL block that was vetted is *the* issue, but that this block was then re-used is expected. Since it never actually broke it never was refactored.
I don't see a solution to the "teams in isolation" problem either. The CPUs and support circuitry (like chipset) are simply too damn complex for a human brain to hold an entire model of in any level of detail capable of being useful in a design context. In chipset I only had three areas that I focused on, there were many many others, some I had better awareness of than others. My blocks I knew inside and out, I knew how to tickle them, break them, etc. Blocks I interacted with I knew their internal block diagram, but not the low level functionality, and blocks orthogonal to my focus area really were just "block Foo connects to Bar and Baz, and I connect to Baz". So I need to understand Baz, but I'd just have to trust that the Baz - Foo interface was done correct.
Re: (Score:3)
The CPUs and support circuitry (like chipset) are simply too damn complex for a human brain to hold an entire model of in any level of detail capable of being useful in a design context.
I respectfully disagree.
It is possible, but Intel is not likely to pay someone properly who can do that when what they "want" are really just easily replaceable assembly line engineers. To management, there is no reason to fully understand, it just needs to work.
I get nausea and vertigo when I see large, fairly complex things that are vital but that nobody seems to have a full grasp of the whole system.
Re: (Score:2)
The "scheduled sale" is a lie. No CEO dumps ALL of his stock.
If they schedule the sale in advance and provide the required notice to shareholders, then they are legally able to sell as much stock as they want. If the CEO anticipates a drop or sees turmoil or sees themselves being fired or retiring, they may very well dump all their stock and get more back later through executive stock compensation.
Re:Lawsuits on what grounds? (Score:5, Insightful)
Re: (Score:3)
This is a thousand times worse than the FDIV or f00f bugs.
Not sure if it's strictly worse. At least you can do useful work on an airgapped machine. With the FDIV bug, not even a well-secured machine is useful in numerical computing scenarios. Unless you want to patch your compiler to emit a slower (on the average) routine for divisions, that is.
Re: (Score:2)
The "scheduled sale" is a lie. No CEO dumps ALL of his stock.
Sounds like you know a lot about "No CEOs". Good we got that sorted.
The reality is that MOST CEOs dump their stock as soon as they can. The exception being those that started their own companies and still believe in endless growth potential. The vast majority of the CEOs in the world sit at the top of bluechip companies whose stocks are better liquidated and invested elsewhere.
But then if it's a lie then it's a clear case of insider trading, and just like those other clear cases of insider trading that you
Re: (Score:2)
"In all the years I've been at this and of all the companies I've covered, I can't recall another single massive sale on this scale," Stacy Rasgon, an Intel analyst at Sanford Bernstein.
Re: (Score:2)
Re: (Score:3)
I'd say he dumped all of his shares. The remaining shares are tied to the CEO position, which he currently fills. Those shares aren't his until he leaves the position or the legal requirement to sit on them and do nothing with them is removed.
Re:Lawsuits on what grounds? (Score:5, Interesting)
You keep saying that, I don't think it's true. (Score:4, Informative)
It doesn't matter if the original bug is in the HW or not, so long as there is a workaround at some layer (firmware, kernel, etc.). You are beyond naive if you think this is the first time a HW bug has been masked by SW--it happens all the time. Usually the workaround is buried in a driver or firmware and you never hear about it.
Re: (Score:3)
You constantly use the word mitigate as if a patched workaround making the exploit unusable on the OS level isn't every bit the same thing as a hardware fix making the exploit unusable.
And with first benchmarks out of the patched windows machines showing the performance impact for most normal loads lies somewhere between sweet and fuckall [techspot.com] this really is every bit as overblown as many people are stating.
Software has provided additional layers of protection over hardware since the DOS days. What makes this "m
Re: (Score:2)
Have you read a description of the hardware defects? It is exactly like it is insecure by bungling ineptitude and corner cutting
If they advertised these defects, no one would have bought a single chip from them, ever.
Its like selling buckets with hole in and saying "its OK if you carry them real fast".
Re: (Score:3)
If you sell something that is fundamentally broken, you must issue a refund or a working, equivalent replacement.
If you knowingly sell something that is fundamentally broken, that's fraud.
No, sorry, that's not fraud at the levels of political donations that Intel makes.
At those levels of political donations it then becomes "...an unfortunate design error for which Intel has already negotiated a full settlement with the government's lawyers that prevents any other parties filing civil actions against Intel, unfortunately, a gag clause in the settlement prevents details from being released."
What, don't tell me you thought the US still operated based on the Rule of Law!?
Strat
Re: (Score:2)
Re: (Score:2)
Same syndrome as VW (Score:4, Interesting)
The underlying pattern is exactly the same as the VW scandal. A manufacturer tries to deliver the promised performance, and in order to do so fakes out an emissions test (VW) or builds in a highly insecure procedure (Intel).
At an even simpler level, it is just the battle between quality and quantity. VW and Intel cheated "a little" to provide the promised performance. We can expect a very great deal more of this.
Re:Same syndrome as VW (Score:5, Interesting)
Intel will no doubt copy the big banks by claiming that it is "too big to fail". It would argue that it can't afford to replace all the defective chips, and so it shouldn't be forced to.
The US government regards Intel as a huge asset - just like Microsoft, Oracle, IBM, Google, Facebook, Twitter, etc. - and will certainly take the company's side if it faces a serious threat to its existence.
Re: (Score:2)
Re: (Score:2)
The underlying pattern is exactly the same as the VW scandal. A manufacturer tries to deliver the promised performance, and in order to do so fakes out an emissions test (VW) or builds in a highly insecure procedure (Intel).
At an even simpler level, it is just the battle between quality and quantity. VW and Intel cheated "a little" to provide the promised performance. We can expect a very great deal more of this.
This is not an Intel only problem; It's a fundamental design flaw (or oversight) that affects most modern processors. While Intel is taking the bulk of the blame on this, my take is this could very well be a catastrophe for smartphones, where each additional clock doesn't just affect performance. Losing a couple of hours a day of battery is pretty significant and quite possible.
Re: (Score:3)
This is not an Intel only problem; It's a fundamental design flaw (or oversight) that affects most modern processors. While Intel is taking the bulk of the blame on this, my take is this could very well be a catastrophe for smartphones, where each additional clock doesn't just affect performance. Losing a couple of hours a day of battery is pretty significant and quite possible.
There are two issues: Meltdown, which is easyish to exploit and affects all post-1995 Intel processors and 4, count 'em 4 Arm processors. Then there's Spectre which is hard to exploit and affects some other processors, but mostly Intel. Intel want everyone to believe that this means every vendor's in the same boat. They've done a very good job at this pretence but it is still a pretence. Or, "lie" if you prefer.
Re: (Score:2)
This is not an Intel only problem; It's a fundamental design flaw (or oversight) that affects most modern processors.
Meltdown is the Intel-specific bug (it's different and can be patched, at a 70% performance hit.) Spectre is an architectural issue in all modern chips that can't be fixed without redesigning them from the ground up. Intel is taking the heat for Meltdown because it reeks of extraordinarily sloppy design and/or an attempt to cheat and have the best benchmarks by making an insecure chip. I'm sure to them it wasn't even that big of a deal, they know their chips are all backdoored with Intel ME, so what's on
Re:Same syndrome as VW (Score:4, Insightful)
Bullshit. The suggestion is frankly completely bonkers - there are no similarities at all!
What you are suggesting is that Intel willingly incorporated a security violating bug in order to gain some performance... How the hell would that work out?
No don't respond as it's obvious you don't know enough to answer.
Re:Same syndrome as VW (Score:4, Insightful)
It found out about the bug in June and continued to sell defective processors for the last seven months.
So yes, Intel willingly incorporated a security violating bug, for at least the last seven months.
Re: (Score:2)
I don't know that much about CPU design and fabrication but it's my understanding that the manufacturing process takes several months at least, so assuming they discovered the flaw in June and managed to *immediately* change the design to fix it, implementing those changes to the production line the very next day, it quite possibly could still have taken months for the revised designs to make it into the factory doors.
But after you consider that coming up with a fix might itself take weeks at least, and imp
Re: (Score:2)
Re: (Score:2)
Re:Same syndrome as VW (Score:5, Interesting)
It found out about the bug in June and continued to sell defective processors for the last seven months.
So yes, Intel knowingly did this, for at least the last seven months.
Re: (Score:2)
The underlying pattern is exactly the same as the VW scandal. A manufacturer tries to deliver the promised performance, and in order to do so fakes out an emissions test (VW) or builds in a highly insecure procedure (Intel).
At an even simpler level, it is just the battle between quality and quantity. VW and Intel cheated "a little" to provide the promised performance. We can expect a very great deal more of this.
Wow. So basically your line of thinking is: "Company did something that turned out to be bad. Another company did something that turned out to be bad. Therefore conspiracy!!!!!!"
Please use that grey matter between your ears to maybe read up on the VW scandal and this issue here before you look any more stupid than you already made yourself out to be with this post.
Lots of hand-wringing & schadenfreude here (Score:3)
This is just not an attack-vector that computer architects are used to reasoning about. For the most part, the security isolation story is bas
Not surprising at all under the circumstances (Score:4, Interesting)
Seeing as replacing every Intel chip sold in the last decade would break the company overnight AND the problem can be patched (with an uncertain performance hit that may negligibly low in most scenarios, but could be ridiculously high in a few), I'm not in the least bit surprised by this.
They're going to have to either kick it up a notch in the next product cycle OR find and release similar vulnerabilities in the competition's product lines or they're going to lose a bit of market share over this, though.
I'd be shocked if they lost a huge portion of the market. There are a lot of PHBs out there who think Intel is the only option.
Re: (Score:3)
The fact is they could replace older chips a lot less expensively than people think. One reason if they use modern manufacturing to produce older chips the yield would be nearly 100%.
Re: (Score:3)
"You MUST by my chip, it will cost you $30" is a business even Al Capone could be happy with.
A recall is absurd. Software is a thing. (Score:5, Insightful)
It's not possible recall all the processors that ever existed. Society doesn't have the resources even to think about such a thing.
Besides, computers run software, which is almost infinitely malleable; it can be crafted to mitigate the problems of hardware—as it has always done. So much of programming is about working around someone else's boneheaded mistakes.
Now, that being said, this is actually a good reason to support FOSS. You cannot trust other people (especially large, flush corporations) to care enough about your particular situation to fix up the software so as to mitigate such problems. If only more software in the world were open to inspection, then at least people who really care could go about fixing things themselves, and the rest of you consumer nitwits could at least benefit from their hard work, too.
We'll get there one day.
Re: (Score:3)
I'd like to see an option to return my CPUs for a free fix. For some people the performance loss is significant.
It won't happen because they don't make CPUs for those old sockets any more, and they aren't going to give me a free motherboard and RAM upgrade.
Re: (Score:2)
I'd like to see an option to return my CPUs for a free fix. For some people the performance loss is significant.
It won't happen because they don't make CPUs for those old sockets any more, and they aren't going to give me a free motherboard and RAM upgrade.
Are you claiming a real significant performance loss, and not a theoretical one? What workload are we referring to here? I think others would like to reproduce your results.
Not entirely absurd (Score:2)
A recall doesn't have to be all-or-nothing. Intel could at least make an effort to replace the worse-affected situations.
If they advertised a certain performance and their design flaw makes that performance not possible, it's legally breach of contract and/or false advertising. They don't automatically have a get-out-of-punishment card JUST because of the magnitude of the mistake. "It's too hard to uphold" is not a sufficient excuse. There is a continuum of resources and effort they can provide to replace b
Re: (Score:2)
It's not possible recall all the processors that ever existed. Society doesn't have the resources even to think about such a thing.
Issuing a recall doesn't mean that you'll successfully buyback every item that was sold. There may not even be a buyback program. And how quickly you've forgotten that society has dealt with far larger recalls, even in just the last year, in fact.
Take VW's emissions scandal, for instance, which affected over 11 million vehicles. They were forced to recall vehicles spanning nearly a decade after they advertised performance numbers that were only achievable thanks to their use of a "cheat mode" that cut neces
Re: (Score:3)
Having the source code doesn't make an application anymore trustworthy from a security standpoint,
Re: (Score:3)
A recall actually wouldn't be that expensive for Intel. Most CPUs and SoCs with the same die size [techreport.com] as Intel's CPUs sell for only around $20. The $100 to several $1000 Intel is able to command for their CPUs is due to marketing and them being top dog. The material cost of the Intel* CPUs themselves is only a tiny fraction of their retail price. (Which raises the possibility o
This doesn't surprise (Score:5, Insightful)
Re: (Score:3)
Re: (Score:2)
Cloud and VPS services are going to be hammered by this. It's a critical flaw for them and their systems do a massive amount of calling and switching in and out of the hypervisor and every running OS kernel.
Imagine your service suddenly and permanently losses 30% of its capacity. Hundreds of millions of Euros of computing power wiped out. Your customers are pissed because their bills are going up as their apps suddenly need more CPU cycles...
The I/O performance is still impacted by the CPU (Score:2)
Re: (Score:3)
Re: (Score:2)
If you're on Win 10 you pretty much have to (Score:2)
Re:This doesn't surprise (Score:5, Informative)
My brothers pissed because this is going to tank performance in the IO heavy strategy games he plays and he bought his i7 specifically to play them.
Where'd you get this from? So far the only benchmarks I've seen show sweet fa difference for any kind of gaming before and after the patches.
Boo hoo (Score:2)
Perhaps it might incentivise him to get out the basement and go get some exercise instead.
Re: (Score:2)
But you use Oracle Sparc64 for all your database work, don't you?
Sorry, but no, sorry. It's not "fixed" (Score:5, Informative)
Well, maybe in the veterinary sense, but I didn't plan to buy a castrated CPU.
First, the problem is in the processor logic itself. We're talking about a design flaw that could only "really" be patched by re-etching the silicon. I highly doubt that he has found a way to rework the die. This isn't some BIOS feature we have to patch. Intel's promise now is that they found a way to manage the problem in microcode. And whether the microcode patch will do any good is still to be seen. Personally, my stance is "seeing is believing".
Mostly because there is a second aspect: ALL, and I do mean ALL, possible approaches to fixing this can only be done with a drop in performance. There is no way this can be addressed without taking a performance hit. Especially high I/O applications like database processing is severely affected by the current patches, postgresql cited performance drops of up to 30%.
Simply having the gall to state that this is no reason for a recall takes quite the chutzpah. I kinda wonder whether various high performance data centers will simply swallow this.
Intel *will* settle at some point... (Score:5, Interesting)
The bug primarily affects large cloud vendors like Google, Facebook (who have entire buildings filled with lawyers) and HPC clusters (many of which have law *schools*).
Without the patch, the computers are vulnerable, and large data centers *must* upgrade given the size and value of the target they are. However, the loss in performance may be substantial. I help manage a ~2000 server HPC cluster. If the patch causes us to lose 5% of our performance, that's like throwing 100 computers away. Which is completely and utterly unacceptable, and we as well as others have the resources to make that crystal clear to Intel.
Re: (Score:2)
I suspect HPC will take little or no performance hit. The hit comes on workloads that do LOTS of system calls. HPC does hardly any.
Re: (Score:2)
Intensive Intel research shows (Score:3)
Intel CEO Brian Krzanich said the new problems are much more easily fixed by other people who knew what they were doing. "After all," he continued, "do you want the idiots who did this to work on the fix? You're better off doing it yourself. I'll be at the beach if you need me."
What about kicking Intel out for AMD! (Score:2)
What about kicking Intel out for AMD!
Time for AMD EPYC where are the 1P boards super mi (Score:2)
Time for AMD EPYC where are the 1P boards super micro?
H11SSL-i / H11SSL-C / H11SSL-NC does someone have an link to a store where I CAN BUY them??
Someone make an amd ryzen board with ipmi! (Score:2)
Someone make an amd ryzen board with ipmi! for systems that don't need an high end epyc system. Like xeon e3
Doing it Right - Deploying a Patch (Score:2)
If there is no need for a physical recall and a simple software patch does the job then that is the right thing to do. It is better for Intel, better for customers, better for vendors, better for the economy and better for the Earth. A physical recall has very high costs for each of these groups. Yes, some people might like a 'shiny new computer' out of the deal but that is just greed. Unfortunately there will likely be some lawyers who will try and get rich on this with a big lawsuit. Shakespeare them. ("F
Re: (Score:2)
Question on Timing (Score:5, Interesting)
But I'm interested in this for a slightly different reason. In mid-December 2017 I purchased a new computer system. I had been saving up for it for a very considerable period of time... It is based around the Core i7-7700T processor, which I now understand to be one which will be impacted and likely to "slow down" as the patches for Windows and Linux are deployed.
But Intel knew that the chip that I would be buying was materially defective. Whilst I accept that they have taken steps to apply corrective software fixes, that doesn't detract from the fact that I could have chosen to defer my purchase until a "clean" chip was released. Here we have the CEO saying "no recall", yet how are Intel's actions any different from i.e. the Ford Motor Company / Firestone Tire issue?
Are Intel claiming that they have no legal obligation to sell working product? Or to take appropriate steps to notify customers in a timely manner? If they knew about this in October, has it *really* taken this long to get patches ready and come clean? And what about all the product already in the supply chain?
I would be *very* interested to see any data from Intel's distributors or channel suppliers to get a better handle on shipment volumes in the time slot in question. Very interested to know if Intel made a push to "get rid" of known bad stock. Very interested to know what the lead time is for good silicon.
Anyone got any real-world experience of these scenarios?
Re: (Score:2)
You nailed the issue. In addition, Intel is STILL SELLING their defective product. Intel did the
Re: (Score:3)
Anyone got any real-world experience of these scenarios?
I invite you to look at a history of erratas from any CPU (or silicon in general) manufacturer. It is literally situation normal to sell devices with known defects that need to be worked around, and it has been since the 80s.
The problem with your "defer" option is that you're unlikely to defer when there's no end in sight.
Re: (Score:2)
Re: (Score:2)
probably not, but the ability to read the pipeline contents that was speculative and not used when not in kernel mode probably could be. That would be a significant improvement (like putting passwords on your baby monitor when having sex). Of course with the IoT's track record, that may not be possible either.
Re: (Score:2)
Re: (Score:2)
I'm not sure what you regard as the difference between a fix and a mitigation. If intel changed the processor so that no memory accesses were launched until the CPU knew for sure if the memory management was going to permit it execute them, they would be slower for legitimate workloads because more time would be spent waiting for data from memory after the accesses were launched later. Is that a fix or a mitigation? If you think that i a mitigation, then no fix may be possible at all. If you think it's a fi
Re: (Score:3)
70%?
What's with the obviously crazy people posting about this? Not only here but elsewhere including "articles" (read: crap) claiming the sky is falling and processors as we know them aren't possible anymore...
Intel have a bug that leads to a potential security breach in certain systems under certain circumstances. Yes that's really really bad for some systems including cloud computing farms. It is bad as it opens up other systems for security breaches. But it isn't the end of the world.
30% impact is for so
Re: (Score:2)
If they DON'T fix it, then they may be seriously short of future customers. Now THAT would be a serious financial hit!
Re: (Score:2)