Kingsfordweg 151, 1043GR Amsterdam, The Netherlands ● 24/7 support — support@novogara.com
Knowledge base

CPU mitigations

Since 2018 every processor has carried software mitigations for speculative-execution flaws. They are not free, and on a dedicated machine the trade-off is genuinely yours to make.

See what is active

grep . /sys/devices/system/cpu/vulnerabilities/*

Each line names a flaw and says Not affected, Mitigation: ... or Vulnerable. That one command is the whole picture, and it is more reliable than any blog post about your processor generation.

Keep the microcode current — intel-microcode or amd64-microcode — because several mitigations only work with the firmware half in place, and a missing microcode update silently leaves you Vulnerable.

What they cost

It depends almost entirely on how often your workload crosses between userspace and the kernel:

  • Syscall-heavy work — databases, web servers with many small requests, anything doing lots of IO: 5–30%.
  • Compute-bound work that stays in userspace — encoding, rendering, number crunching: close to nothing.
  • Disabling hyperthreading, which some mitigations recommend, costs far more than the mitigations themselves on parallel workloads.

Measure on your own workload rather than trusting a percentage from an article. See benchmarking a new server.

The bare-metal argument

Most of these attacks are about one tenant reading another's memory. On a dedicated server there is no other tenant: the machine is yours, and everything on it is your own code.

So mitigations=off on the kernel command line is a defensible choice for a single-purpose machine running only software you control — a compute node, an encoder, a batch worker.

When it is not defensible

  • You run virtual machines or containers for other people — Proxmox, any hosting of third parties
  • Untrusted code runs on the machine, including a browser engine, a CI runner executing pull requests, or user-supplied scripts
  • The machine processes other people's personal data and you would struggle to explain the decision afterwards
  • You are not sure. The default is on for a reason.

If you do turn them off, write down why and where, so the person who inherits the machine knows it was a decision rather than an oversight. Put it in configuration management with a comment.

A middle course

You can disable individual mitigations instead of all of them — nopti, spectre_v2=off — which lets you remove the one that costs you performance while keeping the rest. Check the result with the same grep above, because the kernel sometimes declines to do what you asked.

On our hardware

We ship current firmware and microcode, and the mitigations are on by default. If you want a machine configured otherwise, that is your call to make on your own server — the operating system is yours, as what unmanaged means explains.


Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base