Last year a patch was raised for the Linux kernel that would report outdated CPU microcode versions as a security vulnerability. With Intel routinely issuing new CPU microcode updates for security vulnerabilities and addressing other functional issues, the Linux kernel would begin warning users when recognizing that outdated CPU microcode is deployed for a given processor. That patch has now been queued into a tip/tip.git branch and thus looking like it will be submitted for the upcoming Linux 6.16 kernel cycle.
Since that original patch proposal was made last year, there’s been perfect examples with new CPU microcode in November for two security advisories and in February were CPU microcode updates for five new security issues. That’s just the past few months and if you’ve been a longtime reader, you’re well aware of the CPU security issues that have come about for all vendors in recent years and are commonly seeing mitigations applied via microcode updates.
Queued this afternoon into the tip/tip.git’s x86/microcode branch is the patch for reporting outdated Intel CPU microcode versions to users.
Due to the likelihood that updated microcode contains security fixes and/or functionality issues resolved, when a CPU is detected as running outdated microcode it will be reported via /sys/devices/system/cpu/vulnerabilities/old_microcode. This is in the same sysfs directory where other CPU security vulnerabilities are reported and thus easy for collection. Ensuring you are on the latest CPU microcode is also important when debugging Linux kernel issues.
Besides reporting the old microcode issue via sysfs, recognizing outdated CPU microcode will also taint the running Linux kernel via the “TAINT_CPU_OUT_OF_SPEC” flag.
This recognizing of outdated Intel CPU microcode versions isn’t trivial and relies on a static list of different CPU microcode versions for each CPU family / model / steppings. Thus with time this list will need to be updated and maintained by Intel engineers to properly reflect the latest microcode versions released.
Now that this patch is queued via a tip/tip.git x86 branch, this will more than likely be submitted for the Linux 6.16 merge window in just over one month, barring any last minute objections from being raised with this reporting.
