Help: need to build a ramdisk with microcode to fix bug

Freaksta · 10-08-2015, 07:13 PM

https://bugzilla.kernel.org/show_bug.cgi?id=103351

Can someone help me here? I obtained a 0x13 microcode update called broadwell.bin and saved it in the Downloads directory for root (VM for testing).

here are the results of my actions:

I saved broadwell.bin, and from the same directory ran:

iucode-tool -Sl --overwrite --write-earlyfw=/boot/intel-ucode.img broadwell.bin

This resulted in:

root@Donkey:~/Downloads# iucode_tool -Sl --overwrite --write-earlyfw=/boot/intel-ucode.img broadwell.bin
iucode_tool: system has processor(s) with signature 0x00040671
selected microcodes:
001: sig 0x00040671, pf mask 0x22, 2015-08-03, rev 0x0013, size 11264
iucode_tool: Writing selected microcodes to: /boot/intel-ucode.img
root@Donkey:~/Downloads#

I then updated my LILO entry with "initrd = /boot/intel-ucode.img" and ran the 'lilo' command.
I rebooted.

I ran 'dmesg | grep micro' and got the following:

root@Donkey:~# dmesg | grep micro
[ 3.757670] microcode: CPU0 sig=0x40671, pf=0x2, revision=0x19
[ 3.811668] microcode: CPU1 sig=0x40671, pf=0x2, revision=0x19
[ 3.812220] microcode: CPU2 sig=0x40671, pf=0x2, revision=0x19
[ 3.812562] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
root@Donkey:~#

i ran dmesg | grep early' and got nothing.

I ran 'grep microcode /proc/cpuinfo and got:
root@Donkey:~# grep micro /proc/cpuinfo
microcode : 0x19
microcode : 0x19
microcode : 0x19
root@Donkey:~#

What am I doing wrong?

bassmadrigal · 10-09-2015, 06:39 AM

According to the Arch wiki, you need to have the microcode option compiled into the kernel, not as a module. Unfortunately, Slackware compiles this as a module, so you'll likely need to rebuild your kernel with that option marked as a Y instead of M.

55020 · 10-09-2015, 07:30 AM

I didn't know about CONFIG_MICROCODE_INTEL_EARLY, so thanks to bassmadrigal and Freaksta -- the kernel config is explained well in this Red Hat bug: https://bugzilla.redhat.com/show_bug...ple&id=1083716

Quote:

The current Fedora kernel config-x86-generic contains
CONFIG_MICROCODE_INTEL_EARLY=y

However, this is ineffective because microcode itself is built as a module
CONFIG_MICROCODE=m

And the MICROCODE_EARLY option depends on it being built-in, not as a module; from arch/x86/Kconfig:

config MICROCODE_EARLY
bool "Early load microcode"
depends on MICROCODE=y && BLK_DEV_INITRD
select MICROCODE_INTEL_EARLY if MICROCODE_INTEL
select MICROCODE_AMD_EARLY if MICROCODE_AMD
default y

To fully enable early-microcode-loading, the config should have at least

CONFIG_MICROCODE=y
CONFIG_MICROCODE_EARLY=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_INTEL_EARLY=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_AMD_EARLY=y

If that doesn't bloat the kernel too much, it would be nice if this could be picked up for Slackware.

An alternative is to hack your own BIOS that contains the new microcode: it's a bit fiddly, and requires various dodgy Windows utilities, and might be awkward or even impossible for UEFI, but it worked well for me to get round the Atom PSE erratum. I guess they invented CONFIG_MICROCODE_INTEL_EARLY to save us this pain.

atelszewski · 10-12-2015, 03:38 AM

Hi,

I went down the path and tried the early microcode update (I'm on Intel based system).
Some additional info here.
Here is my quick and dirty how to.

1. Install intel-microcode
2. Install iucode_tool
3. Rebuild your kernel (generic + initrd) with:

Code:

CONFIG_MICROCODE=y
CONFIG_MICROCODE_EARLY=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_INTEL_EARLY=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_AMD_EARLY=y

4. Prepare microcode for inclusion in initrd:

Code:

$ iucode_tool --scan-system --write-earlyfw=/boot/ucode.cpio /lib/firmware/microcode.dat

6. Merge microcode with initrd (/boot/initrd-generic-4.1.x.gz is my initial ramdisk):

Code:

$ cat /boot/ucode.cpio /boot/initrd-generic-4.1.x.gz > /boot/initrd-generic-ucode-4.1.x.img

7. Run LILO, reboot and pray for the system to boot again

Unfortunately, I cannot test if the microcode is applied properly, because my BIOS already has the latest available microcode in it. What I can confirm is that the initial ramdisk with the prepended microcode actually boots properly.

--
Best regards,
Andrzej Telszewski

Freaksta · 10-12-2015, 01:47 PM

Thank you everyone!

I will try this tonight and report back. :-)

slalik · 10-14-2015, 05:54 PM

On stable kernel 3.10.17 the early Intel microcode update works without any change in the kernel configuration. I use the procedure described by atelszewski, and it really works. (Minor additions to step 4: iucode_tool requires the module cpuid: --not really needed now, see below

Code:

# grep -q cpu/cpuid /proc/devices || modprobe -q cpuid

Also, I add the option --overwrite, otherwise iucode_tool can't write to /boot/ucode.cpio if this file already exists.)

Starting with 3.11 kernel added the support for AMD and the requirement CONFIG_MICROCODE=y. Unfortunately, the kernel config in Slackware-current have CONFIG_MICROCODE=m and hence CONFIG_MICROCODE_EARLY is disabled.

atelszewski · 10-15-2015, 11:58 AM

Hi,

Quote:

Minor additions to step 4: iucode_tool requires the module cpuid

How does it manifest itself? Is iucode_tool complaining?

I'm running 4.1.10 without the cpuid module loaded (neither it's compiled-in) and it looks like everything is detected correctly:

Code:

$ iucode_tool -S -v -l /lib/firmware/microcode.dat 
iucode_tool: system has processor(s) with signature 0x000206a7
iucode_tool: assuming all processors have the same signature
iucode_tool: microcode bundle 1: /lib/firmware/microcode.dat (662528 bytes)
iucode_tool: processed 149 valid microcode(s), 149 signature(s), 149 unique signature(s)
selected microcodes:
001: sig 0x000206a7, pf mask 0x12, 2013-06-12, rev 0x0029, size 10240
iucode_tool: selected 1 microcode(s), 1 signature(s)

--
Best regards,
Andrzej Telszewski

slalik · 10-15-2015, 12:34 PM

Quote:

Originally Posted by atelszewski

How does it manifest itself? Is iucode_tool complaining?
I'm running 4.1.10 without the cpuid module loaded (neither it's compiled-in) and it looks like everything is detected correctly

You are right, it works without cpuid module now. I found an explanation in the /usr/doc/iucode_tool-1.3/ChangeLog

Code:

2015-02-14, iucode_tool v1.2
[...]
* iucode_tool: use the cpuid instruction (via gcc's cpuid.h) directly
    to implement --scan-system.  This assumes there is only one
    signature per x86/x86-64 system, which is a safe assumption at this
    time.  One can have processors with distinct pf flags and the same
    signature in a x86/x86-64 multi-processor system, so --scan-system
    will match any pf_mask.  When compile-time configured with
    --enable-cpuid-device (disabled by default), iucode-tool will use
    the cpuid instruction directly and also scan every processor using
    the kernel cpuid device.  This fixes an scalability issue in systems
    with many processors

Thank you!

atelszewski · 10-15-2015, 01:54 PM

Hi,

BTW, I have updated the intel-microcode SlackBuild at SlackBuilds.org (it's in the approved queue as of 15 Oct 2015) so that, if you have iucode_tool installed, the microcode gets split and installed under /lib/firmware/intel-ucode.

It's important to have those files there, quote from iucode_tool man page:

Quote:

There are two microcode update kernel drivers in Linux: the early microcode update driver (which gets the microcode update data from a special uncompressed initramfs image) and the late microcode update driver, which gets microcode update data through the firmware subsystem.

The late microcode update driver should be present in the system at all times to ensure microcode updates are reapplied on resume from suspend and cpu hotplug, even when the early microcode update driver is used. Do not unload it, unless you really know better.

Updating microcode through the early driver is safer, but can only be done at boot. Using the early driver to update microcode is strongly recommended. The late microcode update driver can apply new microcode updates at any time, but it cannot safely apply any new microcode updates that would change visible processor features.

--
Best regards,
Andrzej Telszewski

slalik · 10-16-2015, 07:33 AM

Quote:

Originally Posted by atelszewski

BTW, I have updated the intel-microcode SlackBuild at SlackBuilds.org (it's in the approved queue as of 15 Oct 2015) so that, if you have iucode_tool installed, the microcode gets split and installed under /lib/firmware/intel-ucode.

Thank you very much! I have one remark: strictly speaking, for version 14.1 the requirement:

Code:

3) make sure your kernel has the followings:
  CONFIG_MICROCODE=y
  CONFIG_MICROCODE_EARLY=y
  CONFIG_MICROCODE_INTEL=y
  CONFIG_MICROCODE_INTEL_EARLY=y

is not true. It suggests that the standard 14.1 kernel, which has 'CONFIG_MICROCODE=m', must be recompiled, but this is not the case. For 14.1 the standard configuration is OK.

Also, what do you think on the idea to produce also /boot/ucode.cpio (via iucode_tool --scan-system --overwrite --write-earlyfw=/boot/ucode.cpio)?

Addition:
I read about the /lib/firmware/intel-ucode. As far as I understand, this directory is needed in two situation:
1. when user/admin wants to update microcode manually via

Code:

echo -n 1 >/sys/devices/system/cpu/microcode/reload

2. when the CPU is changed physically (without a reboot).

In case of resume from S3 state it is not needed, because Documentation/x86/early-microcode.txt and Documentation/power/suspend-and-cpuhotplug.txt both claim that kernel uses the cached microcode.

In Debian, the README file tells that triggering an immediate microcode update (without a reboot) is dangerous:

Quote:

**** WARNING **** **** WARNING **** **** WARNING **** **** WARNING ****

This procedure used to be safe before microcode update 20140913.
It is not safe anymore in the general case.

While it is likely to continue to be safe for the Intel micro-
architectures that preceded Haswell and Silvermont, this is not
in any way assured.

You have been warned. Do not do this unless you really know
what you are doing.

**** WARNING **** **** WARNING **** **** WARNING **** **** WARNING ****

Debian package intel-microcode-3.20150121.1 contains a file ucode-blacklist.txt:

Code:

06-3c-01
06-3c-02
06-3c-03
06-3f-01
06-3f-02
06-45-01
06-46-01

In /lib/firmware/intel-ucode the files from this blacklist are renamed to 06-3c-02.initramfs, etc. The Debian NEWS files reads:

Quote:

Microcodes known to be dangerous have been renamed so that they will
not be found by the kernel. This is a reactive blacklisting: it is
unlikely to be complete at any point in time.

atelszewski · 10-17-2015, 03:28 AM

Hi,

Quote:

Originally Posted by slalik

Thank you very much! I have one remark: strictly speaking, for version 14.1 the requirement:

Code:

3) make sure your kernel has the followings:
  CONFIG_MICROCODE=y
  CONFIG_MICROCODE_EARLY=y
  CONFIG_MICROCODE_INTEL=y
  CONFIG_MICROCODE_INTEL_EARLY=y

is not true. It suggests that the standard 14.1 kernel, which has 'CONFIG_MICROCODE=m', must be recompiled, but this is not the case. For 14.1 the standard configuration is OK.

OK, for the sake of argument let's just say you have to make sure the aforementioned configuration options are compiled-in.
I'm using config from -current, and there the options were set as =m.

Quote:

Also, what do you think on the idea to produce also /boot/ucode.cpio (via iucode_tool --scan-system --overwrite --write-earlyfw=/boot/ucode.cpio)?

Seems fine.

Quote:

Addition:
I read about the /lib/firmware/intel-ucode. As far as I understand, this directory is needed in two situation:
1. when user/admin wants to update microcode manually via

Code:

echo -n 1 >/sys/devices/system/cpu/microcode/reload

2. when the CPU is changed physically (without a reboot).

In case of resume from S3 state it is not needed, because Documentation/x86/early-microcode.txt and Documentation/power/suspend-and-cpuhotplug.txt both claim that kernel uses the cached microcode.

OK. Let's assume having the files under /lib/firmware/intel-ucode won't hurt you (see the comment below), but might be handy in some cases.

Quote:

In Debian, the README file tells that triggering an immediate microcode update (without a reboot) is dangerous:

Quote:

**** WARNING **** **** WARNING **** **** WARNING **** **** WARNING ****

This procedure used to be safe before microcode update 20140913.
It is not safe anymore in the general case.

While it is likely to continue to be safe for the Intel micro-
architectures that preceded Haswell and Silvermont, this is not
in any way assured.

You have been warned. Do not do this unless you really know
what you are doing.

**** WARNING **** **** WARNING **** **** WARNING **** **** WARNING ****

Debian package intel-microcode-3.20150121.1 contains a file ucode-blacklist.txt:

Code:

06-3c-01
06-3c-02
06-3c-03
06-3f-01
06-3f-02
06-45-01
06-46-01

In /lib/firmware/intel-ucode the files from this blacklist are renamed to 06-3c-02.initramfs, etc. The Debian NEWS files reads:

Quote:

Microcodes known to be dangerous have been renamed so that they will
not be found by the kernel. This is a reactive blacklisting: it is
unlikely to be complete at any point in time.

OK, so it seems that some of the ucode files might hurt you. This makes me uncomfortable, as it adds more maintenance burden to the intel-microcode.SlackBuild. I hate it

I will have to investigate a little bit to see what it is all about and maybe incorporate the blacklisting in the SlackBuild, althoug at the moment I'm not a heavy user of the microcode, as my system has the latest one built-in into BIOS (so I even can't experiment).

--
Best regards,
Andrzej Telszewski

slalik · 10-17-2015, 04:40 AM

Quote:

Originally Posted by atelszewski

OK, for the sake of argument let's just say you have to make sure the aforementioned configuration options are compiled-in.
I'm using config from -current, and there the options were set as =m.

Yes, people with -current and, generally, everybody who upgraded the kernel, must have these options compiled in. But people with the stock stable kernel 3.10.17 are to do nothing, for 3.10 everything works even if CONFIG_MICROCODE=m. So, I'd prepend something like "if you upgraded the stock slackware kernel" to "3) make sure your kernel has the followings:".

atelszewski · 10-17-2015, 12:15 PM

Hi,

Quote:

So, I'd prepend something like "if you upgraded the stock slackware kernel" to "3) make sure your kernel has the followings:".

I'm going to stick to my words. Today 3.10.x is the stock kernel, but in the future, 4.1.x is going to be the one

We might generalize and say: "make sure CONFIG_MICROCODE_INTEL_EARLY=y (whatever the dependencies)".

Quote:

But people with the stock stable kernel 3.10.17 are to do nothing, for 3.10 everything works even if CONFIG_MICROCODE=m.

Indeed, looking at the kernel dependencies it turns out that CONFIG_MICROCODE=y is the requirement for 4.1.x but not for 3.10.x.

--
Best regards,
Andrzej Telszewski

slalik · 10-17-2015, 12:41 PM

Quote:

Originally Posted by atelszewski

We might generalize and say: "make sure CONFIG_MICROCODE_INTEL_EARLY=y (whatever the dependencies)".

I think this is perfect.

It would be nice if this would be in the stock kernel for 14.2 as it is for 14.1!

Freaksta · 10-21-2015, 05:41 PM

Hello friends...

This still isn't working for me. Can you point out my mistake?

bash-4.2# cat /usr/src/linux/.config | grep MICRO
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_MICROCODE_INTEL_LIB=y
CONFIG_MICROCODE_INTEL_EARLY=y
CONFIG_MICROCODE_EARLY=y
CONFIG_NFC_MICROREAD=m
CONFIG_PATA_JMICRON=y
CONFIG_NET_VENDOR_STMICRO=y
CONFIG_HID_MICROSOFT=m
CONFIG_USB_MICROTEK=m
CONFIG_MEMSTICK_JMICRON_38X=m
bash-4.2#

bash-4.2# cd /lib/firmware/

bash-4.2# ls -al broadwell.bin
-rw-r--r-- 1 root root 11264 Oct 18 09:11 broadwell.bin

(Added the -K switch to copy to intel-ucode directory in /lib/firmware)

bash-4.2# iucode_tool -Sl -K --overwrite --write-earlyfw=/boot/intel-ucode.img /lib/firmware/broadwell.bin
iucode_tool: system has processor(s) with signature 0x00040671
selected microcodes:
001: sig 0x00040671, pf mask 0x22, 2015-08-03, rev 0x0013, size 11264
iucode_tool: Writing selected microcodes to: /boot/intel-ucode.img
iucode_tool: Writing microcode firmware file(s) into /lib/firmware/intel-ucode
bash-4.2#

(I have also tried iucode_tool --scan-system --write-earlyfw=/boot/ucode.cpio /lib/firmware/ )

bash-4.2# cat /etc/lilo.conf | grep intel
initrd = /boot/intel-ucode.img

bash-4.2# lilo
Warning: LBA32 addressing assumed
Added Linux + *
Added Recovery
One warning was issued.

bash-4.2#

And when I reboot....

bash-4.2# dmesg | grep early
bash-4.2# dmesg | grep micro
[ 0.598123] microcode: CPU0 sig=0x40671, pf=0x2, revision=0x19
[ 0.598315] microcode: CPU1 sig=0x40671, pf=0x2, revision=0x19
[ 0.598501] microcode: CPU2 sig=0x40671, pf=0x2, revision=0x19
[ 0.599050] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
bash-4.2# grep microcode /proc/cpuinfo
microcode : 0x19
microcode : 0x19
microcode : 0x19
bash-4.2#