The attack surface of the kernel is much larger than the attack surface of a browser. Not saying this is a bad idea, but it definitely opens up much more room for much more serious attacks.
The browser already mitigates this via the normal system call sandboxing on the various OSes.
And something like this already existed, 32bit chrome would play games with the LDT on OSes that allowed that to build a better sandbox. It's just that the LDT more or less disappeared on x86_64.
Ring 1 and 2, while rarely used on x86 have meaning that is not appropriate for what is needed here.
What I want is a new ring-4. Ring-4 is like ring-3, except that cache attacks are mitigated (disable speculative execution is the obvious option, but there might be something else that I don't know of). Ring-3 code can put parts of itself in ring-4 mode as required.
If you just want to disable speculative execution, you can already do that. Just emit an lfence in front of every load. Of course, you don't want to do that because it'd cut into your execution speed by 10x to 100x. What you want is the ability to keep speculative execution, but not allow the JITed code to speculate based on information in the same process that it shouldn't have access to. To do that requires describing the different security zones to the processor somehow.
Why I say that bringing back rings one and two is a good idea is that it gives another context to user mode _and_ kernel mode, so that the kernel can protect itself from BPF style programs at some point.
Ring 1 and 2 already exists on x86, we can't just reassign what they do, which is why I introduced ring-4. Ring-1 and Ring-2 are too powerful for user programs, the web browser should not use them.
Sure you can, it just needs to be opt in. And since x86_64 neutered rings 1 and 2 to the point that they don't really make sense to use anyway, it shouldn't be a big deal for downstream software either.
