Microcode for every processor? Not a Xeon 5650?

[npaust]

Somehow, in my decade of using gentoo, I completely missed the fact that I need to include microcode in my kernel. I guess it's really more of an optimization than a need!

Anyway, I followed the instructions on the Intel Microcode wiki and got 5 of my 6 machines working. The last one though is failing because I can't find the microcode for the processor.

The processor in question is a Intel Xeon x5650 with a signature of x206c2. If you look at the Intel documentation pages, the 20150121 microcode package specifically references this processor. However, when I emerge that package, there's no microcode with that signature.

Is this normal? Do I have a perfect processor that's never needed revisions? Is the microcode package in portage defective and missing my processor? Or, is there some simple thing that I'm just overlooking?

Thanks for enlightening me,
Nathaniel

[Roman_Gruber]

There is always a microcode update regardless if you want itor not. UEFI does it for you during booting. and the operating system does it during bootup.

at genreation 4xxx processors onward this has to be done in linux with the initramfs in your bootloader. no more loading as in ivybridge or before when linux is already loaded.

have you checked dmesg what it says ?

--

Sigh I wish guys would crasp, that gentoo stable means "outdated" as debian stable.

Code: Select all

ASUS-G75VW roman # emerge -s intel-microcode
  
[ Results for search key : intel-microcode ]
Searching...

*  sys-firmware/intel-microcode
      Latest version available: 20161104
      Latest version installed: [ Not Installed ]
      Size of files: 1.260 KiB
      Homepage:      http://inertiawar.com/microcode/ https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=26400
      Description:   Intel IA32/IA64 microcode update data
      License:       intel-ucode

[ Applications found : 1 ]

I recommend that you use latest kernel.org release kernel version, same for gpu drivers, same for webbrowers and of course same for the microcode form the manufacturer. anything else can still be stable when you desire

alternatively when you have a decent mainboard manufacturer with up to date microcode in the bios, its obsolete than. you can repack your bios with up to date microcode too.

[npaust]

That only sort of answers my question. It appears that there is no specific microcode update for this processor (no updates with the correct signature) in either the Intel downloads or in the gentoo package. dmesg does show that the microcode uses some revision, but that's apparently coming from the computer's bios rather than from linux.

Also, your mention of needing to use an initramfs to do early loading of microcode is outdated. In recent kernels, I'm still at 4.4.39, you can add the microcode right into the kernel and it correctly updates at the start of the boot process.

[Roman_Gruber]

Also, your mention of needing to use an initramfs to do early loading of microcode is outdated.

Nope this was the suggested way recently (less than a year)

Outdated is to use a userpsace tool during the init tool to load the microcode.

An honeslty. I hope you are still aware of this fact

initramfs + kernel = sorta similar as = kernel + build in via special kernel option

Its the same stage (or lets call it point of time) when this information is processed by the (let call it boot process) "software".

MAy I ask you again.

HAve you used the last recent kernel aka 4.9.X with latest intel microde? What is the output of that dmesg regarding microcode, thanks

I doubt intel dropped the microcode for that particular cpu in their latest microcode "patch". Is it really dropped in latest?

--

Latest bios installed?

have you disassembled the bios and checked that microde?

Is that microcode in any way with flaws that you need another one? e.g. instruction bug which is not very well handled by that microcode in the bios?

[frostschutz]

I don't know if that Xeon Whatever has a microcode udpate.

If Linux updated the microcode correctly, it will be the first line even before the kernel reports its version.

Code: Select all

$ dmesg | head
[    0.000000] microcode: microcode updated early to revision 0x1c, date = 2014-07-03
[    0.000000] Linux version 4.9.2 (root@EIS) (gcc version 5.4.0 (Gentoo 5.4.0 p1.0, pie-0.6.5) ) #2 SMP Tue Jan 10 17:57:46 CET 2017

Such a early microcode udpate can be passed the same way initramfs is passed onto the kernel - but it's just using that path to get data to the kernel, it's not actually part of the initramfs which comes later.

Should also work for builtin initramfs, not sure if there is a kernel option specific to built-in microcode update files.

[npaust]

Roman_Gruber, at the bottom of the intel microcode wiki page it has a description of how to use the microcode without an initramfs. It may not be hugely functionally different, but from my point of view it's fairly simple. If there was some user that was scared off by having to set up the initramfs, it's good to know that that step isn't required. The change date on that wiki is from the end of December 2016, so it may be that that's a fairly recent change.

I think we're getting away from my original question, which more academic than functional. There isn't a specific file in the intel releases that corresponds to my processor on one of my machines. That machine has been fairly rock solid for the ~5 years that I've had it (and I've never worried about microcode issues before). So, in large part the question is simply, "If you can't find a microcode file for your processor, does it really matter?"

For completeness though, the machine is a Dell and does have the most recent bios installed. I don't care enough to try to figure out what particular microcode the bios may or may not be trying to load. Using the gentoo-sources-4.4.39 kernel, and without inserting a specific microcode file, dmesg does not show any lines of "microcode updated early". Since I'm not specifying a microcode, that would really surprise me. I'm also not particularly inclined to jump to a different kernel just to play with an issue that seems to be a non-issue.

Again though, it seems like the answer is that you should go looking for microcode for your processor if you're running into problems. If a machine works, then the bios or some other behind-the-scenes method is taking care of it.

[Roman_Gruber]

Just for information. early_ucode.cpio is my generated intel microcode. initramfs-genkernel-x86_64-4.2.3-gentoo is the genkernel geneated initramfs.

Code: Select all

menuentry ' ... ' {
        insmod part_gpt
        set root='hd0,gpt2'
        echo    ' ... '

    linux /... 
    initrd /early_ucode.cpio /initramfs-genkernel-x86_64-4.2.3-gentoo

}

The difficult stuff is only to write one line starting with initrd, and to rename and move that intel u-code file to the boot partition.

Just for information.

At least one microcode is in the BIOS (or lets call it UEFI these days)

Intel patches out some features with microcode, like overclocking of NON K cpus (becaues they are greedy).
There are some advanced techniques which you can achieve when you play around on some platforms with intels microcode. I will not discuss this here because of legal reasons. Also do not ask me here or in personal message. Those who are interested will find it themself anyway.

Microcode is only here to correct Flaws found in cpus later, like broken instructions in the silicons. Or to patch out overclocking functionality from some mainboards for non K ("non overclockable" intel cpus).

All this information I provided only refers to INTEL platform (starting from penryn -> ivybridge / haswell). I do not use AMD, and I do not intend to use that in future too. These are the platforms I was interested in, and where I read about it.

[hmh]

Somehow, in my decade of using gentoo, I completely missed the fact that I need to include microcode in my kernel. I guess it's really more of an optimization than a need!

Not really, depends on how buggy your system is, which in turn depends on what processor you have and also on what revision of microcode is already preloaded into it by your BIOS/UEFI. And it is always possible your usage pattern never triggers whatever bugs are still unpatched in your processor.

The processor in question is a Intel Xeon x5650 with a signature of x206c2. If you look at the Intel documentation pages, the 20150121 microcode package specifically references this processor. However, when I emerge that package, there's no microcode with that signature.

Microcode 0x206c2 is a "bit special", in that newer revisions of it have high chances of bricking Intel TXT on motherboards with a BIOS/UEFI that is too old. By "high chances" I mean nobody tested and reported back, so we have to assume the worst just in case it really bricks Intel TXT.

Apparently, just because microcode updates are ephemeral (reverted by hard-reset/power-off), doesn't mean they cannot make persistent changes to the TPM and Intel ME data areas (which are very persistent). Please refer to Intel-SA-00030 (https://security-center.intel.com/advis ... geid=en-fr), and read between the lines of the "recommendations" section of that security advisory.

I.e. for Xeon 56xx-based systems, you need an up-to-date BIOS/UEFI from your motherboard vendor instead of operating-system-supplied microcode updates. Without such vendor updates, you might (depending on how old the microcode in your BIOS/UEFI is) have several known security bugs in the processor, and I certainly don't mean the Intel TXT issue described in Intel-SA-00030 (https://security-center.intel.com/advis ... geid=en-fr). It will have vulnerabilities that allows malware to inject itself into SMM (ring -3, "system management mode") and also a very irritating bug that renders 32-bit VMs (but not 64-bit VMs) dangerous to run on that machine.

Nobody really knows why Intel pulled the (old) microcode update it was distributing, though. It did not brick anything as far as we know, since nobody complained to Linux distros for the several years it was in the field. And it did fix several other nasty errata related to power management and other internal, less visible functions of the chip. OTOH, it left several critical issues unfixed, such as: Intel-SA-00030, Intel-SA-00045(?), the 32-bit VMs critical errata, and the LAPIC "memory sinkhole".

Is this normal? Do I have a perfect processor that's never needed revisions? Is the microcode package in portage defective and missing my processor? Or, is there some simple thing that I'm just overlooking?

Quite the opposite. For server use, you have a Processor from Hell if your BIOS/UEFI is not running it at a suitably high microcode revision level. I would never trust anything Xeon 36xx/56xx that can't be updated to at least revision 0x15 to server work (and for critical server work I would require revision 0x1a or higher).

Systems that are stuck with older microcode might be fine to use for gaming or as light desktop that will never need to run 32-bit VMs or something like that, though. It is not a junk-yard sentence...

Besides, if that system has been working fine for you for many years, what difference does it really make that it is somewhat broken? It certainly did not get in your way, or you'd have replaced it long ago. The usual mass-criminals do not seem to be actively exploiting the nasty SMM security issues since they are very target-specific. Your 32-bit VMs might corrupt data or crash every so often, though (but you could just restrict yourself to 64-bit VMs) -- and that's just if your microcode is older than 0x15 AFAIK.

FYI: one actually wants revision 0x1D of that microcode to protect oneself against the "LAPIC memory sinkhole" security vulnerability (I've heard HP has it for most/all(?) of their Xeon 56xx/36xx servers, I don't know about other vendors). Revision 0x1A (which is easier to find on server/workstation BIOS updates) is also good, in that it should fix most of the issues, but it does not fix the LAPIC memory sinkhole security vulnerability.

[npaust]

hmh, thank you for that detailed explanation. I'm guessing that this computer would be your worst nightmare since dmesg reports an 0x10 revision on the microcode. I wish I had a history of what versions of the microcode that Dell has pushed out in previous BIOS updates. I wonder if they went backwards to specifically avoid some of the issues you outlined?

Anyway, the computer is a desktop workstation, not a server, and doesn't run any virtualization, isn't using TXT, and only connects to the world via ssh anyway. In the past ~5 years of use (it is getting close to retirement), it's had perhaps two crashes, even with being on and used 24/7. My usage patterns must just not hit the bugs.

Thanks for the info.

[xming]

HP z400 has microcode 1D, apparently some (random) people uses it. I had a look
- d/l from HP http://ftp.hp.com/pub/softpaq/sp75501-76000/sp75720.tgz, extract the bios file
- use https://github.com/platomav/MCExtractor to extract the the microcode

Code: Select all

-------[ MC Extractor v1.13.2 r52 ]-------

File (1/1): 7G3_0360.bin

+---+-------+--------------+----------+------------+---------+--------+----------+---------+--------+
| # | CPUID |   Platform   | Version  |    Date    | Release |  Size  | Checksum |  Offset | Latest |
+---+-------+--------------+----------+------------+---------+--------+----------+---------+--------+
| 1 | 106A5 |  03 [0, 1]   |    1B    | 2015-06-27 |   PRD   | 0x2800 | B57A8827 | 0x70050 |  Yes   |
+---+-------+--------------+----------+------------+---------+--------+----------+---------+--------+
| 2 | 106A4 |  03 [0, 1]   |    13    | 2015-06-30 |   PRD   | 0x3800 | 35DDB232 | 0x72850 |  Yes   |
+---+-------+--------------+----------+------------+---------+--------+----------+---------+--------+
| 3 | 206C1 |  03 [0, 1]   |    6     | 2009-12-22 |   PRD   | 0x1800 | 45E27C49 | 0x76050 |  Yes   |
+---+-------+--------------+----------+------------+---------+--------+----------+---------+--------+
| 4 | 206C2 |  03 [0, 1]   |    1D    | 2015-08-04 |   PRD   | 0x2400 | F7DC758B | 0x77850 |  Yes   |
+---+-------+--------------+----------+------------+---------+--------+----------+---------+--------+
| 5 | 206C0 | 13 [0, 1, 4] | FFFF0016 | 2009-08-20 |   PRE   | 0x2000 | 764EEA44 | 0x79C50 |   No   |
+---+-------+--------------+----------+------------+---------+--------+----------+---------+--------+

Code: Select all

$ iucode_tool -S -l /tmp/MCExtractor/Extracted/Intel/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin
iucode_tool: system has processor(s) with signature 0x000206c2
microcode bundle 1: /tmp/MCExtractor/Extracted/Intel/cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin
selected microcodes:
  001/001: sig 0x000206c2, pf_mask 0x03, 2015-08-04, rev 0x001d, size 9216

Will try to use this on my system, rumour is that HP will release new bios on the 26th of Jan with new microcode.

UPDATE:

Code: Select all

iucode_tool cpu206C2_plat03_ver0000001D_2015-08-04_PRD_F7DC758B.bin -K

Will output the correct filename and put the file in /lib/firemware/intel-ucode which are needed for kernel fw loader

Code: Select all

[    0.592613] microcode: sig=0x206c2, pf=0x1, revision=0x14
[    0.592750] microcode: Microcode Update Driver: v2.2.
[ 1276.090617] microcode: updated to revision 0x1d, date = 2015-08-04

UPDATE: eraly loading

Code: Select all

[    0.000000] microcode: microcode updated early to revision 0x1d, date = 2015-08-04
[    0.580402] microcode: sig=0x206c2, pf=0x1, revision=0x1d
[    0.580550] microcode: Microcode Update Driver: v2.2.

[xming]

HP has released new BIOS, which contains the latest microcode for Westmere

Code: Select all

[    0.000000] microcode: microcode updated early to revision 0x1e, date = 2018-01-23
[    0.595744] microcode: sig=0x206c2, pf=0x1, revision=0x1e
[    0.595883] microcode: Microcode Update Driver: v2.2.

[bunder]

x5650 is westmere ep, and according to intel 1e is indeed the latest revision for that processor. meanwhile bloomfield doesn't get diddly. rip my i7 920.

https://newsroom.intel.com/wp-content/u ... idance.pdf

[xming]

x5650 is westmere ep, and according to intel 1e is indeed the latest revision for that processor. meanwhile bloomfield doesn't get diddly. rip my i7 920.

time to replace 920 with a cheap westmere from ebay