Everyone probably knows this already but:
in /lib/src/Linux*/Documentation there exist several .txt files addressing microcode.
just in case
I sometimes forget about the obvious.
HTH
John

1 members found this post helpful.

I have an HP 8460P laptop from around 2011. I upgraded it to the newest bios which was released in April 2017. When I checked the microcode from the current SBo package the microcode was dated 2013. I checked the revisions numbers from the running microcode to the newest one in the latest package and they are different, however wouldn't it stand to reason that the last bios revision from 2017 would have the latest microcode considering, at least according to intel, its from 2013?

Disregard, I got this sorted out.

This method didn't work for me for some odd reason.
The only way I could get it working on my system

1. Install iucode_tool

2. Install intel-microcode

3. Delete /boot/intel-ucode.cpio which is 1.6 MB because iucode_tool create the full package instead of an intel-ucode.cpio 74.8 KB which is for my system only.

4. 5. Backup intel-ucode.cpio, because after removing iucode_tool + intel-microcode (which is not needed once the file is created) it will remove intel-ucode.cpio

6. Copy it back to /boot/

7. Run this command after I update my Kernel Once you have a copy of intel-ucode.cpio in the /boot directory for your updated microcode update, there is really only one step and that is running the command cat intel-ucode.cpio initrd_4.14.13-smp.gz > /home/problemchyld/Desktop/initrd_4.14.13-smp.gz
iucode_tool + intel-microcode doesn't serve a purpose once you get the necessary file. These are my geekish ways.

I would not recommend concatenating 2 files onto a file that was concatenated.

Look:
Try this:

2 members found this post helpful.

hmm, it seems that Intel has gone back to the 20171117 as the latest available microcode. There is no explanation to why, but it appears the 2018 version has vanished.

1 members found this post helpful.

The reason for vanishing of the 2018 release is that Intel royally messed with.

Long story short, the brand new microcodes produced many hangups and unexpected reboots.

Thanks. Well it looks like Intel with it's swift response shot it self in the foot and had to pull back the microcode. The latest as of 1/27/2018 is they are working with OEM's (supposedly for CPU's in past five years) on proper microcode rollout and relying on Microsoft patch for Win7, Win8 and Win10. ALL other OS's are apparently left in the dustbin to figure out what to do. This is another reason I wish I had my older AMD Athlon system functioning, instead of this Pentium D. Time to go looking for a new AMD based system and leave this whole Intel microcode install idea in the dustbin where it should have stayed.

BTW I have successfully loaded the latest kernel patches from Pat and understand why he was slow to release them now. kernel 4.4.112 was also built and loaded without issues using the methods of keefaz and kjhambrick specifically...after building a proper initrd with the command_generator for the downloaded kernel.
modify the /etc/lilo to new stanza with /boot/initrd-custom-4.4.112_ucode.gz, then run lilo and then reboot.

1 members found this post helpful.

Your effort on this thread is admirable and the result helpful for all of us, so please don't get demotivated. Intel messing things up with their hurry for a response/patch is indeed a show stopper, but on the other hand they're still pushing to resolve it and they were the first to try to get a microcode fix for these vulnerabilities. If you do work you also make mistakes, it's easier to do nothing, no mistakes. AMD is still cooking and leaving the OS folks to patch the vulnerabilities ATM, while their " starting this week" microcode updates are still nowhere to be found:
https://www.amd.com/en/corporate/speculative-execution
"AMD will make optional microcode updates available to our customers and partners for Ryzen and EPYC processors starting this week."
I'm more concerned about the time (and competencies - armies of engineers) these HW companies had available to come up with a fix and properly test it, given the fact that the vulnerabilities were already known internally for half a year. Even the American House of Representatives is curious about this fact now (sending love letters to all big American companies):
https://energycommerce.house.gov/wp-...re-Letters.pdf

3 members found this post helpful.

Intel just released a document covering the platforms that will receive a microcode update and the status of the microcode development, however the release dates are still unknown:
https://newsroom.intel.com/wp-conten...e-guidance.pdf

Just wanted to add, that the updates that are labeled as "Production" (green) appear to be already available through the OEM channels/partners.

>EDIT
The article from where I took the pdf link in the first place was in German and now I found the official source at Intel (more details and the OEM Microcode availability):
https://newsroom.intel.com/news/secu...mware-updates/

3 members found this post helpful.

Thanks for the updated list. It looks like my CPU x0f47, formerly known as Smithfield isn't on the list, so probably will not ever get an update. But I still appreciate the information, as I am sure others are. Cheers

I recalled your frustration with your CPU not being on the Intel's list and considered to update this long (and almost old, but still actual) thread. Yesterday I got a microcode update from DELL on an older Haswell i3 Inspiron Laptop, laptop model that was not to be found (& still isn't) in DELL's list of computer models that are to receive a microcode update for the MeltDown&Spectre mitigation. It was a surprise for me! I hope that this will be also your case and Intel will get your CPU patched in the end, furthermore they might also release a general microcode update file for Linux after this vendors only (OEM) phase will come out positive. Thus, this thread will become actual again.

There was an interesting aspect I've noticed after the microcode (BIOS) update, the spectre-meltdown-checker.sh version 0.35 script reported that my microcode has the mitigation implemented but the system is still vulnerable (removed the CPU&Laptop model out of privacy concerns):

- Kernel only mitigation:
https://s14.postimg.org/eq0egkc7l/kernel-only.png
- Kernel plus microcode (BIOS) mitigation:
https://s14.postimg.org/uo946q90h/ke...-microcode.png
- DELL BIOS (microcode) Info:
https://s14.postimg.org/hk3ju3m4h/DE...-microcode.png

I forgot to run some benchmarks before and after the microcode update in order to check the performance impact, but after the microcode update I just loaded win7 and played a shooter game that I know was almost killing this laptop before (it has a weak Nvidia Card). I couldn't observe any performance drops, nothing noticeable.

1 members found this post helpful.

That's not true. Your image "Kernel plus microcode (BIOS) mitigation: https://s14.postimg.org/uo946q90h/ke...-microcode.png" clearly says STATUS: NOT VULNERABLE on all three variants.

If you're worried about "CPU vulnerability to the three speculative execution attacks variants", that is the status of your raw hardware CPU without the fixes.

You can get accurate information on Intel microcode directly from Intel instead of Dell. Here is the latest status (26th February): https://newsroom.intel.com/wp-conten...e-guidance.pdf. But even in the current circumstances, Intel has apparently not yet made its latest microcode available to the Linux community. Thankfully, with the possible exception of Skylake, Intel microcode updates are not required.

2 members found this post helpful.

You're right in all your points:
https://s13.postimg.org/8nm29l4sn/no...ocode-only.png
- kernel focusing only, piece of %$^$ that script is - I just used it as per "monkey see monkey do", noticed it floating around here on the forum and said to myself I need to have that banana too. Got it now, checked it and removed it right away.

What was the point BTW? My point with the update on this thread was to confirm that Intel is delivering the microcode updates through the vendors, that I got this microcode update through Dell (BIOS is signed 30 January 2018, that's weird) on an old (4 years) system that doesn't appear listed to receive a microcode update by Dell (the manufacturer), system that Intel has nothing to do directly with. Thanks for reconfirming the link I presented some posts above, I'm always checking that document in parallel with the web support sections at the HW vendors after BIOS updates And, indeed thankfully the kernel folks gave us a fix before the CPU manufacturers did, actually Intel tried and failed in their 1st attempt.

Thank you for the updates. I also want to report that if you are using the kernel updates from Pat that you can build your mkinitrd after loading the new kernel by simply inserting in you mkinitrd string -P /boot/intel-ucode.cpio which will then add the intel-ucode.cpio built from the earlier mentioned tools into your initrd. Ii place this just before the -o {initrd-output-filename.gz}. This simplifies the steps listed earlier.

I do hope Intel will update the microcode for my old 0xf47, Cheers

1 members found this post helpful.