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.
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.