Depending on your risk tolerance, mostly yes: 1) You can disable kPTI without opening the door to Meltdown (which let you directly read kernel memory as usermo

Depending on your risk tolerance, mostly yes: 1) You can disable kPTI without opening the door to Meltdown (which let you directly read kernel memory as usermode). 2) You can re-enable hyperthreading while allowing virtualization (VMs) without obvious issues (l1tf used to allow users to read kernel memory through VMs). I don't know which, if any, distros do this, but it's the prudent thing to do if you care deeply about security. (Linux may have the scheduling fixes by now that also fix this, but I honestly haven't followed them, and they didn't have them in like November when I last checked.) Others: 1) I'm honestly unsure if you can recompile kernels without "retpoline", but it's not a super big perf impact anyway, at least not compared to those two mitigations. 2) I'm not super familiar with the "MDS" vulnerabilities, so I don't know how bad the perf impact of their mitigations are, or how bad their impact is. 3) There's some TSX issues, which I'm also unfamiliar with, also probably don't matter much perf wise. If you are paranoid, or have a multi-tenant machine, I'd still leave these on (and I'd particularly leave hyper-threading off, even on AMD), since we haven't stopped seeing new side channels. Hyper-threading is basically asking for problems on multi-tenant machines. Honestly, if your machine is not multi-tenant, and you can tolerate some risk (e.g. you don't care if anyone sitting at your machine can read all of RAM, including potential malware), I'd just disable all this stuff. Unless you've run into particular hiccups (you compile linux kernels all day and you need the extra cores), I wouldn't do it.