Slashdot Mirror
Nope, No Intel Chip Recall After Spectre and Meltdown, CEO Says (cnet.com)
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.
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. Good thing he sold all his stock before this went public.
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.
I am sure that there are many other solipsists out there.
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.
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.
Yep, that sounds like Intel (at least after you add in the fact they're trying to spin it as a ~30% speed reduction, which would still amount to about $210 per processor to make for a fair rebate.)
Caveat Emptor.
Intel offered a product, and you chose to buy it. The whole thing was voluntary. There was no fraud, either; Intel never said its chips were free defects; indeed, anyone who has had even a passing interest in the world of computing knows that a huge amount of software (especially kernel stuff) is devoted hiding and working around hardware-level "quirks" (read: bugs).
If anybody sues Intel, they'll be suing Intel only for providing an optional feature that makes computations faster. That's it. You don't want the security risk? Well, turn off that optional performance optimization.
That's a lot, but it's not all.
A lot of users won't be impacted. 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. It's looks like enough to knock him down to high end i5 territory. That's about $75-$100 worth of performance gone in a puff of smoke....
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Microcode can change a lot of things about a processor, but microcode generally works by "pulling a bunch of strings" in the CPU control unit in a particular order for each CPU instruction encountered. Those "strings" go to a bunch of complex hard-wired circuits that can never be changed. I seriously doubt that the characteristics of the CPU TLB can be changed with a simple microcode update.
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
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."
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Yes that is wrong. Intel is trying to fool you with terms like "microcode update" and "chip level fixes". There is no fix for Meltdown other than replacing your faulty Intel processor. NONE. If you don't believe me, ask the experts. You can only mitigate the issue.
Comment removed based on user account deletion
AFAIK the kernel software workaround (called KPTI in Linux) makes it impossible to exploit the Meltdown hole (i.e. variant #3 from Project Zero). There's some performance cost but Google has measured the cost as negligible on real workloads. I'm running with a similar patch in OS X and I can't tell any difference.
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.
If they DON'T fix it, then they may be seriously short of future customers. Now THAT would be a serious financial hit!
Sent from my ASR33 using ASCII
What about kicking Intel out for AMD!
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.
Sent from my ASR33 using ASCII
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! for systems that don't need an high end epyc system. Like xeon e3
Nice try. Intel has done recalls for much less. There is no "firmware update" that will fix it. This is a huge flaw that cannot be fixed. But nice try at spinning it.
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. ("First thing we do is kill all the lawyers." -S)
This was not Intel knowingly cutting corners. The amount of verification that goes into building a CPU is mind-boggling. There are dozens of layers of constrained-random verification, formal verification, electrical verification, performance verification. The techniques used are decades beyond the types of QA testing that most people on this forum are familiar with.
This is just not an attack-vector that computer architects are used to reasoning about. For the most part, the security isolation story is based on keeping architected state separate--caches are supposed to be architecturally invisible so you don't think of them as being an attack-vector. You certainly don't think of the measurable access latency through the cache hierarchy as being part of the attack surface; classically when we're reasoning about process isolation we aren't thinking about timing at all.
The exploit here relies on measuring the latency to access some piece of data that you have permissions to, and using that to infer the value of a piece of data that you don't have permissions to--it turns out the two are connected due to the way exceptions are handled during speculative execution. It slipped through the cracks. Mistakes happen.
You're well within your rights to complain about how Intel is reacting to the bug--but it is absurd to claim that they "knowlingly cut corners". I have no way of knowing, but my guess is that you churn out buggy Javascript for a living--which makes your 'holier than thou' attitude even more misplaced.
when you put it like that it makes it sound like the problem is his hard drive, which it's not. A faster drive wouldn't fix the performance issues either (e.g. it wouldn't make the CPU turns faster).
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
It's damn near impossible not to. He's on Win 7 though so he's OK. My Win 10 machines didn't let me say no. I suppose I could manually remove the patch but I'm 90% sure they're gonna try and install it again.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Perhaps it might incentivise him to get out the basement and go get some exercise instead.
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
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" suggests that there might be other issues behind your comments
"Every time I see an adult on a bicycle, I no longer despair for the future of the human race." - H. G. Wells
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 fix then why is swapping in a OS kernel that avoid sthe problem equally well with the same performance cost not a fix?
A lot of people are commenting on the fact that Intel's CEO sold the maximum permissible amount of company stock [or options - it isn't clear which] *after* Intel were notified of the bug and *before* this was made public.
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?
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 bad chips.
I agree they shouldn't be forced to commit corporate suicide via mass recall, but they should at least be court-forced to make a strong effort if they failed to deliver on their performance claims. I expect a class-action lawsuit and some kind of upper-limit of payouts agreed to so as to not outright kill the company.
Table-ized A.I.
Or employing CPU designers that know how to do their job.
Sent from my ASR33 using ASCII
MetricT's company might not be all that influential as a single company - we just don't know. But there is nothing to stop all the major cloud providers from agreeing to join forces in a class-action lawsuit against Intel - and they have the backing and clout to make sure they get it.
The challenge for Intel here is that the harm is done. They need to repair both the reputational harm and the actual damage this incident has caused.
It took Apple a couple of days to figure out the damage being done by the iPhone battery issue [they likely got data directly from their sales channel and saw an immediate decline in sales] but Intel face the same hurdle here. Remember, though, that Intel are shielded from immediate effects because they only sell to integrators and channel partners. It might take 3 months before they actually saw sales diminish.
It won't lessen the impact when it comes.
The best thing Intel can do right now is to prepare a recall or offer a trade-in and get ahead of the negative publicity. Only their greed and their hubris is stopping that.
This isn't a simple errata. This is HUGE flaw, a true game changer. It is a flaw that CANNOT BE FIXED, only mitigated to some extent.
Meltdown CAN be fixed. You simply change the VHDL / Verilog code to do access check BEFORE the speculative execution and NOT AFTER.
You know, like AMD does it.
(Spectre is another matter.)
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.
Yes, it is. Their initial response to the FDIV bug was that it was a rarely used instruction so they wouldn't be replacing the chips. I got mine replaced, and will be getting new processors this time too. It all depends on how tenacious you are. If if costs them less to replace the chips than to deal with you they will replace them.
Comment removed based on user account deletion
Until some similar bug crops up on AMD too.
The proper approach to unreasonable people is to ignore them.
From now on, we'll only be buying AMD-based machines. Buh-bye, Intel!
I don't respond to AC's.
OK yes it is bad, but how does someone running a desktop/laptop get hit? In order to exploit the bug, wouldn't another process not of your knowing have to be running? I get it is a major issue for cloud machines where they are sliced and diced for multiple users, but my machine I don't see it. If I have processes running that are foreign that are not standard system processes, I think I have bigger problems than this to worry about.
Comment removed based on user account deletion
Heavy on IO. CPU turns are taking longer. I gather if you play the really huge and poorly optimized Grand Strategy games it's a problem. He tells me folks on the forums are already complaining. There's also been some scattered reports on the Ghost Recon Wildlands forums of big hits to frame rates, but it's pretty random. Some folks saw no difference post patch and others went from 60 to the mid 40s.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Comment removed based on user account deletion
It's in the SEC filings that the CEO cashed out a larger than usual quantity of stock option exercises and then sold them, starting literally the day he found out about the flaws.
Trust him if you want, but as a longtime tech investor, I wouldn't.
-- Tigger warning: This post may contain tiggers! --
To play devil's advocate: I don't know of a single chip that doesn't have errata published by the manufacturer. The first "real" lesson I learned in my EE career is "you can't take the manufacturer's documentation at face value."
The important thing is how problems are handled, and I don't know of any chip maker who handles bugs like this well.
When their GeForce 8600M had issues with overheating and dying, NVIDIA first blamed notebook manufacturers, and later the foundry. It was later found to be a problem with NVIDIA's silicon layout. Apple had to replace millions of MacBooks whose NVIDIA card died after less than a year (Ever wonder why Apple uses AMD graphics these days?)
Even AMD has issues when it goes into CYA mode: Back in the day, AMD had major TLB issues with their Phenom processor. At the time AMD claimed the "... TLB erratum is a highly random event that would not occur during normal desktop usage and we've never encountered it during our testing of Phenom." "Normal desktop usage" was defined to exclude a Xen hypervisor running Windows XP, or running the SPEC 2006 benchmark -- not exactly common, but they're clearly doing the PR spin.
Then there's Intel... Some serve as an example of others to follow. Others serve as a warning to others.
In the past two months alone, from serious bugs in the Intel Management Engine to Meltdown, they've done a great job serving as a warning.
-- Sometimes you have to turn the lights off in order to see.
Could a root-kit using VT bypass this for the guest if it was specifically built to not include any of these "fixes"?
"... to determine which ones to prioritize based on what they see as systems in the field"
How about taking responsibility for all of them, right now?
- The Kessel run is for nerf herders. I can circumnavigate the entire Central Finite Curve in a lot less than 12 parse
Comment removed based on user account deletion
Comment removed based on user account deletion
Another random thought here... Thinking about all the manufacturers of systems - Dell, HP, Lenovo, Apple, the list goes on - who currently have tens of thousands of built machines sitting in warehouses, or in shipping containers in transit, or in stores waiting to sell... which have this bug in them.
What would happen if the general public collectively decided, "Nope. Not going to buy it with a bug in there. We'll wait for new generation processors, thanks..." ???
Sadly, I think this is unlikely to happen, but I wonder if something like that could get the channel integrators to put enough pressure on Intel to offer replacements? And, if you were a channel integrator, what would you do with all your Intel stock that you haven't already fitted to a system?
At the very least...
> Security is like virginity: indivisible. You can't be "just a little bit insecure".
/., and that's saying something. There is NO such thing as perfect security. All you can do is raise the cost, time, & effort required to defeat the security measures. This is true for every kind of security that has ever existed in the history of mankind.
This is the most false statement I have ever heard on
> Note that the remedies for Meltdown will more than wipe out the performance gains obtained by the ill-advised speculative execution.
You really have no idea what you're talking about. Turn off OoO execution and performance slows down dramatically. Turn on KPTI and performance slows down negligibly.
It's clear you don't understand computer architecture, engineering, or basic security principles.
How can Intel replace all these effected CPUs when there is not a replacement? It seems that the /. and other communities have gone stark raving mad. There is no hardware fix. Life is a dangerous adventure. It doesn't matter what "Mother" tells you -- you live in an unsafe world and an unsafe computing environment. The best attempts by any person and even by Intel will always fall short in providing a truly "Safe" world or computing environment will Never happen. Even the courts and legislatures can't change this. As the Eagles sang, "Get over it!" And get on with a real & authentic life -- take responsibility for your own happiness, etc.