Early loading of microcode updates with all firmware

Early loading of microcode updates with all firmware

[Paul Menzel]

Dear Borislav,


Thank you for recently updating the document *Early load microcode* [1].

My goal is to include all microcode updates from AMD and Intel, as the 
image is supposed to run on several systems.

Therefore, I included the files in the initramfs image, under 
`/lib/firmware`, and selected the microcode related Kconfig options.

```
$ grep MICROCODE /boot/config-4.11.7.mx64.161
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
```

But, the microcode is not updated. For example, I have to manually run 
the command below.

```
$ echo 1 | sudo tee /sys/devices/system/cpu/microcode/reload
```

Reading the document, that method is not explicitly mentioned there, so 
I guess it’s not supported.

So two question. If I want to add it to the initramfs image, the 
document says to prepend the updates. But I am unclear how to create 
`microcode.bin` to contain all the files in 
`/lib/firmware/intel-ucode/`, and then the ones for AMD devices. Do I 
just concatenate both?

Regarding the section *Builtin microcode*, it would be quite cumbersome 
to list all the microcode files. It looks like wildcards like `*` are 
not supported. At least the build breaks, if `intel-ucode/*` is used in 
the prompt.


Kind regards,

Paul


[1] https://www.kernel.org/doc/Documentation/x86/early-microcode.txt

Re: Early loading of microcode updates with all firmware

[Borislav Petkov]

Dear Paul,

On Fri, Jun 30, 2017 at 12:44:43PM +0200, Paul Menzel wrote:
> But, the microcode is not updated. For example, I have to manually run the
> command below.

Yes, you need something in userspace to trigger that reload.

> Reading the document, that method is not explicitly mentioned there, so I
> guess it’s not supported.

Note the "early" in that file's name.

And that method is supported - it is the late loading method. I could
rename that file to microcode.txt and document all the loading methods
there. Here's a TODO list item...

> So two question. If I want to add it to the initramfs image, the document
> says to prepend the updates. But I am unclear how to create `microcode.bin`
> to contain all the files in `/lib/firmware/intel-ucode/`, and then the ones
> for AMD devices. Do I just concatenate both?

Here's a script I'm using, it should make it all clear:

---
#!/bin/bash

if [ -z "$1" ]; then
    echo "You need to supply an initrd file"
    exit 1
fi

INITRD="$1"

DSTDIR=kernel/x86/microcode
TMPDIR=/tmp/initrd

rm -rf $TMPDIR

mkdir $TMPDIR
cd $TMPDIR
mkdir -p $DSTDIR

if [ -d /lib/firmware/amd-ucode ]; then
	cat /lib/firmware/amd-ucode/microcode_amd*.bin > $DSTDIR/AuthenticAMD.bin
fi

if [ -d /lib/firmware/intel-ucode ]; then
	cat /lib/firmware/intel-ucode/* > $DSTDIR/GenuineIntel.bin
fi

find . | cpio -o -H newc >../ucode.cpio
cd ..
mv $INITRD $INITRD.orig
cat ucode.cpio $INITRD.orig > $INITRD

rm -rf $TMPDIR
---

You can adjust the regex selecting the Intel files to something more
restrictive as you don't want to carry everything in your initrd. Not
that putting every microcode file in the initrd doesn't work - it does
just fine.

> Regarding the section *Builtin microcode*, it would be quite cumbersome to
> list all the microcode files. It looks like wildcards like `*` are not
> supported. At least the build breaks, if `intel-ucode/*` is used in the
> prompt.

Yes, you need to list them one-by-one.

I wouldn't use that method though as it means you need to rebuild the
kernel when there's a new microcode. So stick to the initrd instead.

HTH.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: Early loading of microcode updates with all firmware

[Paul Menzel]

Dear Borislav,


On 06/30/17 13:37, Borislav Petkov wrote:

> On Fri, Jun 30, 2017 at 12:44:43PM +0200, Paul Menzel wrote:
>> But, the microcode is not updated. For example, I have to manually run the
>> command below.
> 
> Yes, you need something in userspace to trigger that reload.
> 
>> Reading the document, that method is not explicitly mentioned there, so I
>> guess it’s not supported.
> 
> Note the "early" in that file's name.
> 
> And that method is supported - it is the late loading method. I could
> rename that file to microcode.txt and document all the loading methods
> there. Here's a TODO list item...
> 
>> So two question. If I want to add it to the initramfs image, the document
>> says to prepend the updates. But I am unclear how to create `microcode.bin`
>> to contain all the files in `/lib/firmware/intel-ucode/`, and then the ones
>> for AMD devices. Do I just concatenate both?
> 
> Here's a script I'm using, it should make it all clear:
> 
> ---
> #!/bin/bash
> 
> if [ -z "$1" ]; then
>      echo "You need to supply an initrd file"
>      exit 1
> fi
> 
> INITRD="$1"
> 
> DSTDIR=kernel/x86/microcode
> TMPDIR=/tmp/initrd
> 
> rm -rf $TMPDIR
> 
> mkdir $TMPDIR
> cd $TMPDIR
> mkdir -p $DSTDIR
> 
> if [ -d /lib/firmware/amd-ucode ]; then
> 	cat /lib/firmware/amd-ucode/microcode_amd*.bin > $DSTDIR/AuthenticAMD.bin
> fi
> 
> if [ -d /lib/firmware/intel-ucode ]; then
> 	cat /lib/firmware/intel-ucode/* > $DSTDIR/GenuineIntel.bin
> fi
> 
> find . | cpio -o -H newc >../ucode.cpio
> cd ..
> mv $INITRD $INITRD.orig
> cat ucode.cpio $INITRD.orig > $INITRD
> 
> rm -rf $TMPDIR
> ---
> 
> You can adjust the regex selecting the Intel files to something more
> restrictive as you don't want to carry everything in your initrd. Not
> that putting every microcode file in the initrd doesn't work - it does
> just fine.
> 
>> Regarding the section *Builtin microcode*, it would be quite cumbersome to
>> list all the microcode files. It looks like wildcards like `*` are not
>> supported. At least the build breaks, if `intel-ucode/*` is used in the
>> prompt.
> 
> Yes, you need to list them one-by-one.
> 
> I wouldn't use that method though as it means you need to rebuild the
> kernel when there's a new microcode. So stick to the initrd instead.

Thank you for the quick and useful response. I got it working now.


Kind regards,

Paul