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 FDIV recall occurred after much backlash against Intel. If it turns out that Meltdown is exploited on a large enough scale to cause significant damage, or if the performance losses from implementing KPTI are severe enough, Intel may well change its position. Right now, it's nary a story at all because of the 24/7 focus on all things Trump. If people start getting angry due to their systems slowing, a recall might be in order. Intel is simply trying to avoid effectively recalling every non-Itanium processor they've made over the last 2+ decades (or even the last five years if the limit it to non-EOL products), because it would be quite expensive. This is far more widespread than FDIV, but if the impacts are serious enough, it might be the less damaging choice for Intel.
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.
I thought the new microcode updates and bios updates that intel and oems are rolling out would be the fix. Not just a non fix mitigation. Is that wrong?
That's a lot, but it's not all.
Wonder if they will do an out of band silicon rev to fix this in current production processors. That would be a big financial hit for them. My guess is that they'll roll it into a their standard rev schedule. Since they've known about this for many months, maybe we'll see something soon. I was just about to start on a new build but that's now on hold. Wait and see I guess.
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/
Yes, it might be a boon for some, but for society, it's clearly anti-profitable.
All of the resources spent mitigating and monitoring these bugs could have been spent on other things, like bombing more nations or throwing more pot smokers into cages.
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.
Comment removed based on user account deletion
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"
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.
You'll find that out on your own.
Intel has a technology called SGX that purports to isolate data running within "secure enclaves" ... so can these vulnerabilities read into SGX-protected memory too?
People are dreaming that Intel will end up coughing up a settlement for what is a flaw found in hardware anymore then Microsoft would be liable for one found in Windows. No such thing as guaranteeing the hardware will never have a flaw. Also no proof what so ever Intel knew anything about this until last Summer when it was informed of the proof of concept. Personally, everything I have read seems to indicate this will be mitigated through patches and firmware updates and any risk left would be so limited in scope its not worth being concerned about. We have far more riskier stuff in the wild now that is much more effective. Nobody thinks any litigation will be able to prove any malice by Intel or any other chip maker.
What about kicking Intel out for AMD!
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
I mean really. my processor works fine the way it is. Can I opt out of any 'fix'?
The way I use my computer for gaming, etc. I don't see this bug as a problem for my situation.
If the OS applies a 'patch' to my processor that kills performance, then I have an issue. I the patch is inside the OS itself and leaves the processor alone, then fine. But don't touch my silicon without my consent!
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)
You can be sure that the next time his company buys some replacement computers, he's right their explaining to the boss that he needs to buy AMD instead.
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 will be cheaper to rearchitecture the hypervisor.* Plus as I've already pointed out the biggest cloud makers aren't like the rest of us. They have custom hardware and silicon done. Also the performance hit isn't an across the board thing because they have different servers for different tasks. e.g. database.
*One of the selling points of virtual hardware.
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
Only in the mathematical, logical, and I/O sense. Otherwise there are important differences, partially due to workload, and lineage.
https://stackoverflow.com/questions/27333815/cpu-simd-vs-gpu-simd
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.
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
Nobody said FOSS has never had flaws. What is being said is that with proprietary software, you have NO CHOICE but to depend on the good graces of other people who have no real incentive to care about your particular situation.
Get it yet?
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
I've read this over a couple of times and I think they are "spinning" their announcements to make it sound like they issued a fix via microcode, but what actually happened is they heavily contributed to the software level patches that have been made for Meltdown. Was kind of funny to see that this fix was then updated by an AMD guy to basically disable it if the CPU is an AMD one (because Meltdown doesn't impact them.)
I think at this point no one has implemented any kind of fix for Specter (which affects AMD, Intel, ARM, etc)?
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"?
RISC-V may or may not depending upon implementation.
https://www.reddit.com/r/RISCV/comments/7nzd5c/is_riscv_affected_by_meltdown_andor_spectre/
You're the one who's wrong. ARM themselves note that Cortex A57, A72, A75 and A15 processors are affected by CVE-2017-5754 which is the Meltdown CVE (Spectre is CVE-2017-5753 and CVE-2017-5715)
OOSE (Out of order speculative execution) is basically making a statistical bet that the majority of a workflow will go a certain way. One that gives increased performance. Meltdown took some of the time-consuming checks and moved them from the "check first" to the "check after the fact" which is fine as long as your bet that things go a particular way remains true. The exploit consistently broke that bet.
"... 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
Sounds like the hardware version of OOPs with some of the same problems.
Has anyone ever used SHENZHEN I/O to simulate Meltdown and Spectre?
As usual Canada, UK, Australia, India, et al are screwed
Comment removed based on user account deletion
Read the press and disclosure releases carefully. Spectre in some form is a potential issue with any processor that uses speculative execution. EVERY Intel CPU since at least the Pentium Pro does that. Meltdown is a little more specific to Intel because its architecture is more aggressive about speculative execution than some others - giving better IPC but opening up access to this attack. Intel's position is that these are not bugs in the processor - the processor is operating exactly as designed. But the fixes slow down the processor so people are going to see this as CPU bugs. Security == go slower, right? And Intels competitors *are* a tad slower at IPC, though more resistant in general to these attacks (especially Meltdown). Still nothing even remotely modern in terms of CPU design is completely immune to at least Spectre in some form, even mainframes and supercomputers - THAT is why this is fundamentally unfixable at the hardware or, probably, even the microcode level, unlike the older bugs. A whole new kind of CPU design is needed to avoid the problem, not just a faster version of what's already done.
Everything I've read on this so far backs you up 100%.
Comment removed based on user account deletion
Chris you work for a shady IT bodyshop that has been hired by the FBI. You DO work in the private sector.
It just feels like you work for the government because you have to deal with low pay, self important career bureaucrats, urine tests, and invasive background investigations. Your job could go away the second someone decides they don't like you and decides your online activity constitutes a failure to not talk about your work on social media or someone decides to make an issue of your alleged paedo tendencies.
"Security" is a classic go-to excuse to give the ditch diggers and coal miners when they start wondering why it is they work so hard for the man in return for so little. If you had an actual good job nobody would ever have a prepared list of reasons why it's so good to work there. Security works for you because you always, always always get fired^H^H^H^H your contract ends and it's not renewed.
Do you really think you weren't fired from your other jobs? I had a chum who was constantly getting 6 month contracts "not extended", because he was no fun to be around and it was obvious he was on drugs. But he sincerely believed that he was just picking up six month contracts and finishing them.
The worst part is he started getting better and better jobs, essentially getting a small promotion every 8 months. But eventually he burned every major bodyshop in Austin and had to start sucking dick for coke money.
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?
It's because they're not bugs, they're features they were told to put in.
At the very least...
You can do the simple math of their financials: they don't have enough assets on their balance sheet to replace every Intel processor sold since the Pentium, which is the scope of this bug! It would bankrupt Intel to replace them.
As it is, the decline of the PC in the consumer market has already hurt Intel. This would be the end.
> 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.
Sorry, that's not on the cards
That's OK as long as it's in the cards.
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.