Probably you're on Win as you mentioned gaming. In Linux you can pass `mitigations=off` as a kernel boot time switch [1]. I did it on my old PC at home and it felt a bit snappier after that. However, I don't have any numbers to quantify it.
On Windows you'll have to delete C:\Windows\System32\mcupdate_GenuineIntel.dll to prevent Windows applying Intel microcode updates. Whatever microcode is in the bios, it will use that.
There are also ways to modify the BIOS to update or downgrade its microcode.
My gaming PC, a Sandy Bridge i7-2600k, has had 20 microcode updates between 2010 to 2019.
The majority were in 2013 until the spectre mitigations came in 2018.
The last bios update for my mobo contains microcode 2 versions behind the spectre updates.
Sorry, I explained it more detail elsewhere in this comments section.
mitigations=off works at the OS kernel level to patch out some expensive aspects of what the kernel can do (possibly in concert with the CPU but driven by the kernel). This issue a microcode change that affects the CPU behavior without any intervention by the kernel, so mitigations=off doesn't help.
On some linux distributions [0] microcode is loaded early during kernel boot. So it's a matter of pinning the package to a previous version. No idea what happens with BIOS/UEFI updates though, although you can roll these back too. Obviously the "proper" way here is to have open source microcode but I can't see that happening anytime soon.
I also have no idea how to do on Windows but disabling those mitigations along with other unnecessary Windows 10 stuff can be done through Chris Titus' debloat program: https://christitus.com/debloat-windows-10/
Can you disable these on a per-process basis? I'm not concerned that my compiler or Blender render is going to side-channel attack whatever other part of the system. Generally there's little overlap between completely untrusted code and code that requires high performance.
Hm... I'm on a host OS with Meltdown mitigations disabled, but I can seemingly run a VM with the mitigations enabled, verified via InSpectre[1]. I guess that's different somehow?
This is because the Spectre/Meltdown can't be patched with microcode updates, the mitigations instead use different kernel mechanisms (KPTI for Meltdown, retpolines for Spectre). If the guest kernel for your VM is using these mitigations it will be protected even if the host has mitigations disabled.
There's a lot of mitigations. Some are microcode, some are kernel/vmm code, some are user space if that process is running untrusted code. Your host probably just isn't running with the normal ISA mitigations, but the microcode installed.
Ha interesting! It was something I wanted to check/try. I'm wondering if it makes the mitigations less effective. Maybe it would drop for some time the even minimal risk of netspectre or such and make cybertight architects lay off my vm hosts...
The main reason for games not to be playable on Linux is the anticheat software used in modern online games. Pretty much everything else will now run perfectly (see protondb.com). Since the commentor you were replying to specified that they played old single player games they would probably be fine with just Linux. Indeed many sufficiently old Windows games are now easier to play on Linux than they are on modern Windows.
[1] https://www.phoronix.com/scan.php?page=news_item&px=Spectre-....