The kernel can pull "tricks" to mitigate speculative execution during context switches. But it can't do anything to prevent a process running on one hyperthread

The kernel can pull "tricks" to mitigate speculative execution during context switches. But it can't do anything to prevent a process running on one hyperthread from using side-channel attacks against another process, or the kernel, or a secure enclave, running on the other hyperthread of the same core. That's right, if you don't have hyperthreading disabled right now, you are technically vulnerable. All the major players have decided that it's not worth the performance cost (or maybe just the feeling of loss of giving up that hyperthreading) for such a niche, difficult-to-exploit vulnerability. A popular idea is to only allow threads of the same process to run on hyperthreads of the same core (or of processes in the same "security domain"). Patches to do this for linux have been floating around for about 2 years, they might have been merged recently, I'm not sure. But the performance cost of the logic that enforces this is greater than the performance benefit of hyperthreading in most cases. IMHO either give up hyperthreading, or give up security against the "MDS" vulnerabilities. I leave it enabled for my gaming system, I think there are bigger problems if attackers have local execution on my system ;)