LinuxQuestions.org - [SOLVED] How to load new Intel microcode

Page 1 of 4

Show 50 post(s) from this thread on one page

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - How to load new Intel microcode (https://www.linuxquestions.org/questions/slackware-14/how-to-load-new-intel-microcode-4175621053/)

bamunds

01-05-2018 09:51 PM

How to load new Intel microcode

This thread started on the Latest Kernel release thread. https://www.linuxquestions.org/quest...14#post5802714 at post 505 and continues through post 518. To avoid duplication of helpful comments please read that thread at least for the posts listed.

NOTE this only address the microcode loading issue and not the full mitigation for Meltdown or Spectre threat.

It is for the purpose of helping me understand how to load my older Intel Pentium D 820 processor on a no-longer support emachine t5224. The platform is a full install of Slackware 64 14.2 with multilib and FVWM as primary WM.

iucode_tool version 2.2 is loaded from Slackbuilds.org.
The man page is a great and required read to understand the tool.
This tool was loaded to discover processors signature in hopes of seeing if Intel had new microcode to overcome the Meltdown and Spectre threats.

This lead to a coversation about how Intels instructions for loading the 20171117 microcode, which does NOT have the newest microcode to address Meltdown or Spectre, but was important to read and understand what is offered, can be used to load microcode.

The installation is using LVM/LUKS and therefore requires an initrd. The initrd is re-created with each new kernel upgrade. Kernel installs are updated to either Pat's latest official release or kernel.org latest release every 2 months, which ever comes first. Currently the platform is on 4.4.106 with 4.4.88 (Pat's latest official release) as the backup kernel.

The iucode_tool man page indicates that much has changed with microcode loading as of Linux kernel 4.4. The driver is now always loaded due to suspend and resume. Updating microcode earlier is safer and can should only be done at boot. It requires an uncompressed intramfs image in /kernel/x86/microcode/GenuineIntel.bin and must be the first initramfs called early initramfs. Read the man page of iucode_tool for Linux Notes section to get all the requirements.

What I need help understanding is how the iucode_tool inter works with the Intel Linux-microcode file.
I suspect that I have to unpack the file. Then use the intel_microcode SBo package https://slackbuilds.org/repository/1...tel-microcode/ to build a microcode from the /intel-ucode tar directory.

This third tool now will "2) write the microcodes to an early initramfs archive: /boot/intel-ucode.cpio" which then has to be PRE-pended to the initrd. So as Darth Vader indicated in the in the other thread a way to do that with:

Quote:

Originally Posted by Darth Vader (Post 5802711)

@bamunds

My solution to load the Intel microcode:

Code:

# Create the base initrd.

mkinitrd -c -k "$KVERSION" -r "$ROOTDEV" -f "$ROOTFS" -m "$KMODULES" -h "$SWAPDEV" -u -M -w 5 -o /boot/initrd-${KVERSION}.gz



# Concatenate the intel-ucode.cpio and base initrd on the final initrd.

cat /boot/intel-ucode.cpio /boot/initrd-${KVERSION}.gz > /boot/initrd-${KVERSION}_ucode.gz



# Symlink the final initrd.

ln -sf initrd-${KVERSION}_ucode.gz initrd.gz

I use the SBo variant of Intel microcode, for now.

Final question. What have I missed?
Will this actually then override the obsolete microcode on the CPU or only that part which is causing threats.
Until I try it I quess I won't know if it causes any other microcode changes that affect other parts of the system, like the HDD, Ethernet or the USB onboard reader to stop functioning. So this weekend I'll give it a try.
OH-- how to make a backup? I would think my backbup initrd for 4.4.88 should be ok since it won't load new microcode. Right?

Petri Kaukasoina

01-06-2018 02:48 AM

intel-microcode (20171117) from slackbuilds.org puts the microcode to /boot/intel-ucode.cpio. If you use generic kernel + initrd, rename /etc/mkinitrd.conf.sample to /etc/mkinitrd.conf and uncomment line with MICROCODE_ARCH="/boot/intel-ucode.cpio". Then running mkinitrd will automatically include the microcode to the initrd. (This was added as a patch in 14.2, Jun 29 2017.)

You can make a backup lilo entry with the old initrd.

(Or, if you don't use initrd, add ' initrd=/boot/intel-ucode.cpio' in lilo.conf to load the microcode directly instead of the real initrd.)

Try

Code:

grep microcode /proc/cpuinfo

before and after to see if the microcode version has changed.

This will not do anything to your ethernet firmware etc.

zakame

01-06-2018 05:02 AM

I just usually do this:

Code:

# install iucode_tool, install/update intel-microcode packages from SBo, then

/usr/share/mkinitrd/mkinitrd_command_generator.sh --run /boot/vmlinuz-generic -a '-P /boot/intel-ucode.cpio' | sh

This will generate a combined /boot/initrd.gz from the selected kernel modules needed for boot + the intel-ucode.cpio.

Then proceed to use the generated initrd as usual on your preferred bootloader.

In my case, I automate this in /usr/libexec/slackpkg/functions.d/z-lookkernel.sh for kernel upgrades.

mralk3

01-06-2018 02:12 PM

A quick rundown... I posted this some time ago in another thread, I believe, but cannot find it now.

EDIT: IMPORTANT: You must install iucode_tool from SBo, and immediately after you install that, install intel-microcode. If you do not first do this, then /boot/intel-ucode.cpio will not be present, and the following directions do not work.

Here is what my mkinitrd.conf looks like with the intel microcode in use:

Code:

#

# See "man mkinitrd.conf" for details on the syntax of this file

#

SOURCE_TREE="/boot/initrd-tree"

CLEAR_TREE="1"

OUTPUT_IMAGE="/boot/initrd.gz"

#KERNEL_VERSION="$(uname -r)"

KERNEL_VERSION="4.14.11"

KEYMAP="us"

MODULE_LIST="jbd2:mbcache:ext4:i915"

ROOTDEV="/dev/sda2"

ROOTFS="ext4"

RESUMEDEV="/dev/sda1"

UDEV="1"

MICROCODE_ARCH="/boot/intel-ucode.cpio"

WAIT="1"

And here is what the relevant part of my lilo.conf looks like:

Code:

image = /boot/vmlinuz-generic

  initrd = /boot/initrd.gz

  root = /dev/sda2

  label = Generic

  read-only

image = /boot/vmlinuz

  initrd = /boot/intel-ucode.cpio

  root = /dev/sda2

  label = Huge 

  read-only

I am running Slackware64-current. When there is a kernel upgrade I update KERNEL_VERSION in my mkinitrd.conf and then I run as root:

Code:

mkinitrd -F -c && lilo -v

This allows kernel-generic and kernel-huge to use the latest intel micorcode, assuming I have kept it up to date from ponce's SBo-git repository..

To check if everything is working, a reboot is necessary, and then:

Code:

root@localhost:~# grep microcode /var/log/dmesg 

[    0.000000] microcode: microcode updated early to revision 0x22, date = 2017-01-27

[    3.817920] microcode: sig=0x306c3, pf=0x10, revision=0x22

[    3.818348] microcode: Microcode Update Driver: v2.2.

--
This is my processor:

Code:

root@localhost:~# lscpu | grep "Model name"

Model name:          Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz

bamunds

01-06-2018 04:07 PM

Quote:

Originally Posted by Petri Kaukasoina (Post 5802774)

I've never created a mkinitrd.conf so I'll check the man page before proceeding.
To clarify you are referring to mkinitrd-1.4.10_x86_64-1_slack14.2 was patched, or at least that is where I found the patch in the changelog. It appears from ls /var/log/packages, that I did install that update. So next is to read the man page. I'm not clear why you qualified this for "generic kernel", wouldn't it work with any kernel referenced in the .conf file? Also what is the effect if using the mkinitrd_command_generator.sh? From reading the shell script still I think it use mkinitrd to generate the output, but I want to verify that it isn't going to bypass the /boot/intel-cpio if one is also using a mkinitrd.conf with that setting set?

Quote:

Originally Posted by Petri Kaukasoina (Post 5802774)

You can make a backup lilo entry with the old initrd.

Already have done this for safety in past. Thanks.

Quote:

Originally Posted by Petri Kaukasoina (Post 5802774)

(Or, if you don't use initrd, add ' initrd=/boot/intel-ucode.cpio' in lilo.conf to load the microcode directly instead of the real initrd.)

This confuses me. I do use a initrd because of LVM/LUKS, but I still want to understand if you are referring to the same lilo.conf entry that mralk3 suggested in post 4?

Thanks for the hints to make this easier going forward.

Darth Vader

01-06-2018 04:25 PM

Look, if you concatenate several initrds, the kernel is smart enough to find out every one and load them.

/boot/intel-ucode.cpio is just an initrd which contains these Intel firmware.

So, you concatenate it to your own initrd, then on final, the kernel will find them properly.

bamunds

01-06-2018 04:32 PM

Quote:

Originally Posted by mralk3 (Post 5803010)

A quick rundown... I posted this some time ago in another thread, I believe, but cannot find it now.

Thank you for posting it again.

Quote:

Originally Posted by mralk3 (Post 5803010)

Here is what my mkinitrd.conf looks like with the intel microcode in use:

Code:

#

# See "man mkinitrd.conf" for details on the syntax of this file

#

SOURCE_TREE="/boot/initrd-tree"

CLEAR_TREE="1"

OUTPUT_IMAGE="/boot/initrd.gz"

#KERNEL_VERSION="$(uname -r)"

KERNEL_VERSION="4.14.11"

KEYMAP="us"

MODULE_LIST="jbd2:mbcache:ext4:i915"

ROOTDEV="/dev/sda2"

ROOTFS="ext4"

RESUMEDEV="/dev/sda1"

UDEV="1"

MICROCODE_ARCH="/boot/intel-ucode.cpio"

WAIT="1"

I plan to read the man page for mkinitrd.conf to understand all the possible inputs. If I use the .conf do I need to list all the modules which are needed in the module_list entry? Is there a line length limit and does "" accept more entries on next line?

Quote:

Originally Posted by mralk3 (Post 5803010)

And here is what the relevant part of my lilo.conf looks like:

Code:

image = /boot/vmlinuz-generic

  initrd = /boot/initrd.gz

  root = /dev/sda2

  label = Generic

  read-only

image = /boot/vmlinuz

  initrd = /boot/intel-ucode.cpio

  root = /dev/sda2

  label = Huge 

  read-only

This doesn't make any sense. The intel-ucode.cpio needs to be loaded before any other part of the initrd per documents on using Intel microcode and the man page for iucode_tool. Why does your "Huge" only point to the intel-ucode.cpio, doesn't it need a standard initrd.gz?

Quote:

Originally Posted by mralk3 (Post 5803010)

I am running Slackware64-current. When there is a kernel upgrade I update KERNEL_VERSION in my mkinitrd.conf and then I run as root:

Code:

mkinitrd -F -c && lilo -v

Code:

root@localhost:~# grep microcode /var/log/dmesg 

[    0.000000] microcode: microcode updated early to revision 0x22, date = 2017-01-27

[    3.817920] microcode: sig=0x306c3, pf=0x10, revision=0x22

[    3.818348] microcode: Microcode Update Driver: v2.2.

--
This is my processor:

Code:

root@localhost:~# lscpu | grep "Model name"

Model name:          Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz

Thanks for the suggestions. I'll do some more reading on the mkinitrd.conf configuration.
Here are my current microcode results.

Code:

root@Hicrest1:~# lscpu | grep "Model name"

Model name:            Intel(R) Pentium(R) D CPU 2.80GHz

root@Hicrest1:~# grep microcode /var/log/dmesg

[    0.731704] microcode: CPU0 sig=0xf47, pf=0x10, revision=0x3

[    0.731843] microcode: CPU1 sig=0xf47, pf=0x10, revision=0x3

[    0.732038] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

root@Hicrest1:~# grep microcode /proc/cpuinfo

microcode      : 0x3

microcode      : 0x3

It appears the driver was updated in 14.2 is still at v2.01, and currently I don't have an early update being applied. I appreciate the examples of what it will look like after getting the microcode upgraded. If all my hardware is currently running correctly, does it make sense to upgrade the microcode to the 20171117 version? I suppose one reason might be to see if it works before waiting for the latest with the Meltdown fix.

Ultimately my understanding is that both microcode and kernel code need to be upgraded to resolve both the Meltdown and maybe Spectre threats. SO I'm waiting on the kernel correction for 4.4 line and will probably have to wait for the microcode too, if Intel even goes back to my older CPU. For now simply working to get this all work out and understood. Which is exactly what all the responses are helping me do. Thanks everyone, I keep learning and learning. More suggestions or corrections to my understanding are appreciated.

bamunds

01-06-2018 04:47 PM

Quote:

Originally Posted by Darth Vader (Post 5803052)

...the kernel is smart enough to find out every one and load them.

I don't want to take your "look" the wrong way but this statement doesn't fit logic of lilo. Lilo tells the boot loader which initrd you want to load and ignores the other initrd files of the lilo.conf. The concatenate of initrd's would have to be IN the same initrd as you select for the bootloader to load. Yes or no?

Quote:

Originally Posted by Darth Vader (Post 5803052)

/boot/intel-ucode.cpio is just an initrd which contains these Intel firmware.

So, you concatenate it to your own initrd, then on final, the kernel will find them properly.

Which I thought was the reason you suggested to make the initrd and then

Code:

# cat /boot/intel-ucode.cpio /boot/initrd-kernelxxxxx.gz > /boot/initrd.gz

Although I'm not sure this ensures that the intel-ucode is loaded first. Did you feel I misunderstood something from my responses to others? You maybe very familiar with your way, but it is new to me and I'm just learning and learning this new area of microcode and how to load latest Intel microcode to a old CPU. I'm seeking advice to simply be careful and not bork my system.

Darth Vader

01-06-2018 04:57 PM

From the lilo POV, that /boot/initrd.gz file is just an initrd (it have no clue about content), which it will map to kernel, when it is properly specified.

Right this concatenated file which contains the both initrd, you should specify to lilo.

And yes, the kernel will find and load first the firmware one.

BTW, SYSLINUX is smarter than LILO, on this aspect, because you can specify multiple initrd files. ;)

PS. And please forgive my English, I am not native speaker.

bamunds

01-06-2018 10:59 PM

@kjhambrick
Thanks again for your comments and example output in the Latest Kernel thread. Can you tell me which method of microcode updating you used and if you are using an initrd or not, per my question in #518?

You examples of how dmesg will display the updated code are very helpful in your #517 post on the other thread. I hope to use the latest kernel 4.4.110, which implements some Kaiser solutions, along with the latest 20171117 microcode and now I'll know what to pull from dmesg and what result to check to verify the task completed correctly.

kjhambrick

01-07-2018 08:06 AM

Quote:

Originally Posted by bamunds (Post 5803158)

<<cut-n-pasted from the latest kernel release thread>>

Quote:

Originally Posted by bamunds (Post 5803153)

Yes it did help. Especially helpful are you microcode dmesg outputs showing the microcode dates of your CPU which were loaded. However I am confused about which method you used for updating the microcode. Are you saying you're updating the microcode.dat (now deprecated) or are you using the iucode_tool to build the /boot/intel-ucode.cpio and then cat'ing it into a initrd.gz? Can the updating comments please be taken to the separate thread title "How to update Intel microcode" at https://www.linuxquestions.org/quest...de-4175621053/. Thanks.

bamunds --

I use the iucode_tool and the /boot/intel-ucode.cpio initrd file.

So that I don't bork things when I install a new kernel, I wrote a little wrapper script to write a script that invokes Alien Bob's /usr/share/mkinitrd/mkinitrd_command_generator.sh and then prepends the /boot/intel-ucode.cpio initrd file into the resulting initrd for the Generic Kernel.

The script and a typical session is below my .sig if you want it ( the script is .do-mkinitrd_command_generator.sh ).

When all is said and done, I end up with two initrd files, one for Generic Kernel without the intel-ucode.cpio file and one with the intel-ucode file.

Note that I 'defanged' the install step -- .do-mkinitrd_command_generator.sh prints the cp command but does not execute it.

I always cut-n-paste the cp command after I look at the output ...

Note that the OutDir Varb should be edited for your tastes and system,

Anyhow ... Don't forget to edit /etc/lilo.conf ( or elilo or grub ) after installing the new initrd file in /boot/ !

These are the stanzas for the 4.4.110 Generic and Huge Kernels along with a reminder for me.

Code:

#

######################################################################

# NOTE:  HUGE Kernel initrd = /boot/intel-ucode.cpio for ucode patch #

######################################################################

#

image    = /boot/vmlinuz-generic-4.4.110.kjh

  root  = /dev/sda3

  initrd = /boot/initrd-generic-4.4.110.kjh-ucode.gz

  label  = Linux44110G.kjh

  read-only

image    = /boot/vmlinuz-huge-4.4.110.kjh

  root  = /dev/sda3

  initrd = /boot/intel-ucode.cpio

  label  = Linux44110H.kjh

  read-only

Normally the Huge Kernel needs no initrd file.

However it does need one to load the intel microcode.

HTH.

-- kjh

I name my some of my scripts with a leading dot so that I can clean the directory with an `rm *` but not touch the scripts and configs.

.do-mkinitrd_command_generator.sh is one such script because I configured it to write the new initrd files in the `dirname $0` directory.

This is .do-mkinitrd_command_generator.sh

Code:

#!/bin/sh

#

WriteIt=0

DoUCode=1

UCodeFile="/boot/intel-ucode.cpio"



OutDir="/root/tmp/update-logs/initrd"        # edit me !  This is where stuff is written



[ "$1" = "-w" ] && WriteIt=1 && shift 



[ $# -lt 1 ] && echo "usage:  `basename $0` [ -w ] KernelVersion" >&2 && exit 1



[ "$DoUCode" = "1" -a ! -f "$UCodeFile" ] && echo "cannot find $UCodeFile ... ABORT" && exit 2



Version="$1"



UCodeInit="initrd-generic-$Version-ucode.gz"



[ ! -f "/boot/vmlinuz-generic-$Version" ] && echo "cannot find a generic kernel version $Version" >&2 && exit 3



/usr/share/mkinitrd/mkinitrd_command_generator.sh \

  -k $Version \

  -a          \

  "-o $OutDir/initrd-generic-$Version.gz"    |

  if [ "$WriteIt" != "1" ]

  then

      cat

  else

      cat > "do-mkinitrd-$Version.sh"

  fi



  if [ "$DoUCode" = "1" ]

  then

      echo "#"

      echo "# prepending the latest intel microcode as $UCodeInit"

      echo "#"

      echo "cat $UCodeFile $OutDir/initrd-generic-$Version.gz > $OutDir/$UCodeInit"

      echo "#"

      echo "echo \"# all done.\""

      echo "ls -la $OutDir/initrd-generic-$Version.gz $OutDir/$UCodeInit"

      echo "echo \"# \""

      echo "echo \"cp -vp $OutDir/initrd-generic-$Version.gz $OutDir/$UCodeInit /boot/\""

    # echo "echo \"# \""

    # echo "echo \"# check around ... if all went well, invoke the following cp command.\""

    # echo "echo \"# \""

    # echo "echo \"# cp -p $OutDir/initrd-generic-$Version.gz $OutDir/$UCodeInit /boot/\""

  fi |

  if [ "$WriteIt" != "1" ]

  then

      cat

  else

      cat >> "do-mkinitrd-$Version.sh"

      chmod 700 "do-mkinitrd-$Version.sh"



      echo "#"

      echo "# do-mkinitrd-$Version.sh is ready to run"

  fi

So ... after installing a new kernel and before I run lilo, I make a new initrd including the intel-ucode.cpio file.

My newest kernel is 4.4.110.kjh ...

Here is a session.

Code:

cd /root/tmp/update-logs/initrd

sh .do-mkinitrd_command_generator.sh -w 4.4.110.kjh

#

# do-mkinitrd-4.4.110.kjh.sh is ready to run

The .do-mkinitrd_command_generator.sh -w 4.4.110.kjh` command wrote a script to create two initrd files:

1. a Generic initrd that does not include the intel-ucode.cpio file
2. an initrd that includes the intel-ucode.cpio file and the Generic initrd ( #1 )

The generated script ( do-mkinitrd-4.4.110.kjh.sh ) is below ...

Continuing ... run the generated script ...

Code:

# sh do-mkinitrd-4.4.110.kjh.sh



OK: /lib/modules/4.4.110.kjh/kernel/drivers/usb/host/xhci-hcd.ko added.

OK: /lib/modules/4.4.110.kjh/kernel/drivers/usb/host/xhci-pci.ko added.

:

<<snip a number of kernel module lines>>

:

OK: /lib/modules/4.4.110.kjh/kernel/fs/mbcache.ko added.

OK: /lib/modules/4.4.110.kjh/kernel/fs/ext4/ext4.ko added.

42762 blocks



/root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh.gz created.

Be sure to run lilo again if you use it.

# all done.

-rw-r--r-- 1 root root 9202493 Jan  7 07:43 /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh-ucode.gz

-rw-r--r-- 1 root root 7615293 Jan  7 07:43 /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh.gz

# 

cp -vp /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh.gz /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh-ucode.gz /boot/

The last line above ( cp -vp ... ) is the command that would copy the two initrd files into /boot/

Don't forget to install your initrd files before you run lilo !

this is the generated script that actually makes the two initrd files:

Code:

#

# mkinitrd_command_generator.sh revision 1.45

#

# This script will now make a recommendation about the command to use

# in case you require an initrd image to boot a kernel that does not

# have support for your storage or root filesystem built in

# (such as the Slackware 'generic' kernels').

# A suitable 'mkinitrd' command will be:



mkinitrd -c -k 4.4.110.kjh -f ext4 -r /dev/sda3 -m xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4 -u -o /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh.gz

#

# prepending the latest intel microcode as initrd-generic-4.4.110.kjh-ucode.gz

#

cat /boot/intel-ucode.cpio /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh.gz > /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh-ucode.gz

#

echo "# all done."

ls -la /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh.gz /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh-ucode.gz

echo "# "

echo "cp -vp /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh.gz /root/tmp/update-logs/initrd/initrd-generic-4.4.110.kjh-ucode.gz /boot/"

This is the directory where I do the deed ... needs to be cleaned again but because the script is a dot-file, cleanup is simply: `rm *` :)

Code:

# ls -la



total 114772

drwxr-xr-x 2 root root  12288 Jan  7 07:43 ./

drwxr-xr-x 6 root root    4096 Jan  5 10:24 ../

-rwxr-xr-x 1 root root    1689 Sep 27 05:22 .do-mkinitrd_command_generator.sh*

-rwx------ 1 root root    1198 Dec  9 17:18 do-mkinitrd-4.4.105.kjh.sh*

-rwx------ 1 root root    1198 Dec 17 04:59 do-mkinitrd-4.4.106.kjh.sh*

-rwx------ 1 root root    1198 Dec 21 13:10 do-mkinitrd-4.4.107.kjh.sh*

-rwx------ 1 root root    1198 Dec 25 12:54 do-mkinitrd-4.4.108.kjh.sh*

-rwx------ 1 root root    1198 Jan  2 15:02 do-mkinitrd-4.4.109.kjh.sh*

-rwx------ 1 root root    1198 Jan  7 07:42 do-mkinitrd-4.4.110.kjh.sh*

-rwx------ 1 root root    1241 Sep 16 05:54 do-mkinitrd-4.4.88.sh*

-rw-r--r-- 1 root root 9202097 Dec  9 17:18 initrd-generic-4.4.105.kjh-ucode.gz

-rw-r--r-- 1 root root 7614897 Dec  9 17:18 initrd-generic-4.4.105.kjh.gz

-rw-r--r-- 1 root root 9202048 Dec 17 04:59 initrd-generic-4.4.106.kjh-ucode.gz

-rw-r--r-- 1 root root 7614848 Dec 17 04:59 initrd-generic-4.4.106.kjh.gz

-rw-r--r-- 1 root root 9202505 Dec 21 13:10 initrd-generic-4.4.107.kjh-ucode.gz

-rw-r--r-- 1 root root 7615305 Dec 21 13:10 initrd-generic-4.4.107.kjh.gz

-rw-r--r-- 1 root root 9202496 Dec 25 12:54 initrd-generic-4.4.108.kjh-ucode.gz

-rw-r--r-- 1 root root 7615296 Dec 25 12:54 initrd-generic-4.4.108.kjh.gz

-rw-r--r-- 1 root root 9202522 Jan  2 15:02 initrd-generic-4.4.109.kjh-ucode.gz

-rw-r--r-- 1 root root 7615322 Jan  2 15:02 initrd-generic-4.4.109.kjh.gz

-rw-r--r-- 1 root root 9202493 Jan  7 07:43 initrd-generic-4.4.110.kjh-ucode.gz

-rw-r--r-- 1 root root 7615293 Jan  7 07:43 initrd-generic-4.4.110.kjh.gz

-rw-r--r-- 1 root root 8917615 Sep 16 05:54 initrd-generic-4.4.88-ucode.gz

-rw-r--r-- 1 root root 7614063 Sep 16 05:54 initrd-generic-4.4.88.gz

magicm

01-07-2018 08:35 AM

I just want to clarify (or correct) an impression that I have. If one sets up a mkinitrd.conf file which has an entry for MICROCODE_ARCH, I'm assuming that the output of mkinitrd -F will be what is to be specified in the lilo initrd entry (say for a standard Slackware 'generic' kernel).

For example, if there are entries
OUTPUT_IMAGE="/boot/initrd.gz"
and
MICROCODE_ARCH="/boot/intel-ucode.cpio"
I'm assuming that conceptually
cat /boot/intel-ucode.cpio {an internal form of initrd.gz} > /boot/initrd.gz

Well, (slight embarrassment); I actually decided to read the mkinitrd script, and my impressions is correct. But I figured I'd post this here in case anyone else was unclear about it.

bamunds

01-07-2018 11:12 PM

@kjhambrick, thank you for the great write-up and examples. I wasn't aware the huge kernel didn't need an initrd. I'm studying your script to see where I need to change it to allow me to use it every couple of months with the latest 4.4.x kernel, rather than with Pat's latest official release. I like the idea of scripts! Although I'm not a programmer I seem to be able to read and understand the logic of them, although the variables sometimes confuse me. Is there a reason you haven't used a mkinitrd.conf for some of the variables? Darth Vader suggested modifying that file to assure the intel-ucode.cpio is actually included in the initrd, which makes sense. I'll be working on this more tomorrow. Again thanks. Cheers

kjhambrick

01-08-2018 07:17 AM

Quote:

Originally Posted by bamunds (Post 5803482)

@kjhambrick, thank you for the great write-up and examples. I wasn't aware the huge kernel didn't need an initrd.

bamunds --

The HUGE Kernel does not need an initrd UNLESS you need to load the intel-ucode.cpio file or maybe some module that Pat did not compile into HUGE ...

I used to run HUGE because I was lazy ( no need for an initrd ) and because I was old and set in my ways :)

But since the Intel ME Bug and now that I need to load intel-ucode.cpio, I no longer run HUGE, I've gone GENERIC.

Quote:

I'm studying your script to see where I need to change it to allow me to use it every couple of months with the latest 4.4.x kernel, rather than with Pat's latest official release. I like the idea of scripts! Although I'm not a programmer I seem to be able to read and understand the logic of them, although the variables sometimes confuse me.

Yes, a lot of my admin scripts are simply cut-n-paste lists of commands that worked for me copied to a text file.

Sometimes I clean them up a little and add variables or flags but quite often they're just the working sequence of commands in a text file.

I like scripts in these cases so I don't forget steps or mis-type a command ...

Quote:

Is there a reason you haven't used a mkinitrd.conf for some of the variables? Darth Vader suggested modifying that file to assure the intel-ucode.cpio is actually included in the initrd, which makes sense. I'll be working on this more tomorrow. Again thanks. Cheers

Yes, there are better ways to do what I am doing now ( /etc/mkinitrd.conf ) and there is also a -P option for mkinitrd so that you can pass the microcode cpio archive to mkinitrd ( man mkinitrd ).

But the scripts work for me and being old and set in my ways, I'll keep doing it the way I do it until it breaks :) :)

HTH

-- kjh

BratPit

01-08-2018 10:14 AM

Quote:

Originally Posted by kjhambrick (Post 5803586)

Solution for HUGE but not only .

Recompile with this options /change to your firmware module name/

Quote:

Device Drivers --->
Generic Driver Options --->[*] Include in-kernel firmware blobs in kernel binary
(intel-ucode/06-3c-03) External firmware blobs to build into the kernel binary
(/lib/firmware/) Firmware blobs root directory

if you do not know which microcode module is for your processor:

Quote:

iucode_tool -S -l /lib/firmware/intel-ucode/*
iucode_tool: system has processor(s) with signature 0x000306c3
[...]
microcode bundle 49: /lib/firmware/intel-ucode/06-3c-03
[...]
selected microcodes:
049/001: sig 0x000306c3, pf_mask 0x32, 2017-12-10, rev 0x0023, size 22528

, and it autoload early like from initrd :)

I do not know if this option is in 4.4 kernel but in 4.9 is and work.

bamunds

01-08-2018 10:28 AM

@Kjhambrick, I ran across your summer 2017 thread which has examples of how-to upgrade microcode and the patch resulting to allow an easy upgrade. Linking here for more insight and examples for those looking to update their microcode. Also thanks to phenexia2003 for the patch that allows a flag to mkinitrd which simplifies this. https://www.linuxquestions.org/quest...rs-4175608636/

It would be really great to see a docs.slackware.com article on "How to Update Intel Microcode" which captures all these ideas and suggestions but written by a senior Slackware member who really understands the different options and can describe the different paths for those using LTS kernels.

PS I read Greg K-H's Meltdown article last night and it appears that Meltdown and Spectre are only going to be addressed only on LTS kernels 4.4, 4.9, 4.14, although 4.15 is not yet LTS it is being worked on for Meltdown.

keefaz

01-08-2018 11:33 AM

Using debian archive, I created quickly initrd with simple procedure:

Code:

cd intel-microcode-3.20171215.1

mkdir tmp

# my processor is i5-4570, signature 0x306c3

iucode_tool -Ktmp tmp supplementary-ucode-CVE-2017-5715.d/s000306C3_m00000032_r00000023.fw

cd tmp

iucode_tool --write-earlyfw=intel-ucode.cpio 06-3c-03

cp intel-ucode.cpio /boot/efi/EFI/Slackware/

Then I edited elilo.conf and added the initrd line, rebooted
now microcode is updated to 0x23 version

Code:

[    0.000000] microcode: CPU0 microcode updated early to revision 0x23, date = 2017-11-20

...

...

But it seems the processor is still vulnerable to spectre, using the c programm floating around I get

Code:

Reading 40 bytes:

Reading at malicious_x = 0xffffffffffdfec80... Success: 0x54='T' score=2

Reading at malicious_x = 0xffffffffffdfec81... Success: 0x68='h' score=2

Reading at malicious_x = 0xffffffffffdfec82... Success: 0x65='e' score=2

...

BratPit

01-08-2018 12:31 PM

Try this tool

https://raw.githubusercontent.com/sp...own-checker.sh

Your microcode only does Mitigation 1 from CVE-2017-5715.
The rest is open.

Quote:

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Kernel compiled with LFENCE opcode inserted at the proper places: UNKNOWN (couldn't find your kernel image in /boot, if you used netboot, this is normal)
> STATUS: UNKNOWN

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Hardware (CPU microcode) support for mitigation: YES
* Kernel support for IBRS: NO
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* Mitigation 2
* Kernel compiled with retpoline option: NO
* Kernel compiled with a retpoline-aware compiler: UNKNOWN (couldn't find your kernel image)
> STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)

I do not know why not see my /boot/vmlinuz in variant 1 check ?

keefaz

01-08-2018 01:36 PM

Quote:

Originally Posted by BratPit (Post 5803696)

Try this tool

https://raw.githubusercontent.com/sp...own-checker.sh

Your microcode only does Mitigation 1 from CVE-2017-5715.
The rest is open.

I do not know why not see my /boot/vmlinuz in variant 1 check ?

Thanks, after a slight modification in script, I got:

Code:

Spectre and Meltdown mitigation detection tool v0.16



Checking vulnerabilities against Linux 4.4.110 #1 SMP Fri Jan 5 22:17:16 CET 2018 x86_64



CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'

* Kernel compiled with LFENCE opcode inserted at the proper places:  NO  (only 53 opcodes found, should be >= 70)

> STATUS:  VULNERABLE 



CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'

* Mitigation 1

*  Hardware (CPU microcode) support for mitigation:  YES 

*  Kernel support for IBRS:  NO 

*  IBRS enabled for Kernel space:  NO 

*  IBRS enabled for User space:  NO 

* Mitigation 2

*  Kernel compiled with retpoline option:  NO 

*  Kernel compiled with a retpoline-aware compiler:  NO 

> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)



CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'

* Kernel supports Page Table Isolation (PTI):  YES 

* PTI enabled and active:  YES 

> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

Script modification (added XXX to temp file template name)

Code:

--- spectre-meltdown-checker.sh    2018-01-08 20:18:36.836828923 +0100

+++ spectre-meltdown-checker.new.sh    2018-01-08 20:27:48.534863440 +0100

@@ -64,7 +64,7 @@

 {

    [ -n "$1" ] || return 1

    # Prepare temp files:

-    vmlinuxtmp="$(mktemp /tmp/vmlinux-XXX)"

+    vmlinuxtmp="$(mktemp /tmp/vmlinux-XXXXXX)"

 

    # Initial attempt for uncompressed images or objects:

    if check_vmlinux "$1"; then

Emerson

01-08-2018 01:44 PM

Why not build the microcode into kernel? Simple, works for me. Or this would not be the Slackware way? Just curious.

BratPit

01-08-2018 01:48 PM

Quote:

Originally Posted by keefaz (Post 5803719)

Thanks, after a slight modification in script, I got:

Code:

Which does not change the fact that this mitigation microcode does not prevent spectre PoC :(

kjhambrick

01-08-2018 01:57 PM

Quote:

Originally Posted by bamunds (Post 5803649)

Yikes !

Not only am I old and set in my ways, but I am old and forgetful too !

I honestly forgot all about that thread.

Thanks for bringing it up ... it was a good one :)

-- kjh

Darth Vader

01-08-2018 01:59 PM

Quote:

Originally Posted by Emerson (Post 5803724)

Why not build the microcode into kernel? Simple, works for me. Or this would not be the Slackware way? Just curious.

Because not all people use the overpriced Intellicrap?

bassmadrigal

01-08-2018 02:24 PM

Quote:

Originally Posted by bamunds (Post 5803649)

although 4.15 is not yet LTS it is being worked on for Meltdown.

4.15 won't be an LTS kernel. It will become the latest stable, but that will be supplanted by 4.16 and then 4.17 and on. Non-LTS kernels are usually only supported for around 3 months before they EOL them and expect users to move to the next stable kernel.

LTS kernels are specifically selected to have a longer than normal life of updates -- now up to six years of updates, but only 4.4 and 4.14 will have that 6 years. 4.9 was stuck with the old LTS policy of updates for 2 years. We don't know what kernels will be LTS kernels until it is announced by a kernel developer, usually Greg Kroah-Hartman.

I'm actually kinda surprised that 4.1 isn't getting the updates (or maybe it is and I'm just not aware of it), because it won't be EOL until May 2018. Other than that, 4.4, 4.9, 4.14, and 4.15 are the only maintained kernels by kernel developers. All other kernels versions have been EOLed and probably won't see official updates for these vulnerabilities.

kjhambrick

01-08-2018 02:33 PM

Quote:

Originally Posted by bassmadrigal (Post 5803750)

<<snip>> ...

I'm actually kinda surprised that 4.1 isn't getting the updates (or maybe it is and I'm just not aware of it), because it won't be EOL until May 2018. Other than that, 4.4, 4.9, 4.14, and 4.15 are the only maintained kernels by kernel developers. All other kernels versions have been EOLed and probably won't see official updates for these vulnerabilities.

bassmadrigal --

The 4.1 Kernel is maintained by Sasha Levin and maybe there is more foundation code to back-port into 4.1 than 4.4, etc ???

Just guessing ...

-- kjh

From the 4.1.48 ChangeLog:

Code:

commit 0199619b21f7320482e8a2db14cf8bc974a7766a

Author: Sasha Levin <alexander.levin@verizon.com>

Date:  Tue Dec 12 10:21:44 2017 -0500



    Linux 4.1.48

    

    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

Emerson

01-08-2018 02:37 PM

Quote:

Originally Posted by Darth Vader (Post 5803736)

Because not all people use the overpriced Intellicrap?

So you build only AMD microcode into kernel?

Darth Vader

01-08-2018 02:51 PM

Quote:

Originally Posted by Emerson (Post 5803757)

So you build only AMD microcode into kernel?

Neither. The AMD microcodes could be loaded well from a running system.

abga	01-08-2018 03:02 PM

Wouldn't it be neat to have all this knowledge packed in AlienBoB's Live Slackware image? Obviously, approved from "above". It'll help a lot of people and will definitely make Slackware more popular. Just a tough.

bamunds

01-08-2018 03:33 PM

@keefaz I've tried to use that script and the first test is always failing as "couldn't find your kernel image in /boot,.."
My kernel responds to uname -r as '4.4.106-ba'. I saw where you suggested modifying line 113 of the script, but I've tried that and actually gone to a full 10 X's and it still doesn't recognize the kernel. The /boot/vmlinuz is a symlink to vmlinuz-custom-4.4.106 image on my machine. Any suggestions? Thanks

bamunds

01-08-2018 03:36 PM

Quote:

Originally Posted by abga (Post 5803771)

Actually it would be great to have this on the docs.slackware.com page as "How to upgrade Intel microcode". Then future questions on LQ could be referenced to that article. I know @AlienBob also has a blog and he too has some nice write-ups but I believe this subject to be outside just the LiveSlak interest group.

Since the intent of this article was to guide me on how to properly upgrade Intel microcode, please move issues of latest kernel to that thread and issues of how to address Meltdown or Spectre to the Slackware security thread. Sorry about hi-jacking my own thread with the earlyier "PS about LTS support for Meltdown and Spectre" ouch. Maybe the test script suggestion could also be moved there please!

keefaz

01-08-2018 04:54 PM

Quote:

Originally Posted by bamunds (Post 5803780)

You have to use just 6 Xs for mktemp

Code:

 

man mktemp

... 

The  mktemp  utility takes the given filename template and overwrites a

      portion of it to create a unique filename.  The  template  may  be  any

      filename  with  six  (6)  `Xs'  appended  to  it,  for  example

      /tmp/tfile.XXXXXX.

For the kernel filename, just write it in the script after it tests for files in /boot, eg add this line

Code:

[ -e /boot/vmlinuz-linux      ] && img=/boot/vmlinuz-linux

[ -e /boot/vmlinuz-$(uname -r) ] && img=/boot/vmlinuz-$(uname -r)

[ -e /boot/kernel-$( uname -r) ] && img=/boot/kernel-$( uname -r)

[ -e /boot/bzImage-$(uname -r) ] && img=/boot/bzImage-$(uname -r)

[ -e /boot/kernel-genkernel-$(uname -m)-$(uname -r) ] && img=/boot/kernel-genkernel-$(uname -m)-$(uname -r)

img=/boot/vmlinuz-custom-4.4.106

...

bamunds

01-08-2018 05:01 PM

Quote:

Originally Posted by keefaz (Post 5803812)

You have to use just 6 Xs for mktemp

Code:

[ -e /boot/kernel-genkernel-$(uname -m)-$(uname -r) ] && img=/boot/kernel-genkernel-$(uname -m)-$(uname -r)

img=/boot/vmlinuz-custom-4.4.106

...

Thanks, the added image file did the trick. This is a nice script tool for testing, it should be added to the Greg K-H discussion about Meltdown and Spectre https://www.linuxquestions.org/quest...el-4175621133/so others are aware of it.

Petri Kaukasoina

01-09-2018 12:08 AM

Quote:

Originally Posted by bassmadrigal (Post 5803750)

I'm actually kinda surprised that 4.1 isn't getting the updates (or maybe it is and I'm just not aware of it), because it won't be EOL until May 2018. Other than that, 4.4, 4.9, 4.14, and 4.15 are the only maintained kernels by kernel developers. All other kernels versions have been EOLed and probably won't see official updates for these vulnerabilities.

3.2.98 also got the patches.

bamunds

01-09-2018 11:35 PM

Hmm, Intel's latest microcode available is dated 20180108. Pulled it from their download site earlier linked in this thread. I then modified the intel-microcode.SlackBuild to reference the new file and executed the SlackBuild. That placed a new intel-ucode.cpio in /boot and built a package which was then installed. Then issued

Code:

#cat /boot/intel-ucode.cpio /boot/initrd-custom-4.4.110.gz > /boot/initrd-custom-4.4.110_ucode.gz

and rebooted. But when dmesg is checked it doesn't show any new microcode loading. So checked the download and the 0xf47 file (0F-04-07) is included with a new date. On the Greg K-H thread it is noted that Intel is working on CPU's upto five years old.

Appears nothing new is loading at this time. Expected to see results with microcode date of 01/08/2018. The Intel releasenote mention resetting the reload, which the intel-microcode slackbuild does NOT mentioin. Did I miss a step?

Or will results only appear if new microcode is actually changed?

Trouble shooting advice appreciated. Cheers

nobodino

01-10-2018 12:38 AM

official Intel microcode update: https://downloadcenter.intel.com/dow...e-20180108.tgz

kjhambrick

01-10-2018 06:25 AM

Thanks for the head's up bamunds and nobodino

I've built and installed 2018-01-08 but I'm still building 4.4.111 so I'll boot it later.

This is my current running intel-ucode version from 2017-11-17:

Code:

# dmesg -t |grep -m1 microcode



microcode: CPU0 microcode updated early to revision 0xba, date = 2017-04-09

The release notes so show that I should bump from revision 0xba to 0xc2 ...

My new kernel is ready to install so here we go ... will report back.

EDIT: Back on the air with 4.4.111 + intel-microcode 2018-01-08 and the NVIDIA-Linux-x86_64-384.98.run blob.

My intel-ucode revision is now:

Code:

# dmesg -t |grep -m1  microcode 



microcode: CPU0 microcode updated early to revision 0xc2, date = 2017-11-16

-- kjh

Code:

# cat releasenote



Intel Processor Microcode Package for Linux

20180108 Release



-- Updates upon 20171117 release --

IVT C0          (06-3e-04:ed) 428->42a

SKL-U/Y D0      (06-4e-03:c0) ba->c2

BDW-U/Y E/F    (06-3d-04:c0) 25->28

HSW-ULT Cx/Dx  (06-45-01:72) 20->21

Crystalwell Cx  (06-46-01:32) 17->18

BDW-H E/G      (06-47-01:22) 17->1b

HSX-EX E0      (06-3f-04:80) 0f->10

SKL-H/S R0      (06-5e-03:36) ba->c2

HSW Cx/Dx      (06-3c-03:32) 22->23

HSX C0          (06-3f-02:6f) 3a->3b

BDX-DE V0/V1    (06-56-02:10) 0f->14

BDX-DE V2      (06-56-03:10) 700000d->7000011

KBL-U/Y H0      (06-8e-09:c0) 62->80

KBL Y0 / CFL D0 (06-8e-0a:c0) 70->80

KBL-H/S B0      (06-9e-09:2a) 5e->80

CFL U0          (06-9e-0a:22) 70->80

CFL B0          (06-9e-0b:02) 72->80

SKX H0          (06-55-04:b7) 2000035->200003c

GLK B0          (06-7a-01:01) 1e->22



-- Microcode update instructions --

This package contains Intel microcode files in two formats:

* microcode.dat

* intel-ucode directory 



microcode.dat is in a traditional text format. It is still used in some

Linux distributions. It can be updated to the system through the old microcode

update interface which is avaialble in the kernel with

CONFIG_MICROCODE_OLD_INTERFACE=y.



To update the microcode.dat to the system, one need:

1. Ensure the existence of /dev/cpu/microcode

2. Write microcode.dat to the file, e.g.

  dd if=microcode.dat of=/dev/cpu/microcode bs=1M



intel-ucode dirctory contains binary microcode files named in

family-model-stepping pattern. The file is supported in most modern Linux

distributions. It's generally located in the /lib/firmware directory,

and can be updated throught the microcode reload interface.



To update the intel-ucode package to the system, one need:

1. Ensure the existence of /sys/devices/system/cpu/microcode/reload

2. Copy intel-ucode directory to /lib/firmware, overwrite the files in

/lib/firmware/intel-ucode/

3. Write the reload interface to 1 to reload the microcode files, e.g.

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

bassmadrigal

01-10-2018 06:49 AM

Quote:

Originally Posted by bamunds (Post 5804475)

Code:

#cat /boot/intel-ucode.cpio /boot/initrd-custom-4.4.110.gz > /boot/initrd-custom-4.4.110_ucode.gz

What do you have in your lilo.conf (or elilo.conf)? Do you have a reference to your initrd in there?

kjhambrick

01-10-2018 07:14 AM

Quote:

Originally Posted by bamunds (Post 5804475)

Code:

#cat /boot/intel-ucode.cpio /boot/initrd-custom-4.4.110.gz > /boot/initrd-custom-4.4.110_ucode.gz

bamunds --

I wonder what your CPU Family, Model, Stepping is ?

And is there a new file for that set of CPU Parameters in /lib/firmware/intel-ucode/ which was installed with your modified intel-microcode.SlackBuild ?

This is the file for my CPU ( i7 6700K ):

Code:

# ls -la /lib/firmware/intel-ucode/`./.get-my-cpu-f-m-s.sh`



-rw-r--r-- 1 root root 99328 Jan 10 06:25 /lib/firmware/intel-ucode/06-5e-03

Note the .get-my-cpu-f-m-s.sh script in the command line !

The script is below my sig.

This is the output for my CPU:

Code:

# ./.get-my-cpu-f-m-s.sh



06-5e-03

HTH

-- kjh

This is .get-my-cpu-f-m-s.sh ... it lives in my intel-microcode SlackBuild Directory:

Not much to it and my `gawk` programming style annoys purists, the fanciest thing it does is print the /proc/cpuinfo Family, Model, Stepping data as Hex.

Code:

!/bin/sh



gawk '

BEGIN {



  FS = ":"



  F = M = S = N = 0



  # cpu family      : 6

  # model          : 94

  # stepping        : 3



}

{

  if ( match( $1, /^cpu family[\t ]*$/ ))

  {

      F = $2 +0



      if (( ++N ) >= 3 )

      {

        exit( 0 )

      }

      next

  }

  if ( match( $1, /^model[\t ]*$/ ))

  {

      M = $2 +0



      if (( ++N ) >= 3 )

      {

        exit( 0 )

      }

      next

  }

  if ( match( $1, /^stepping[\t ]*$/ ))

  {

      S = $2 +0



      if (( ++N ) >= 3 )

      {

        exit( 0 )

      }

      next

  }

  if ( N >= 3 )

  {

      exit( 0 )

  }

}

END {



  if ( N >= 3 )

  {

    printf( "%02x-%02x-%02x\n", F, M, S )

    exit 0

  }

  print ""

  exit 1

    

}' /proc/cpuinfo

keefaz

01-10-2018 07:22 AM

Quote:

Originally Posted by bamunds (Post 5804475)

Code:

#cat /boot/intel-ucode.cpio /boot/initrd-custom-4.4.110.gz > /boot/initrd-custom-4.4.110_ucode.gz

Please post output with:

Code:

dmesg | grep microcode

awk '

/family/ {f=sprintf("%02X",$4)}

/model/ && $2 != "name"{m=sprintf("%02X",$3)}

/stepping/{s=sprintf("%02X",$3)}

END{print f"-"m"-"s}

' /proc/cpuinfo

edit:
Posted before reading kjhambrick reply :)

Petri Kaukasoina

01-10-2018 08:05 AM

Quote:

Originally Posted by bamunds (Post 5804475)

Then issued

Code:

#cat /boot/intel-ucode.cpio /boot/initrd-custom-4.4.110.gz > /boot/initrd-custom-4.4.110_ucode.gz

and rebooted. But when dmesg is checked it doesn't show any new microcode loading.

Did you forget to run lilo?

sramov

01-10-2018 08:20 AM

Quote:

Originally Posted by bamunds (Post 5804475)

Or will results only appear if new microcode is actually changed?

Yes, depending on your CPU, you might not see new ucode loaded if there are no updates for it, even if you did build a new initrd with the new microcode release.

For example this is the output when I applied the latest Intel microcode (20180108):

Code:

% sudo dmesg | grep microcode 

[    0.000000] microcode: microcode updated early to revision 0x23, date = 2017-11-20

[    3.657018] microcode: sig=0x306c3, pf=0x2, revision=0x23

[    3.657198] microcode: Microcode Update Driver: v2.2.

Before that it was at 0x22. It was at 0x22 over more than few microcode updates so only if there's something applicable to your CPU, it will be updated, if not there will be no change even if you did everything properly with the initrd.

PROBLEMCHYLD

01-10-2018 09:48 AM

Quote:

Originally Posted by kjhambrick (Post 5804585)

Code:

-- Microcode update instructions --

This package contains Intel microcode files in two formats:

* microcode.dat

* intel-ucode directory 



microcode.dat is in a traditional text format. It is still used in some

Linux distributions. It can be updated to the system through the old microcode

update interface which is avaialble in the kernel with

CONFIG_MICROCODE_OLD_INTERFACE=y.



To update the microcode.dat to the system, one need:

1. Ensure the existence of /dev/cpu/microcode

2. Write microcode.dat to the file, e.g.

  dd if=microcode.dat of=/dev/cpu/microcode bs=1M



intel-ucode dirctory contains binary microcode files named in

family-model-stepping pattern. The file is supported in most modern Linux

distributions. It's generally located in the /lib/firmware directory,

and can be updated throught the microcode reload interface.



To update the intel-ucode package to the system, one need:

1. Ensure the existence of /sys/devices/system/cpu/microcode/reload

2. Copy intel-ucode directory to /lib/firmware, overwrite the files in

/lib/firmware/intel-ucode/

3. Write the reload interface to 1 to reload the microcode files, e.g.

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

Method 1

Does not work at all for me. The output listed

Code:

[root@darkstar:~] # dd if=microcode.dat of=/dev/cpu/microcode bs=1M

dd: error writing '/dev/cpu/microcode': Invalid argument

1+0 records in

0+0 records out

0 bytes copied, 0.0441653 s, 0.0 kB/s

Method 2

Does work for me, but it reverts after reboot. The output listed

Code:

[root@darkstar:~] # dmesg | grep microcode

[    1.215860] microcode: sig=0x6fd, pf=0x80, revision=0xa3

[    1.219124] microcode: Microcode Update Driver: v2.2.

[root@darkstar:~] # echo 1 > /sys/devices/system/cpu/microcode/reload

[root@darkstar:~] # dmesg | grep microcode

[    1.215860] microcode: sig=0x6fd, pf=0x80, revision=0xa3

[    1.219124] microcode: Microcode Update Driver: v2.2.

[  184.140222] microcode: updated to revision 0xa4, date = 2010-10-02

Here is my lilo.conf, how do I make it stick?

Code:

  append="vt.default_utf8=1"

  boot=/dev/sda

  compact

  bitmap=/boot/slack.bmp

  bmp-colors=255,0,255,0,255,0

  bmp-table=60,6,1,16

  bmp-timer=65,27,0,255

  prompt

  change-rules

  reset

  vga=773

image=/dmt/live/vmlinuz

  root=/dev/sda1

  label=0.30.0

  append="boot=live config union=overlay noswap noprompt ip=frommedia live-media-path=/dmt/live bootfrom=/dev/sda1 toram=filesystem.squashfs video=SVIDEO-1:d" 

  vga=788

  initrd=/dmt/live/initrd.img

image=/boot/vmlinuz-generic-smp-4.14.12-smp

  initrd=/boot/initrd_4.14.12-smp.gz

  root=/dev/sda1

  label=4.14.12

  append="resume=/dev/sda2 video=SVIDEO-1:d"

  read-only

kjhambrick

01-10-2018 11:21 AM

PROBLEMCHYLD --

I posted the releasenote only to show which processors were updated.

I suppose you can make things work following Intel's generic instructions ...

However, for Slackware users, Alexander Verbovetsky ( iucode_tool ) and Andrzej Telszewski ( intel_microcode ) have made it easy-peasy !

Download these two SlackBuilds from SBo:

1. System/iucode_tool
2. System/intel-microcode

Read the README Files !

Then build and install them in this order:

1. iucode_tool
2. intel-microcode

At this point you'll have a /boot/intel-ucode.cpio initrd file, something like this:

Code:

# ls -la /boot/intel-ucode.cpio



-rw-r--r-- 1 root root 1614848 Jan 10 06:25 /boot/intel-ucode.cpio

The /boot/intel-ucode.cpio file may be prepended to your existing, working initrd file(s) !

I am not exactly sure what you're doing in the first stanza of your lilo.conf ( your default ), but the 2nd entry looks familiar.

And to be safe, rather than replace you existing initrd file and lilo stanza, I would hedge my bets and make a new initrd for the one in your 2nd stanza:

Code:

# cat /boot/intel-ucode.cpio /boot/initrd_4.14.12-smp.gz > /boot/initrd_4.14.12-smp-ucode.gz

Then add a new Stanza to your /etc/lilo.conf that looks like this:

Code:

image=/boot/vmlinuz-generic-smp-4.14.12-smp

  initrd=/boot/initrd_4.14.12-smp-ucode.gz

  root=/dev/sda1

  label=4.14.12u

  append="resume=/dev/sda2 video=SVIDEO-1:d"

  read-only

Rerun lilo, reboot and select the 4.14.12u entry.

That outta do it !

HTH.

-- kjh

mralk3

01-10-2018 11:24 AM

The simplest way to append the microcode to an initrd is to use the /etc/mkinitrd.conf. My previous post, (post #4 of this thread) simplifies the process by far. I think that this method should be the recommended way to apply the microcode to a initrd because its the simplest and most fool proof method for newbies and advanced users alike. However, I do realize everyone has their own way of doing things but something is getting lost in translation. Remember, K.I.S.S. principle.

Using the 'cat' command isn't necessary to do any of this. Pat and team simplified the process for us with the mkinitrd.conf. A wrapper script for mkinitrd_command_generator.sh isn't necessary either if you use the mkinitrd.conf.

keefaz

01-10-2018 11:25 AM

Quote:

Originally Posted by PROBLEMCHYLD (Post 5804686)

Here is my lilo.conf, how do I make it stick?

Best way it to make ramfs image imho.
iucode_tool has to be installed from sbo / Slackbuilds

Then, infos from /proc/cpuinfo will give you the correct microcode filename (see awk code above)

Once you know the correct microcode file, the easiest way to make the ramfs image is:

Code:

iucode_tool --write-earlyfw=/boot/intel-ucode.cpio /path/to/microcode_file

If you have already an initrd you have to merge it with intel-ucode.cpio image

Code:

cd /boot

cat intel-ucode.cpio initrd.gz > initrd-merged.gz

Then replace initrd.gz with initrd-merged.gz in lilo.conf

Edit: Wow posted too late again :/

kjhambrick

01-10-2018 11:45 AM

Quote:

Originally Posted by mralk3 (Post 5804723)

Very good points mralk3.

I set all this up before phenexia submitted the mkinitrd -P arg patch https://www.linuxquestions.org/quest...6/#post5727883 and before it was released for Slackware 14.2.

And then I wasn't aware of the /etc/mkinitrd.conf file.

It's time for me to retire the old scripts I wrote and get with the program ( or at least keep them to myself :) ).

Thanks !

-- kjh

mralk3

01-10-2018 12:04 PM

Quote:

Originally Posted by kjhambrick (Post 5804740)

Very good points mralk3.

..snip..

It's time for me to retire the old scripts I wrote and get with the program ( or at least keep them to myself :) ).

Yeah I wasn't trying to rain on anyone's parade.

I would also like to point out that SBo has pushed an update out for this week early which includes the latest intel microcode:

https://git.slackbuilds.org/slackbui...74064919242c48

PROBLEMCHYLD

01-10-2018 12:31 PM

Quote:

Originally Posted by kjhambrick (Post 5804740)

Thanks, but neither method works for me. I've installed the 2 necessary packages. The file DoNOT end up in the /boot/ directory.

Code:

[root@darkstar:~] # ls -la /boot/intel-ucode.cpio

ls: cannot access '/boot/intel-ucode.cpio': No such file or directory

kjhambrick

01-10-2018 12:47 PM

Quote:

Originally Posted by PROBLEMCHYLD (Post 5804763)

Thanks, but neither method works for me. I've installed the 2 necessary packages. The file DoNOT end up in the /boot/ directory.

Code:

[root@darkstar:~] # ls -la /boot/intel-ucode.cpio

ls: cannot access '/boot/intel-ucode.cpio': No such file or directory

Odd ...

What do you see if you type the following command ?

Code:

# ls -lartd /var/log/packages/{iucode_tool,intel-microcode}*

-- kjh

Here's mine:

Code:

# ls -lartd /var/log/packages/{iucode_tool,intel-microcode}*



-rw-r--r-- 1 root root 1229 Sep 11 07:03 /var/log/packages/iucode_tool-2.2-x86_64-1_SBo

-rw-r--r-- 1 root root 4209 Jan 10 06:25 /var/log/packages/intel-microcode-20180108-noarch-1_SBo

mralk3

01-10-2018 12:49 PM

Quote:

Originally Posted by PROBLEMCHYLD (Post 5804763)

Thanks, but neither method works for me. I've installed the 2 necessary packages. The file DoNOT end up in the /boot/ directory.

Code:

[root@darkstar:~] # ls -la /boot/intel-ucode.cpio

ls: cannot access '/boot/intel-ucode.cpio': No such file or directory

If you install intel-microcode before you install iucode_tool, then /boot/intel-ucode.cpio will not exist. Install first iucode_tool, and following that, install intel-microcode.

The relevant part in the intel-microcode SlackBuild is:

Code:

mkdir -p $PKG/lib/firmware

cp -a microcode.dat $PKG/lib/firmware



if [ -x /usr/sbin/iucode_tool ]; then

  mkdir -p $PKG/lib/firmware/intel-ucode

  /usr/sbin/iucode_tool -v --list-all -K$PKG/lib/firmware/intel-ucode microcode.dat

  mkdir -p $PKG/boot

  /usr/sbin/iucode_tool -v --write-earlyfw=$PKG/boot/intel-ucode.cpio microcode.dat

fi

If you do it in the wrong order, the file in /boot will not be present.

All times are GMT -5. The time now is 10:09 AM.

Page 1 of 4

Last »

Show 50 post(s) from this thread on one page