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.
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.
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 of attack method.
So from a warranty standpoint -- the CPUs are not defective, they perform as promised, but are just vulnerable to unforseen issues which are Not specific to the way Intel's CPUs are made BUT are general to the way almost All CPUs are made by ALL the manufacturers.
You DON'T always get a free upgrade to your hardware when new unforseeable attack methods are discovered.
Instead, sorry, but if your security requirements necessitate a hardware change, then you're going to have to pay for it, and don't expect a massive charity from Intel.
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.
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 solutions to most of this (modifiying the programs/OS holding the secure data so that it cannot be read this way), in which case they probably have an argument that software should have been written that way in the first place.
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 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