Mdthbs

On a Debian Stretch and testing/Buster system with a current kernel and installed microcode I still see meltdown and spectre listed as bugs in /proc/cpuinfo.

However, running the spectre-meltdown-checker shows not vulnerable.

So I'm wondering what /proc/cpuinfo does show. Are these just the vulnerabilities for this cpu and will those always be listed despite having a patched system?

The intent of the “bugs” field in /proc/cpuinfo is described in the commit message which introduced it:

x86/cpufeature: Add bug flags to /proc/cpuinfo

Dump the flags which denote we have detected and/or have applied bug
workarounds to the CPU we're executing on, in a similar manner to the
feature flags.

The advantage is that those are not accumulating over time like the CPU
features.

Previously, hardware bugs that the kernel detected were listed as separate features (e.g. the infamous F00F bug, which has its own f00f_bug entry in /proc/cpuinfo on 32-bit x86 systems). The “bugs” entry was introduced to hold these in a single feature going forwards, in the same style as x86 CPU flags.

As far as what the entries mean in practice, as you can see in the message, all that’s guaranteed is that the kernel detected a hardware bug. You’ll need to look elsewhere (boot messages, or specific /proc entries or /sys entries such as the files in /sys/devices/system/cpu/vulnerabilities/) to determine whether the issues are dealt with.

The usefulness of the “bugs” entries is limited in two ways. The first is that true negatives can’t be distinguished from unknowns: if the field doesn’t specify “cpu_meltdown”, you can’t know (just from the field) whether that means that the kernel doesn’t know about Meltdown, or that your CPU isn’t affected by Meltdown. The second is that the detection can be too simplistic; it errs on the side of caution, so it might report that your CPU is vulnerable when it isn’t. Because the “detection” is table-driven, its accuracy depends on which version of the kernel you’re running.

In the case of Meltdown and Spectre bugs, the detection process which feeds the values in /proc/cpuinfo works as follows, on x86:

• if the CPU doesn’t perform any speculation (486-class, some Pentium-class, some Atoms), it’s not flagged as affected by Meltdown or Spectre;


• all remaining CPUs are flagged as affected by Spectre variants 1 and 2 (regardless of microcode revision etc.);


• if the CPU isn’t listed as not susceptible to speculative store bypass, if its microcode doesn’t claim to mitigate SSB, and if the CPU doesn’t claim to mitigate SSB, then it’s flagged as affected by SSB;


• if the CPU isn’t listed as not susceptible to Meltdown (AMD), and if its microcode doesn’t claim to mitigate Meltdown, then it’s flagged as affected by Meltdown.

The Meltdown/Spectre vulnerabilities are on the CPU chipset design/architecture, and short of buying new future hardware, the patches are a nice illusion of security over the long term. New methods of exploiting the flaws might surface over time that are able to bypass the current patches.

In short, the current software patches/microcode mitigate the problems against known methods of Spectre/Meltdown family of exploits, but do not solve the underlying CPU design problems that allow them in the first place. The affected (several generations) of CPUs have not stopped being vulnerable in the long run (and most probably never will).

However, as @Gilles correctly states, having that warning does not mean the current known exploits Spectre/Meltdown methods will work; they won't work if the patches are installed.

In the case mentioned in the question, the kernel is only checking for the CPU models known to be affected by Spectre/Meltdown (all x86 CPUs for now if we are talking only about x86), and hence the cpu-insecure still being listed in the bug section/line in /proc/cpuinfo.

Go check your /proc/cpuinfo. It will contain cpu_insecure if your
kernel has the KPTI patch

I've found that the KPTI patch has this piece of code:

   /* Assume for now that ALL x86 CPUs are insecure */

   setup_force_cpu_bug(X86_BUG_CPU_INSECURE);

And after the kernel update, you get:

bugs      : cpu_insecure

PS. There was already a round of updates for a new method for exploiting the Spectre/Meltdown "bugs". It probably won't be the last time.