The microcode from 3.20180108.0+really20170707ubuntu17.10.1:
[parent]: dmesg -t | grep -i microcode
microcode: microcode updated early to revision 0x29, date = 2013-06-12
microcode: sig=0x206a7, pf=0x2, revision=0x29
microcode: Microcode Update Driver: v2.2.
If Intel were fixing this in microcode in 2013 then there's something about which they haven't been letting on. This is an Intel(R) Core(TM) i5-2500K(family 6, model 42, stepping 7).
Similarly running this on my laptop (Intel(R) Core(TM) i5-4330M with microcode from that same deb package (microcode revision 0x22, date = 2017-01-27) reports that it is not vulnerable.
Both of these systems hang using the new ("current") microcode (their reports only differs in the CPU type).
One difference I can see on the report for my system running 18.04beta which is OK with the new microcode is that it says NO "Kernel has the Red Hat/Ubuntu patch", but the two systems above, which both suffer with the new microcode, have YES.
> Define *old* microcode
The microcode from 3.20180108. 0+really2017070 7ubuntu17. 10.1:
[parent]: dmesg -t | grep -i microcode
microcode: microcode updated early to revision 0x29, date = 2013-06-12
microcode: sig=0x206a7, pf=0x2, revision=0x29
microcode: Microcode Update Driver: v2.2.
If Intel were fixing this in microcode in 2013 then there's something about which they haven't been letting on. This is an Intel(R) Core(TM) i5-2500K(family 6, model 42, stepping 7).
Similarly running this on my laptop (Intel(R) Core(TM) i5-4330M with microcode from that same deb package (microcode revision 0x22, date = 2017-01-27) reports that it is not vulnerable.
Both of these systems hang using the new ("current") microcode (their reports only differs in the CPU type).
One difference I can see on the report for my system running 18.04beta which is OK with the new microcode is that it says NO "Kernel has the Red Hat/Ubuntu patch", but the two systems above, which both suffer with the new microcode, have YES.