Meltdown shouldn't hopefully be an issue, as there are high performance CPUs which are immune. A proper Spectre V2 would probably require partitioning the jump prediction tables by process; in the meantime flushing seem to work (although at a non trivial performance cost).
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).
> But it only affect,as a first approximation, processes that try to execute code with different trust domains in the same address space
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.
The ebpf is not the exploit. The ebpf was used in the proof of concept to generate a gadget in the victim process (in this case the kernel). Similar code patterns already existed in the kernel, the authors just used ebpf to make their own so they didn't have to hunt one down.
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.
Note that 2+ decade old 200mhz pentium pro is very likely as vulnerable to spectre as the current generation. Frequency doesn't really factor in it.