I wasn't clear. I meant that we shouldn't take huge performance hits for having some security at the hardware level.
The issue is the basic spectre v1 vulnerability, the bound check bypass, is so firmly rooted in the basic mechanism of speculative execution that it is very unlikely to be fixable. But it only affect,as a first approximation, processes that try to execute code with different trust domains in the same address space. The existing software mitigations appear to help, address spac separation is probably a safer long term solution.
There are simple in order CPUs that have a small speculation window and are, in practice not affected, but it is not a given that an high performance in order core is safe. Denver (an inorder VLIW design) is affected; I can't find anything about power6 (the last inorder CPU competitive with OoO).
This is wrong, even as an approximation. This comment, as well as your other comments on this thread, indicate that you misunderstand spectre v1. Some of the initial proofs of concept of spectre v1 demonstrated the attack with both victim and attacker in the same process, but that is not necessary, and the original materials disclosing spectre make that clear.
The paper [1] describes spectre v1 as a technique in which "conditional branch misprediction can be exploited by an attacker to read arbitrary memory from another context, e.g., another process" [emphasis mine]. The others go on to describe a proof of concept in which a vulnerable code sequence is inserted in the kernel via ebpf, but the attacker is in user space: "we use the eBPF code only for the specu- latively executed code. We use native code in user space to acquire the covert channel information."
It's not clear whether spectre v1 style attacks within a single process can be prevented by hardware, but spectre v1 attacks in which an attacker process manipulates a vulnerable gadget in a victim process certainly can be.
Running untrusted code in the same process as trusted code has always been dodgy, and now will probably need speculation barriers at bounds checks. But the most worrying part of spectre v1 is how it can be used to bypass process (and user/kernel) isolation, and that can and should be fixed.
If you don't believe me, perhaps the document making its way into the kernel source (and the review comments) will make things clear: https://lkml.org/lkml/2018/12/21/577
If you are still not convinced, take a look at these patches merged into Linux to mitigate a vulnerability you are arguing doesn't exist: https://lkml.org/lkml/2018/1/5/769
Spectre V1 can be exploited by simply passing parameters to code that runs in another process. It does not require that the attacker can run code in the victim process.