As reported by Phoronix, Brendan Jackman, a Google engineer, issued a patch that introduces a new Linux boot parameter, force_cpu_bug=. When enabled, the kernel assumes the CPU is affected by a bug such as Spectre, Meltdown, or Retbleed and reacts accordingly.

But why would you want to do this, especially when your machine isn't affected? According to Jackman's post on the force_cpu_bug patch, "It's a bit unfortunate that we have to do this by bug instead of by mitigation. However, we don't have clear identifiers for the mitigations that we do, so I don't think it's practical to do better here than ‘you can pretend you're on a vulnerable CPU – now go and read the docs for the per-vuln cmdline params to figure out how to run the mitigation you want.’"

But why would anyone want to run this command-line boot option, especially when it's very likely to prevent the machine in question from achieving its full potential? Jackman says (in his patch), "This can be handy for mundane reasons like ‘I wanna debug this on the machine that quickly.’”

He continues to say that it can also be helpful for research, "while some mitigations are focussed on individual vulns and uarches, others are fairly general, and it's strategically useful to have an idea how they'd perform on systems where we don't currently need them."

Jackman's patch has to go through the usual process, during which it will be determined if it is of use for mainline release. You can view Jackman's original patch here.