> That's not going to happen without multiple major players demanding it. Since nearly all the major CPU consumers are currently happy with process boundaries being the security enforcement zones, there's no particular reason to believe that in-process sandboxing will ever have hardware fixes to prevent spectre attacks.

The amount of untrusted code running in browser is only increasing over time, and the CPU vendors have absolutely noticed this. That's why ARMv8.3A added an instruction that literally has JavaScript in it's name (FJCVTZS) for instance.

Once you have mitigations for colocating trusted and untrusted code in ring 3, doing the same in ring 0 almost certainly isn't a big deal.

Browser vendors have already rolled out process isolation to handle this. So why would CPU vendors spend silicon on something userspace has already solved with the building blocks that are already supported?

In-process sandboxing by all appearances is simply dead.

As for "doing the same in ring 0 almost certainly isn't a big deal" no, very extremely no. If you let code run in ring 0 it has everything ring 0 can do, period. You cannot put restrictions on it, that's what spectre proved. Give code access to a process and it has entire access to that process. Similarly give something ring 0, and it has the entirety of ring 0.

Untrusted code goes in ring 3 in an isolated process. That's the security model of x86, and it's the only model that CPU vendors have any pressure to fix.

It's worse than what you're stating. Spectre is remotely exploitable with network packets (NetSpectre). The current state of the world isn't just fine with process level security, and the chip vendors are going to need to fix it, because ultimately you can exploit then if you control the data, not just the code. They have several options available to them, all of which also let's you run sandboxed untrusted code in the same MMU context as trusted code.

It is unclear if NetSpectre works in a real environment, but either way it's fundamentally similar to an IPC call and can be treated as such. As in, that's where you'd insert hardening boundaries.

Chip vendors have & will fix process boundaries. But nobody is talking about any sort of protection of any kind that would let in-process sandboxing work again. It's just not even on the table at this point.

> Preventing side-effects from leaking between processes (and ring levels) entirely at the hardware level is definitely going to happen. Within a process, though? That's not going to happen without multiple major players demanding it. Since nearly all the major CPU consumers are currently happy with process boundaries being the security enforcement zones, there's no particular reason to believe that in-process sandboxing will ever have hardware fixes to prevent spectre attacks.

I do not think there is the degree of distinction between "processes" and "threads" that you think there is. If tools exist to isolate speculation state between processes, those tools can probably also isolate threads in a process.

Of course there is. Threads share page tables, processes don't. Literally the exact distinction between threads & processes in userspace is the one that exists in hardware, too.

Processes share the higher half of the page tables at least partially, even with KPTI turned on.