On Tue, 28 Aug 2018, Thomas Voegtle wrote:
Kernel 4.18.5 with old microcode:
[ 0.000000] microcode: microcode updated early to revision 0x2c, date =
Kernel 4.18.5 with new microcode (microcode-20180807.tgz), same config:
[ 0.000000] microcode: microcode updated early to revision 0x32, date =
This happens with 4.14.y and 4.9.y as well.
The same with ssb:
old microcode: spec_store_bypass:Vulnerable
new microcode: spec_store_bypass:Not affected
Is this intentional behavior? I have never seen this on other CPUs, such
as Gemini Lake or Baytrail, Haswell etc.
Looks like the micro code update has the relevant bits set in the
IA32_ARCH_CAPABILITIES MSR, which tell the kernel that the CPU is not
vulnerable. So it seems Intel was able to mitigate the mess in micro code
for this particular CPU model.