Check Linux Spectre v2 Mitigations: Step-by-Step

This guide shows you how to verify whether your Linux system has mitigations enabled for the Spectre variant 2 (CVE-2017-5715) CPU vulnerability. You’ll check kernel boot parameters, sysfs files, and compiler-generated code to confirm the status. No special tools are required—just a terminal and standard commands.

What You’ll Need

A Linux system with a terminal (local or SSH).
Root or sudo access to view some kernel files (though most checks work as a normal user).
Basic familiarity with the command line.

Step-by-Step

Check the kernel’s vulnerability status file.
Run the following command to see the current mitigation state for Spectre v2:
```
cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
```
The output will be one of the following:
- Mitigation: Full generic retpoline or similar — mitigations are enabled.
- Mitigation: Vulnerable — no mitigation is active.
- Vulnerable — no mitigation at all.
- Not affected — CPU is not vulnerable (rare).
Inspect kernel boot parameters.
Spectre v2 mitigation can be controlled by the spectre_v2 kernel command-line option. Check the current boot parameters:
```
cat /proc/cmdline
```
Look for spectre_v2= in the output. If it’s absent, the kernel uses its default (which is usually mitigation enabled on modern kernels). If you see spectre_v2=off or nopti, mitigations are disabled.
Verify retpoline support in the kernel.
Retpoline is a key mitigation technique. Check if the kernel was built with retpoline support:
```
grep -i retpoline /proc/config.gz 2>/dev/null || zgrep CONFIG_RETPOLINE /proc/config.gz
```
If the output shows CONFIG_RETPOLINE=y, the kernel supports retpoline. If CONFIG_RETPOLINE=n, it doesn’t, and mitigations are likely incomplete.
Check if the CPU microcode is updated.
Spectre v2 mitigations often require updated microcode. Check the CPU’s microcode version:
```
grep -m1 "microcode" /proc/cpuinfo
```
Compare the version with your CPU vendor’s latest release. An outdated microcode can prevent full mitigation even if the kernel is patched.
Test with a small C program (optional).
If you want to confirm the compiler is generating retpoline sequences, compile a tiny test program:
```
echo 'int main(){return 0;}' > test.c
gcc -o test test.c -fretpoline
objdump -d test | grep -i retpoline
```
If you see retpoline in the disassembly, the compiler is using it. Note that this only checks your compiler, not the kernel itself.
Check dmesg for mitigation messages.
Kernel logs often contain information about Spectre mitigations at boot:
```
dmesg | grep -i spectre
```
Look for lines like Spectre V2 : Mitigation: Full generic retpoline or Spectre V2 : Mitigation: Enhanced IBRS. If you see Vulnerable, mitigations are off.

Common Mistakes

Assuming the sysfs file is the only source. The spectre_v2 file shows the current state, but it may say “Mitigation” even if the CPU microcode is outdated. Always cross-check with dmesg.
Confusing retpoline with IBRS. Retpoline and IBRS are different techniques. The sysfs output may list multiple, but the key is whether at least one is active.
Checking /proc/cmdline on a system with a bootloader that overrides it. Some bootloaders (like GRUB) may add or remove parameters. Always check the actual kernel command line, not just the bootloader config.
Ignoring the CPU vendor. Intel and AMD have different mitigation requirements. A generic “retpoline” might be sufficient for one but not the other.

Tips

Keep your kernel and microcode updated. Most distributions backport security fixes, so a recent kernel is more likely to have mitigations enabled.
If you’re on a virtual machine, check the host’s configuration too. The hypervisor may need to expose certain CPU features for guest mitigations to work.
Use lscpu to see if your CPU supports IBRS or IBPB. If it does, the kernel can use those features.
For a quick summary, run grep -r . /sys/devices/system/cpu/vulnerabilities/ to see all vulnerability statuses at once.

Troubleshooting

If the sysfs file says “Vulnerable”:

Check if you’re booting with spectre_v2=off in the kernel command line. Remove it from your bootloader configuration (e.g., /etc/default/grub on Debian/Ubuntu, then run update-grub).
Ensure your kernel is up to date. Run uname -r and compare with your distribution’s latest kernel package.
Update your system’s BIOS/UEFI and CPU microcode. On many systems, this is done via the motherboard vendor or the distribution’s linux-firmware package.

If the sysfs file says “Mitigation” but dmesg shows errors:

Check for kernel messages like “Spectre V2 : Mitigation: Vulnerable” which override the sysfs entry. This can happen if the CPU doesn’t support required features.
Verify that the CPU microcode is actually loaded: dmesg | grep microcode. If it says “microcode: CPU0 sig=0x…, pf=0x…, revision=0x0”, the update failed.

If you can’t read /sys/devices/system/cpu/vulnerabilities/spectre_v2:

This file might not exist on very old kernels (pre-4.15). Upgrade your kernel or use dmesg and /proc/cpuinfo as alternatives.
If you get “Permission denied”, try with sudo: sudo cat /sys/devices/system/cpu/vulnerabilities/spectre_v2.

Frequently Asked Questions

What does “Mitigation: Full generic retpoline” mean?

It means the kernel is using retpoline, a software workaround that prevents the speculative execution used by Spectre v2. “Full” indicates it’s applied to all kernel code paths.

Is Spectre v2 mitigation enabled by default on modern Linux?

Yes, most mainstream distributions enable it by default in their kernel configurations, unless the hardware doesn’t support it or the user explicitly disables it.

Can I disable Spectre v2 mitigation for better performance?

Yes, you can add spectre_v2=off to the kernel command line, but this leaves your system vulnerable to a known CPU attack. It’s not recommended unless you fully trust your workload and environment.

Does my CPU need to support IBRS for mitigation to work?

No, retpoline works on most CPUs. IBRS is an alternative hardware-based mitigation. The kernel will choose the best available option based on CPU features.

Why does my sysfs file say “Mitigation: Vulnerable”?

This is contradictory but can happen when the kernel knows about the vulnerability but can’t apply any mitigation due to missing CPU features or microcode. Check dmesg for more details.

How often should I check this?

After every kernel or microcode update, it’s wise to verify. Also, if you change hardware or BIOS settings, re-check.

General steps for current mainstream versions; menus can differ by device and version. See the disclaimer or report an error.

More in this bed

The whole Tech How-To bed →