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