still have ucode 0x12: are new versions in the pipeline? Do I just wait?

[alan12345678]

Hope you don't mind me just asking. Had a TON of boot config issues with rEFInd that I never had with Grub. Grub would just see my /boot/inte-ucode.img and pick it up for loading, so I've never had to look at this issue until now.

Kernel panics every time I try to run something explicitly in rEFInd like

initrd=/boot/intel-ucode.img

and now I've just worked out that despite having the latest version downloaded (20191115-3) it doesn't cover my processor according to iucode_tool. It's an Intel, 06-0c-03 and on Microsoft's last update they've included this in their Windows updates. I did try grabbing that standalone, but it's all manifests and stuff, nothing that looked like binaries I could extract.

cat /proc/cpuinfo is showing cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit so I'm hoping that's nothing I need to be worrying about :)

[esyr-rh]

Are you sure your CPU model ID is 0xc and not 0x3c/0x4c? I don't see any CPU models having this CPU model ID.

[alan12345678]

Apologies, I was interpolating from the output. Here's two versions, according to output:

processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i5-4460 CPU @ 3.20GHz stepping : 3 microcode : 0x12 cpu MHz : 2671.108 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13

or

CPU 0: vendor_id = "GenuineIntel" version information (1/eax): processor type = primary processor (0) family = 0x6 (6) model = 0xc (12) stepping id = 0x3 (3) extended family = 0x0 (0) extended model = 0x3 (3) (family synth) = 0x6 (6) (model synth) = 0x3c (60) (simple synth) = Intel Core (unknown type) (Haswell C0) {Haswell}, 22nm miscellaneous (1/ebx): process local APIC physical ID = 0x0 (0) cpu count = 0x10 (16) CLFLUSH line size = 0x8 (8) brand index = 0x0 (0) brand id = 0x00 (0): unknown feature information (1/edx):

It's listed as an i5-4460, but has an onboard Xeon E3-1200 chip.

[esyr-rh]

microcode-2019115 release contains revision 0x27 of the 06-3c-03 microcode: microcode bundle 1: microcode-20191115/intel-ucode/06-3c-03 001/001: sig 0x000306c3, pf_mask 0x32, 2019-02-26, rev 0x0027, size 23552 CPUMicrocodes repository contains revision 0x28 of the 06-3c-03 microcode: microcode bundle 1: cpu306C3_plat32_ver00000028_2019-11-12_PRD_DBD4CFD1.bin 001/001: sig 0x000306c3, pf_mask 0x32, 2019-11-12, rev 0x0028, size 23552 Revision 0x12 is certainly quite old.

[alan12345678]

Yes it is. So please tell me, if you'd be kind enough: from what little I understand of all this (I'm someone who only learns as he comes across issues. I'm not from an engineering background, thus have just spent hours reading wiki's etc)

If I run mkinitcpio with the standard preset, the resulting ucode.img is the one in I just mentioned i.e. that is picked up as being revision 0x12.

So, if your package is up to date (of course) and I DO have it installed (I do), then what's going on? I thought this was very curious.

I don't understand much about compiling a kernel, but I did go as far as to boot from a live install, -chroot into the mounted dirs, and then compile from there. But what I get is intel-ucode.img that fails.

Presumably I need to alter some config file, or add some flag to something?

[esyr-rh]

What distribution are you using? Generally (in newer distributions with newer kernels), early microcode is placed (by mkinitramfs/mkinitrd/dracut/etc) in a separate cpio archive that is concatenated with the actual initrd. There's also a late (request_firmware()-based) microcode loading mechanism (which doesn't go well with some mitigations, but still) that can be triggered via /sys/devices/system/cpu/microcode/reload file. But all that usually handled transparently by the distribution-provided infrastructure and there's rarely a need to supply microcode files manually.

[alan12345678]

First up MANY many thanks for helping with this! It's not mere geekiness on my part - I've noticed a few odd issues with this computer that might be down to this, to say nothing of the fact that I don't currently have up to date microcode.

I'm using Arch Linux. That uses mkinitcpio by default. My hooks listed in the .conf file look okay, there's no suggestion I need to add anything else from what's available.

There are several reasons I came to this question - which is by way of answering your own above:

I never had this issue at all when using Grub. Just the other day I set up on a new (secondhand) machine that has UEFI. And simply because I didn't want anything but GPT layout, had settled on using rEFInd as my boot loader.

That works the same way grub did - you can set

initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux.img and away you go. It's been that way ever since I've been using Arch.

But several questions now arise. I accept that perhaps it "should" concatenate your firmware updates, but to test I simply deleted the intel-ucode.img sitting in /boot and ran mkinitcpio again, with the default presets (I've got autodetect and modconf hooks) and once it had finished, there was a new copy of intel-ucode.img sitting in /boot so I rather figured this is the way Arch is designed to work! And again, this was always the case with grub2 - that file was always there, and grub just picked it up during grub-mkconfig -o /boot/grub/grub.cfg and there was never an issue, and nothing I needed to tweak.

So things are 'regular' insofar as once again the kernel compile creates this separate little ucode image file, but once again what is so curious is if I run that (commonly found) script bdstar -0xf etc, that pipes the output into iucode_tool it keeps telling me that there's no files in there containing anything useful. Likewise if I simply run the -L option, it again says no.

So I would appear to be in this odd situation wherein I need to have intel-ucode.img sitting in the boot dir alongside vmlinuz-linux and initramfs-linux.img all of which get loaded, but for whatever reason your latest package - containing the relevant updates - is nowhere to be seen. I run # dmesg | grep microcode and it gives me this:

[ 0.033339] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later) [ 0.107897] MDS: Vulnerable: Clear CPU buffers attempted, no microcode [ 0.617123] microcode: sig=0x306c3, pf=0x2, revision=0x12 [ 0.617280] microcode: Microcode Update Driver: v2.2.

[alan12345678]

Thanks again. Your comments have led me onto the Arch forum, and from there I'm narrowing things down. So, clearly nothing from here - thanks again for your help. Issue not solved, but I'm on the trail.

[hmh]

FWLIW, it is best to use iucode_tool -L -tr /boot/intel-ucode.img, if you want to see what microcode updates are present in that early-initramfs data file.

[alan12345678]

thank you for that.

I think the issue finally turned out to be: I built from ground up Arch on UEFI. Chose an EFI boot manager, had NO idea at the time that the old (it was) and out of date ucode was not being loaded (due to bug). So I was running a system for days that was exposed to the Spectre variants plus other stuff.

I finally reverted to Grub, and (while the two aren't necessarily connected) found that when I finally got to regenerate my kernel (for the umpteenth time) FINALLY it spat out a correct ucode.img, and which Grub then just picked up.

So, thanks again - I do appreciate getting help when things go wrong (we all know how that feels, when it seems something can't be fixed). System now stable and performing as expected. I learned a ton more stuff in the process :)