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.

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.

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

This.

After seeing how Intel have responded to recent events, I feel reassured by the fact that the mitigations can be at the software level, rather than having to rely on opaque microcode updates by Intel.

Speaking of Skylake, Intel has started to deploy the microcode update for the 6th Generation Skylake Processors thought their trusted partner Microsoft:
https://support.microsoft.com/en-us/...rocode-updates
https://www.catalog.update.microsoft...px?q=KB4090007

According to this article in German (the only one more detailed I could find ATM), the microcode update is the same as it was in the Linux Microcode Update file that Intel pulled back on the 22th of January 2018. It is written in the article that Intel only rechecked the microcode and didn't modify it:
https://www.heise.de/security/meldun...e-3985133.html

What should I choose?
1. UEFI update from motherboard manufacturer (when it comes);
or
2. Linux processor microcode update from Intel
https://downloadcenter.intel.com/download/27591?v=t

Hello,

Just noticed that latest intel microcode (20180312) includes an update for my "old" Xeon e3-1230 v2 (ivy-bridge) :

--
SeB

teoberi, it's not important.
You can install both.
But if you have a recent kernel, you don't need any microcode update.
The fixes already in the kernel are better and they don't use the microcode stuff.

Recent kernels do retpolines, but I thought there were some edge cases with Skylake that required the IBPB/IBRS features to be fully protected: https://lwn.net/Articles/743019/

But most of this stuff is way over my head so it's possible I missed or misunderstood something somewhere along the way.


To be honest, I'm starting to wonder whether it's worth turning off the mitigations for performance reasons since I'm not in the habit of running untrusted code anyway and outside of proof of concepts I've not seen any mention of real-world exploitation of these vulnerabilities. The only reason I haven't done so already are concerns about javascript in the browser (I disable it as a general rule, but some sites just won't work without it).

All --

I am with GazL on these issues ... dazed and confuzed :)

Is the Intel® Management Engine Critical Firmware Update (Intel-SA-00086) mitigated in the Kernel ?

My understanding of that particular bug is that it affects the Intel Management Engine which is 'below' the OS' in the stack and it requires a BIOS update from your MoBo Vendor ?

Or is the IME Mitigation Code included in the recent kernel-firmware Packages ?

This is a link to the Intel-SA-00086 Detection Tool Page.

Thanks !

-- kjh

These are the results of running the tool on my Work Laptop:

This tool might give you a better understanding of what is vulnerable on your system regarding spectre and meltdown.

spectre-meltdown-checker

My system isn't vulnerable in either tool:

Loaded the new microcode for my x99 / Haswell-E CPU last night, but looks like Asrock rolled out new bios updates with the microcode today, so I was able to ditch the microcode initrd and just updated to the new bios. If I am reading the specter-meltdown-checker correctly it looks like I am not-vulnerable across the board?

I read this morning:
https://access.redhat.com/articles/3311301

In the section "Architectural Defaults" appears

A kernel patch is comming!
https://patchwork.kernel.org/patch/10279661/

It's already in the last kernel (4.14.27).

AFAIK the Intel AMT (ME) update operations are not supported under Linux (Slackware) and its firmware can only be updated either through the vendor's BIOS releases, for older systems/architectures or, more recently, through the vendor's Windows "chipset firmware" updates.
It has got even worse, since you can get these vendor's "firmware" update only under Windows 10 - I have a laptop that came with Win7 and on the support site I only get a Intel AMT patch (firmware update) that was designed/is working only under Win10 :)

Check this for references and some useful links:
https://www.linuxquestions.org/quest...00/page48.html
This looks to be a useful HowTo for updating the firmware (haven't tested it yet):
https://www.flamingspork.com/blog/20...ndows-install/
Some info on the HW & firmware:
https://en.wikipedia.org/wiki/Intel_...ngine#Hardware

For any interested
This update in BLFS_SVN this morning
Released by Beyond Linux from Scratch changelog.
john

SO I'm checking it now. According to the search function on Intel.com there is an update for my Smithfield xof47 processor. I'll report back after I have it loaded and testing for a while.

https://downloadcenter.intel.com/dow...?product=27512

For Intel® Pentium® D Processor 820 (2M Cache, 2.80 GHz, 800 MHz FSB)
Linux* Processor Microcode Data File
Version: 20180312 (Latest) Date: 3/12/2018

Not to say that there is not an update for your specific processor, but the Intel microcode download lists virtually every processor that they have ever made. Just because your processor is listed does not mean that there is a microcode update for your specific processor.

Just for example, I have many Intel processors and they are all listed in there and there are microcode updates for them but the microcode update for my processors are quite old and haven't been updated recently.

The only way to know if your specific processor has had a microcode update is to like kjhambrick says in the next post and check the date.

I highly doubt that the Pentium D 820's have gotten an update since the previous release.

bamunds --

I updated the intel-microcode SBo Package on four Boxes yesterday:

1. rebuilt and upgradepkg'd intel-microcode
2. rebuilt my initrd files
3. reran lilo
4. rebooted

Two-of-four CPUs got a new microcode file:

This is 'bupbox' running Slackware64 14.2:

This is 'sam' running Slackware64-current:

My Skylake ( i7 6700k ) is still running the 2017-11-16 version

The Zotac ZBox BI325 ( Celeron N3160 ) does not show date for the microcode file, but the revision was the same before and after the intel-microcode update.

HTH and Good Luck with your CPU !

-- kjh

My guess is that everything skylake and before is "on their own". At least as of now, and probably will be that way in future updates. There may be some backporting to skylake and *maybe* some earlier in the future, but I wouldn't hold my breath.

Skaendo --

Skylake does seem to be a problem-CPU but there were definitely updates in the Intel 2018-03-12 file for some older CPUs.

I checked the Microcode Revisions before and after installing 2018-03-12:

Third Gen i5-3210M :
And Fourth Gen i3-4150 :
HTH

-- kjh

i5-2400, Sandy Bridge from 2011 got a new microcode. On Linux 4.15.10:

Yeah, at least according to that script. I am no expert on the topic. I assume the people working on that script know a lot more about it all than I do, which is why I trust it to be accurate.

I updated my microcode to version 20180312.
Before:
After:
The rest of my systems in the house are varying versions of the Raspberry Pi, which was announced as not vulnerable to any of this. Now to look at the one family Windows 8.1 machine...

From what I've heard, every Intel CPU from at least the last 2 decades is affected.

I would bet that they are cherry picking which ones get updates by many factors like how easy the fix is for a model, market share, etc. But I do not know *for sure*. So take it with a grain of salt.

I wouldn't doubt that skylake is getting updates, and earlier models are as well, but if you think that every processor that Intel has made is going to get a microcode update, don't hold your breath.

They may very well update the microcode for every single processor that they've ever made (I doubt it), but thinking that the current release has a update for every/any specific model is not wise. It is best to check like you have because not every model gets updated with every release.

"A false sense of security is worse than no security at all."

There's no need to guess.
https://newsroom.intel.com/wp-conten...e-guidance.pdf (March 6 2018)
I think the oldest update currently planned is possibly 'Penryn/QC'.

YAY! That means my X9000 might get a update! :)

@55020
Thanks for that link.

After updating intel-microcode scripts and building the latest /lib/firmware/intel-microcode/
shows that my particular CPU and actually all the Smithfield CPU's are still not getting any updates.
Glad the spectre/meltdown is already being addressed by the Linux Kernel dev's.

Here is my latest process decisions for How-To Update Intel Microcode
The following requires that both intel_tools and intel-microcode are already loaded.
So the method I'm adopting gong forward is to each month during my security updates will be to follow:
1. download latest Intel.com microcode for Linux to my downloads folder.
2. locally re-build the /lib/firmware using intel-microcode.SlackBuild (correctly modified for latest download file name)
3. check the /lib/firmware/intel-ucode/ directory with the above command and see if my CPU is updated.
4. if updated then there are two possible paths.
4a In combination with kernel update: download latest kernel and use the flag parameter suggestions from BratPit
in post #15 when running "make menuconfig" to simply get the update for my CPU only added during the bzImage build time.
4b Not in combination with a kernel udpate: simply use the following command to write a new intel-ucode.cpio
for only my CPU. This will also keep my system from getting a large /intel-ucode.cpio file in /boot.
5. Next follow the steps for
a) Building a Kernel from Source or
b) the steps for concatenated as stated in post #94
cat intel-ucode.cpio initrd_4.14.13-smp.gz > initrd_4.14.13_ucode-smp.gz
and don't forget to fix both the lilo.conf stanza's and rerun lilo before a reboot.

PS. 4.4.121 has a x86/spectre and also a ipv4 fix which I think are important and some may want to consider.

Cheers.

If you run this command, the '>' will first truncate the initrd_4.14.13-smp.gz file to zero length, then do the `cat'.
You need to give the output file a different name.

See https://mywiki.wooledge.org/BashGuide/InputAndOutput

(You could then rename the new initrd back to the original name as a separate step)

@loomx, thanks I was too fast to paste and cut from the post. Yes the output name must be unique from the input name, I've corrected the post. Cheers,

If I run Spectre and Meltdown mitigation detection tool v0.35 I get:
This means that the Slackware kernel is not compiled with support for IBRS/IBPB?
RedHat recommends here
https://access.redhat.com/articles/3311301
these options
My question is how can I activate IBRS/IBPB support?

teoberi --

What version of Slackware and which Kernel do you run ?

As far as I can tell, the latest Kernel Mitigation Code has not yet been backported to the 4.4.y Kernel ( Slackware 14.2's Official Kernel ).

However, there was an additional mitigation in last night's Slackware-current 4.14.27 Kernel ( note the spectre_v2 lines ).

These were the mitigations listed for the 4.14.26 Kernel ( before last night's update ) on a Laptop with an i5-3210M CPU with the latest intel-microcode:
And these are the mitigations listed after installing last night's Slackware-current 4.14.27 Kernel:
For comparison, these are the mitigations listed for the 4.4.118 kernel from a 'stock' Slackware64 14.2 box with a i3-4150 CPU on the latest intel-microcode:
There are a lot of interesting entries in the 4.14.27 ChangeLog: https://cdn.kernel.org/pub/linux/ker...ngeLog-4.14.27 ( :) not that I pretend to understand them all :) )

HTH

-- kjh

EDIT:

P.S. If I recall, RedHat is running a patched 3.10 Kernel so there may be additional steps to apply the mitigations on a RHEL 7 System ?

I don't believe you need to do anything for the latest mitigations to be applied to the 4.4.y Kernels in Slackware 14.2 or the 4.14.y Kernels in Slackware-current.

And ... if previous Kernel Release History is any indicator, there may be additional mitigation code back-ported to 4.4.122 which would be released after a couple rc's ... say, later this weekend or early next week ... ???

If you're interested in the process, you can watch Greg KH's work in progress here: https://git.kernel.org/pub/scm/linux...stable-rc.git/

Slackware64-current with kernel 4.14.27
gawk '{ print FILENAME "\t" $0 }' /sys/devices/system/cpu/vulnerabilities/*
I checked on a server without updating the microcode:
Maybe the script "spectre-meltdown-checker.sh" needs to be updated!

Thanks for that link abga !

I read it 'way back' in January and forgot ALL about it now that it's off my LWN Front Page :)

It's scary ... the murky fog seems to be lifting WRT all this stuff :)

-- kjh

Now I understand what "IBRS_FW" means!
https://patchwork.kernel.org/patch/10218901/

teoberi, Red Hat has its own nonstandard patches. Those options do not exist in anybody else's kernel, including Linus' kernel or the Greg K-H stable kernels. If you grep for 'ibrs_enabled' in the official source of 4.15.10, or 4.4.121, that option does not exist.

The "Skylake problem" is highly debatable. People have been quoting a kernel discussion from early January, but there have been more discussions about it since then, including in mid-January.

Slackware has the latest un-fucked-with kernels from Linus via Greg K-H. It has all the Spectre and Meltdown fixes that Linus and Greg K-H have approved (... in the case of 14.2, at the end of last month). If the kernel without Red Hat patches is good enough for Linus, and if it's good enough for Greg K-H, and Patrick, then it's good enough for me, and in my opinion you should stop worrying.

Edit: Please stop quoting that LWN link from 4th January. It's obsolete. As far as I can work out, the kernel now includes David Woodhouse's patch from 20th January to automatically configure the spectre_v2 mitigation -- see arch/x86/kernel/cpu/bugs.c:

Thanks for verifying that the kernel debug (debugfs is Greg KH creation BTW) patch for IBRS was only adopted by RedHat (and some others, Ubuntu included):
https://lwn.net/Articles/743019/
https://en.wikipedia.org/wiki/Debugfs

David Woodhouse's patch from 20th January (actually it looks like something from 12 Jan 2018 according to the 4.4.118 kernel changelog - kernel commits) is also available in RedHat's kernel, there is no uniqueness there, they just adopted the additional IRBS patch for manually&temporary switching off/on PTI/IBRS/IBPB, that's additional to the already available persistent - boot-time spectre_v2=off kernel boot parameter from David Woodhouse's patch.
https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.118
Switching IBRS/IBPB off might be useful ATM, due to their reported performance impact, on (isolated) systems that run verified code and need to perform very well (fast).
https://lwn.net/Articles/746551/
(Variant 2 section)

@teoberi
You shouldn't worry about that, as 55020 described, it is already activated by the automated mitigation routines in the kernel. You can however disable them or enforce them with the spectre_v2 kernel parameter:
https://github.com/torvalds/linux/bl...parameters.txt
(look for spectre_v2= )

Just for testing/proof, if you follow the link you referenced:
https://access.redhat.com/articles/3311301
and would like to disable PTI/IBRS/IBPB with the kernel boot parameters (in lilo.conf for example): append="spectre_v2=off nopti"
Then the output of that weird "Spectre and Meltdown mitigation detection tool" script will look like this:

Damn, I do not understand anything!
A few days ago the script "Spectre and Meltdown mitigation detection tool" displayed everything is OK -> STATUS: NOT VULNERABLE but today I'm vulnerable again:

It appears to be an extra check for skylake CPUs that was recently added in the "detection tool":
https://github.com/speed47/spectre-m...ker/issues/178
speed47 states that he/she'll try to fix it during this weekend.

If you're still using that "detection tool" script, I'd suggest to follow its issues too:
https://github.com/speed47/spectre-m...checker/issues
together with the commits:
https://github.com/speed47/spectre-m...commits/master

@teoberi. I want to remind you that this thread was about how-to install or upgrade Intel microcode. My question has been marked SOLVED for a month now. Additional posts to a SOLVED thread are usually informational to the original topic, specifically how to update microcode.

There was a separate thread for Spectre/Meltdown mitigation, which I recommend you re-post this comment on. It was started by Greg KH. Good luck. Cheers

OK!

Just FYI, there is a new microcode release at downloads intel.... (20180425)

And apparently they have decided that some processors are just not worthy enough to fix. WTF.

https://newsroom.intel.com/wp-conten...e-guidance.pdf

I guess no more Intel crap for me. And as a system builder/customizer/maintainer, I will no longer recommend Intel products to anyone due to their shartty support.

I just updated here. The microcode for my processor is still the same version as the January bundle, so no change for me.

Worth noting: there's now a 'list' file included in the intel-ucode directory that upsets iucode_tool when it tries to scan for microcode to include in the earlyfw cpio image. I had to change my build script to remove it in order to prevent the error.

I use SlackBuild (SBo),
https://slackbuilds.org/repository/1...tel-microcode/
which depends on,
https://slackbuilds.org/repository/1...m/iucode_tool/

However, with the new intel microcode release,
microcode-20180425.tgz
the intel-microcode SBo does not work anymore. The new microcode no longer includes microcode.dat, which the SBo seems to depend on.

The microcode-update-guidance.pdf shows that my CPU now has a new microcode, so I'm eager to install it when this SBo is working again. Then, my mkinitrd loads it during early boot.

You might have to email the maintainer and see if they know that there is a update available and ask them to update their SlackBuild.

Ahh, I hadn't noticed that microcode.dat had gone away: I don't use the SBo buildscript and mine doesn't use it.

twy --

I've modified ( :) butchered :) ) the Original intel-microcode.SlackBuild to deal with the new Structure of the Intel Microcode.tgz file.

Attached are intel-microcode.SlackBuild.txt and intel-microcode.info.txt which can be dropped into an existing COPY of your intel-microcode SBo directory.

Rename the two files without the .txt extents ( added so I could attach to this LQ Post ).

Set the Execute Permissions on intel-microcode.SlackBuild ( chmod 755 intel-microcode.SlackBuild )

The intel-microcode.info file includes a `wget-able` $DOWNLOAD variable and the MD5SUM is from Intel's Download Site.

`wget` the new microcode-20180425.tgz into the copy of the SBo Directory where you saved the modified intel-microcode.SlackBuild and intel-microcode.info files and DO check the MD5SUM ( also in the intel-microcode.info file ).

Note that there are two additional variables in the modified SlackBuild:

Note that you can combine the two variables as well:
I was not exactly sure what to do about the new intel-ucode-with-caveats/ directory but it is in the Package as /lib/firmware/intel-ucode-with-caveats/ if you want to use it.

In addition, the new Kernel Patches Directory is stored as /usr/doc/intel-microcode-20180425/linux-kernel-patches/

Finally, the intel-microcode.SlackBuild will generate a /lib/firmware/microcode.bin file ( a binary version of the formerly Intel-included ASCII Text microcode.dat file )

Anyhow, I've rebuilt and installed intel-microcode-20180425-noarch-1_SBo_kjh and rebuilt the initrd files on four boxes.

They all work fine but there were no changes to the microcode files for MY CPU's ...

HTH and Have Fun !

-- kjh

Thank you for your attention to this and your contribution with the new slackbuild.

This worked perfectly. My Pentium D 820 is 0f-04-07 code Smithfield, which is not updated and according to Intel's direction document probably won't be updated since it isn't even listed. The current BIOS is 12/12/2006 and Intel's microcode is 4-21-2005.
Time for a new machine, I think 13 years is long enough for any one processor. Cheers