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.
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/
Just like all the Equifax execs rotting in jail now...
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.
No they aren't if they are trading on information that the public doesn't know about.
Yes, it is insecure by design. What do you think the bug is? You cannot fix Meltdown because the flaw is in the hardware. You can only mitigate the effects.
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.
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.
Sent from my ASR33 using ASCII
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.
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
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?
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.
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
It's Hillary "Correct the Record" levels of horseshit.
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).
Sent from my ASR33 using ASCII
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
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.
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump