I think that sort of reasoning is rubbish, when you can speculate your way past all security boundaries on the chip
The ring boundaries of protected mode were never meant as a strong security feature against malice. The documentation of the 286, the first CPU in which they were introduced, is very clear in saying that. It's unfortunate how many assumed otherwise and built an entire industry upon that misunderstanding.
One sees the same problems with ASLR - page tables were never intended or designed to carry security sensitive information, which the various forms of ASLR are. And so, we see the prefetch oracle, and various cache based trickery to de-ASLR things, because the page tables and page walkers were never designed to consider security, only correctness.
I don't know how to fix it, though.
I've been experimenting with Qubes lately, which disables hyperthreading if you have it, and uses hardware isolated VMs to at least make things a little bit harder - the assumption is that within a running OS VM/silo, anything can access anything, so keep them separated. And they've done a lot of good paranoid work along those lines. I'm just not sure the end goal of very strong isolation is even possible on the same machine.
Of course, there are chips that are immune to speculation based vulnerabilities. They're not fast, and they're not very modern, but the Atom D525 in my little netbook has an empty "bugs" field in /proc/cpuinfo, because it's an in-order, non-speculative x86 core. It's just rather glacial.
The ring boundaries of protected mode were never meant as a strong security feature against malice. The documentation of the 286, the first CPU in which they were introduced, is very clear in saying that. It's unfortunate how many assumed otherwise and built an entire industry upon that misunderstanding.