You could ask the same question about any class of security bug, so unsurprisingly I'd answer more or less in the same way.
No. the problem here is that the code isn't wrong. The CPU is wrong. Whether or not the CPU will leak data depends on the make and model of CPU. Most MIPS CPUs and many ARM CPUs don't have this problem. Some AMD x86-type CPUs may not. It has to be fixed on the CPU side.
This could introduce Intel to a world auto manufacturers know well - recalls. Intel has been there before, with the floating point bug.
You don't actually have an argument though. Why is the CPU wrong? Because you say so? And btw, you're wrong about this not affecting ARM or AMD. It affects everyone with speculative execution (we're only talking about Spectre variant 1 here - if you're confused about that, please go back to my first comment in this thread).
Look: When other side channel leaks were found, e.g. people recovering RSA or AES keys from plain cache timing without speculative execution, maybe there were people similarly arguing that it's the CPU's fault. They lost that fight, too. Today, the uncontested consensus is that cache timing leaks are the code's fault, for good reason.
Because what are you going to do, stop building caches? Obviously not, they exist for very good reasons. The same is true for speculative execution. What do you expect CPU people to do? Rip that out entirely? Be real. (Please, seriously think about that: what is it that you actually want CPU people to do? Don't just handwave!)
This kind of discussion is why Linus Torvalds regularly flames security people.
No. the problem here is that the code isn't wrong. The CPU is wrong. Whether or not the CPU will leak data depends on the make and model of CPU. Most MIPS CPUs and many ARM CPUs don't have this problem. Some AMD x86-type CPUs may not. It has to be fixed on the CPU side.
This could introduce Intel to a world auto manufacturers know well - recalls. Intel has been there before, with the floating point bug.