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. 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 usefulness of the “bugs” entries is limited in two ways. 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 “bugs” entry was introduced to hold these in a single feature going forwards, in the same style as x86 CPU flags.Īs 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. the infamous F00F bug, which has its own f00f_bug entry in /proc/cpuinfo on 32-bit x86 systems). Previously, hardware bugs that the kernel detected were listed as separate features ( e.g. The advantage is that those are not accumulating over time like the CPU Workarounds to the CPU we're executing on, in a similar manner to the X86/cpufeature: Add bug flags to /proc/cpuinfoĭump the flags which denote we have detected and/or have applied bug The intent of the “bugs” field in /proc/cpuinfo is described in the commit message which introduced it:
0 Comments
Leave a Reply. |