> 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

> 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. [1]: https://spectreattack.com/spectre.pdf https://spectreattack.com/spectre.pdf