Replaced/repaired, not free. Having said that the problem will be how to replace processors that have become obsolete and therefore out of the market, and where you can not simply replace all the associated hardware to pick up a current and patched processor. And I suspect that most of those who can change the associated hardware will simply migrate to AMD instead of taking another Intel.
Oh I agree 1000%. It's not a freebie, it's Intel living up to the implicit contract to provide a CPU with the performance it was benchmarked when I bought it and not allow user mode stuff to read kernel memory.
In the UK you could make an argument that a processor with that bug was 'not fit for purpose'. Of course it's in the US that a class action suit has the highest chance of success and outside the US Intel will probably follow the US lead.
It'll be interesting to watch. Then again all my Intel chips are
Mind you Intel will presumably claim KPTI and its equivalents on Windows and macOS fix the security problem and any change in performance doesn't violate any sort of contractual agreement.
You are mentally modelling KPTI as an annoying one-time fix (with not much further burden), and not as a brittle work-around that requires permanent vigilance to pervasively deploy and enforce (Google's retpoline certainly falls into the class of permanent vigilance burdens).
Not to mention that your carefully performance-balanced server loads need to be re-engineered around this unpredictable new performance sink-hole. KPTI is not as simple as a CPU microcode update (which also has performance implications, though not usually broad and severe).
This whole mindset of "a patch, is a patch, is a patch" coincides with faulty logic in OS hardening. You see this opinion all the time that an attack mitigation that can be easily worked around isn't worth implementing.
That's the non-metabolic view.
The metabolic view is that every extra difficulty adds complexity to carrying out a successful attack. When we are trying to build something constructive, difficulty scales exponentially in the size of the specification, as we all know. When we are tying to build something destructive (a root kit), this same scaling term is now magically rendered sub-linear. (There might actually be a grain of truth here, due to the inherent asymmetry of success and failure, but that should hardly be taken for granted.)
We try to stack up ASLR and sundry related obstacles to tilt the balance in our favour, then along comes Intel, who dumps a permanent burden on the white hat side of the fence.
How many hundreds of millions of devices out there are never going to receive a patched OS that's compatible with the existing, validated device configuration?
Well, of course, the newest version of the OS is a strict superset of the old OS (though MacOS is not included on this list by virtue of superior Design), and you should stay up to date anyway.
I've been in this industry since the 8080. Enough already with the Stockholm syndrome.
Just imagine Boeing retrofitting your turbo fan with 20% less maximal thrust due to faulty wing design. So the airlines need to stop flying Boeing into Denver on hot days? (Surely your air service scheduling system can manage one more tiny constraint.) What's the big deal? Problem solved.
"I want repaired processors for free" (Score:5, Insightful)
You know, he's not wrong. This is, in impact, way bigger than Intel's FDIV fiasco and that ended up in recalls.
Re: (Score:3, Funny)
Free i5s and i7s! I want to believe!
Re: (Score:5, Interesting)
Re: (Score:5, Interesting)
Oh I agree 1000%. It's not a freebie, it's Intel living up to the implicit contract to provide a CPU with the performance it was benchmarked when I bought it and not allow user mode stuff to read kernel memory.
In the UK you could make an argument that a processor with that bug was 'not fit for purpose'. Of course it's in the US that a class action suit has the highest chance of success and outside the US Intel will probably follow the US lead.
It'll be interesting to watch. Then again all my Intel chips are
patch metabolism (Score:2)
You are mentally modelling KPTI as an annoying one-time fix (with not much further burden), and not as a brittle work-around that requires permanent vigilance to pervasively deploy and enforce (Google's retpoline certainly falls into the class of permanent vigilance burdens).
Not to mention that your carefully performance-balanced server loads need to be re-engineered around this unpredictable new performance sink-hole. KPTI is not as simple as a CPU microcode update (which also has performance implications, though not usually broad and severe).
This whole mindset of "a patch, is a patch, is a patch" coincides with faulty logic in OS hardening. You see this opinion all the time that an attack mitigation that can be easily worked around isn't worth implementing.
That's the non-metabolic view.
The metabolic view is that every extra difficulty adds complexity to carrying out a successful attack. When we are trying to build something constructive, difficulty scales exponentially in the size of the specification, as we all know. When we are tying to build something destructive (a root kit), this same scaling term is now magically rendered sub-linear. (There might actually be a grain of truth here, due to the inherent asymmetry of success and failure, but that should hardly be taken for granted.)
We try to stack up ASLR and sundry related obstacles to tilt the balance in our favour, then along comes Intel, who dumps a permanent burden on the white hat side of the fence.
How many hundreds of millions of devices out there are never going to receive a patched OS that's compatible with the existing, validated device configuration?
Well, of course, the newest version of the OS is a strict superset of the old OS (though MacOS is not included on this list by virtue of superior Design), and you should stay up to date anyway.
I've been in this industry since the 8080. Enough already with the Stockholm syndrome.
Just imagine Boeing retrofitting your turbo fan with 20% less maximal thrust due to faulty wing design. So the airlines need to stop flying Boeing into Denver on hot days? (Surely your air service scheduling system can manage one more tiny constraint.) What's the big deal? Problem solved.