Current mitigations are still largely software based, and frankly, aren't fundamentally any different than the ones proposed just a couple days after 1/3/2018.

Current mitigations are still largely software based, and frankly, aren't fundamentally any different than the ones proposed just a couple days after 1/3/2018. Additionally, current academic literature still hasn't addressed proper silicon mitigations in an all too performant manner-- around 7-15% penalty from what I've seen. While in my opinion, some of these mitigations are provably future-proof (and very genius!), those penalties are still quite heavy. Furthermore, if software yields similar penalties, then why not just stick with software mitigations? Just look at the mitigations list of i9 10900k or Ryzen 9 5950X as used in the article, both released in latter half of 2020. >> itlb_multihit: Not affected + l1tf: Not affected + mds: Not affected + meltdown: Not affected + spec_store_bypass: Mitigation of SSB disabled via prctl and seccomp + spectre_v1: Mitigation of usercopy/swapgs barriers and __user pointer sanitization + spectre_v2: Mitigation of Full AMD retpoline IBPB: conditional IBRS_FW STIBP: always-on RSB filling + srbds: Not affected + tsx_async_abort: Not affected Many of these are still by and large "disable this optimization" and "barriers", all done in software, with the potential exception of EIBRS which just essentially tags the branch predictors (which, in my opinion, they don't do in a particularly effective way, but stay tuned for Research tm). Also Meltdown, which I think is a pretty easy fix, and even Intel agreed [1]. Given typical design --> market time might be ~2 years, designers only had a few months to 1) finish currently pipelined work and 2) work on mitigations. On top of that, given that this is a pretty hard problem, a few months (not even > 1 year IMO) is definitely not enough time. I'd guess that this problem won't be "solved" in a sense for many many more years, much in the same way that the rich history of buffer overflows has been a cat and mouse game for decades, with each mitigation coming with its own tradeoffs and potential performance penalties. On the "Hardware Mitigations" side, think of ARM's pointer authentication-- it's only just now that some pretty nice hardware support has been spawned, decades after buffer overflows were "known". Still though, I personally think some more silicon mitigations will come in the next 2 years. Part of the reason "Pointer Auth" came "decades after buffer overflows" is due to the rise of cloud compute, and security matters much much more to the general public these days. I just mentioned current research generally has penalties on the order of 10%-- While pretty distasteful, it can definitely be (and has been) gradually improved on and is a far step from initial estimates of ~33-50%. [1] https://www.rockpapershotgun.com/2018/01/29/intel-cannon-lake-ice-lake-spectre-meltdown-fix/ https://www.rockpapershotgun.com/2018/01/29/intel-cannon-lak...