The problem is this nearly every single processor Intel shipped for a decade so Intel doesn't have the cash flow to RMA that many replacements. They're going to fight tooth and nail to avoid this.
In reality they could probably argue standard depreciation on a product and offer the remaining value as a discount towards a working product... only there currently aren't any equivalent products on the market. AMD's CPUs are still affected by lower profile variants of this, but aren't as /horridly/ broken.
In reality they could probably argue standard
depreciation on a product and offer the remaining
value as a discount towards a working product...
This could work for older models, but their flagship $15,000+ each (in bulk trays) are also affected. So its hard to argue depreciation on <2 month old silicon.
I can't imagine a court doing anything. The cost to intel is simply to high, and its not like they were negligent given that ARM/POWER/etc are all vulnerable to some extent too.
This whole thing is the equivalent of discovering that if someone throws enough nails on the road your car will blow a tire, spin out of control and kill you. With the kneejerk reaction of trying to fill everyone's tires with concrete to avoid the tires blowing out rather than trying to figure out how to keep people from throwing nails on the road (with the idea that spiteful users are more likely on toll roads) in the first place.
I agree with you that the courts probably won't do much, but you should not group all the CPU manufacturers together. Meltdown mainly (only?) affects Intel. It's spectre that affects basically everyone.
Actually, it is more like that someone can throw a rock through a car window and then compromise the car door lock. Or, probably more accurately, that a hitchhiker can knock you out of the car, and drive off with it.
Spectre/Meltdown ONLY is an issue if you run some untrusted code on your system. If you avoid this, there is not problem. Yes, we like to be able to run untrusted code (such as in a web browser / javascript), but that is not the fault of a car manufacturer that you like to pick up hitchhikers.
I'm with you on the untrusted code bit, which is why I think unmapping the kernel should be restricted to untrusted processes. Then it only applies to your browser, the KVM/qemu instances or whatever runs untrusted code.
Yup, this will hit the EC2/etc users hard, but those people have already IMHO given up on absolute performance by putting themselves in shared environments where bad neighbor syndrome can already hit their perf pretty badly.
But for whatever reason (probably because its easier) the current plan just seems to be to use the big hammer.
The big hammer is the pragmatic approach for the short term. Everyone and their dog wants to claw back the lost performance, we're only week past the big reveal.
Your idea of black/white listing processes might bubble up as a solution in some scenarios. Perhaps it could be pledge-like; if you're savvy enough, try implementing it, or fleshing out the details.