# Missing "microcode updated early" message, why?

## Vrenn

Some time ago I followed the guide to update intel-microcode by the build-in method.

https://wiki.gentoo.org/wiki/Intel_microcode#New_method_without_initram-fs.2Fdisk

I never used an inidtrd, no need. All I must use for start is buildin (like ahci, ext4, scsi...) and all that needs firmware or is not always needed is configured as a module (sound, network, ntfs...)

Gentoo-wiki told me to build-in the microupdate as I did.

```
[*] Prevent firmware from being built 

-*- Userspace firmware loading support

[*]   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
```

now I have following output

```
user ~ $ grep microcode /proc/cpuinfo

microcode       : 0x24

microcode       : 0x24

microcode       : 0x24

microcode       : 0x24

microcode       : 0x24

microcode       : 0x24

microcode       : 0x24

microcode       : 0x24

user ~ $ su

Passwort: 

root ~ # dmesg | grep microcode

[    1.344909] microcode: sig=0x306c3, pf=0x20, revision=0x24

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

root ~ # 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, 2018-01-21, rev 0x0024, size 23552
```

I am missing the "[    0.000000] microcode: microcode updated early to revision 0xa4, date = 2010-10-02" line from the guide.

I am sure the new revision is loaded, but is it "early" loaded and so the new cpu - instructions used?

The guide has following note: "If you use genkernel and legacy GRUB, you will not have the first line. Just check the microcode revision before and after the changes."

I don't use grub legacy (currently grub 2.02) but a manual grub.cfg and since kernel 4.4 I started with a fresh kernel-config made by genkernel-next, but don't use it anymore. (grub-mkconfig didn't like my dual-boot and other bad problems with my samsung-ssd started with kernel 3.18.22)

So I presume either grup.cfg needs an extra option/insmod anything to make dmesg to print the [    0.000000] messages, or the kernel needs some higher debuglevel that genkernel missed to config?

Has the wiki to be interpreted that build in microcode is always loaded early?

I know that there has been many posts with microcode-handling, I tried to read and understand them as good as I could but anyway: thanks for your explanation.

----------

## krinn

It only gave that message if it do an update "there", your cpu is already at revision 0x24, no need to update to revision 0x24, so no action, no message.

Why is your cpu to 0x24 already?

* cpu is new and have already its microcode to 0x24

* something is updating it even earlier (initrd)

* you have setup your computer hostname to "christine" and you better never try to change it!

----------

## NeddySeagoon

krinn,

The BIOS can do CPU microcode updates too.

 *Quote:*   

> Has the wiki to be interpreted that build in microcode is always loaded early? 

 

Its more the other way around. If its not done early, it won't be done at all.

----------

## Vrenn

To krinn

> so no action, no message. 

Thats the message I miss, because 0x24 is an updated revision.

> Why is your cpu to 0x24 already?

Thats exactly what I don't understand as I do an update there.

 > * cpu is new and have already its microcode to 0x24

Im sure its not. Its an asus-Laptop-Haswell from 2015. Latest UEFI-Bios 211 from 2015 gives me naked (without firmware buildIn) revision 0x1c. With microcode package I have revision 0x24.

 > * something is updating it even earlier (initrd)

no initrd, but buildin. So it is updated during boot. But when? Is it early enough that the kernel uses new instructions like IBC? Why is the message then not there?

 > * you have setup your computer hostname to "christine" and you better never try to change it!

What the...?

To NeddySeagoon

Thanks for your mind. So you believe it is done and functioning.

----------

## NeddySeagoon

Vrenn,

Well, version 0x24 is reported.

----------

## krinn

 *Vrenn wrote:*   

> 
> 
>  > * you have setup your computer hostname to "christine" and you better never try to change it!
> 
> What the...?

 

Well sorry, i was thinking it's a well known, see https://en.wikipedia.org/wiki/Christine_(novel), the reference is that like the car, your computer is alive and self update its microcode ; pointing another 3rd "probable" reason: magic.

[Moderator edit: added explicit [url] tag.  Forum auto-linking does not work when the URL contains parentheses. -Hu]

----------

## Vrenn

I first thought about GlaDOS, but that was Caroline...  :Wink: 

But in the end you are right. I consider magic as technology I don't understand, and thats the case now.

NeddySeagoon is right, microcode is updated when kernel reports me about dmesg, but it doesnt tell me when.

The reason I am hunting this "time of patch" is because my favourite magazine (just german) is telling that's very important.

In short: The microcode can be loaded by early or late microcode load. If it is loaded after the kernel has started off (late load), the kernel doesn't see the new cpu-instructions used by IBC.

But it seems upcomeing kernel 4.16 has a detection-routine for it:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=42ca8082e260dcfd8afa2afa6ec1940b9d41724c

But even with kernel 4.15 it looks good.

```
# grep . /sys/devices/system/cpu/vulnerabilities/* 

/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI

/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization

/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Minimal generic ASM retpoline, IBPB
```

sys tells me IBSB is already used. Reading LWN.net I suggest  IBSB needs microcode, so the new cpu-instructions might be imported early enough. So it still seems to work.

Lets see what 4.16 brings, its very interesting.

----------

## NeddySeagoon

Vrenn,

```
Minimal generic ASM retpoline
```

Tells that you are not building your kernel with gcc-7.3.x

----------

## Vrenn

I know. Actually I'm running a stable tree, (mostly, e.g. gentoo-source 4.14 was stable as I updated) so I await the gcc 7 soon sable. But that should be interdependent from the mircocode-approach.

Then the meltdown/spectre-update might be complete, until the next bug comes...

(to be honest, I don't think it will ever be)

----------

## Vrenn

Now running on 4.16.5 (still stuck to nvidia-drivers, another story  :Sad:  ).

There is NO warning in dmesg like "x86/CPU: CPU features have changed after loading microcode, but might not take effect. x86/CPU: Please consider either early loading through initrd/built-in or a potential BIOS update."

(see this commit on kernel.org)

The kernel has learned new Mitigation-methods. (yes, still waiting for gcc 7.3 become stable)

```
# grep . /sys/devices/system/cpu/vulnerabilities/*

/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI

/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization

/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Minimal generic ASM retpoline, IBPB, IBRS_FW
```

Seems to work.

Just wanted to put that here if someone reads this post for more info.

----------

## Vrenn

Strange: gcc 7.3 is out, I have compiled kernel with 7.3.0 and still no full reptoline. 

```
cat /proc/version 

Linux version 4.16.14-gentoo (root@skl) (gcc version 7.3.0 (Gentoo 7.3.0-r3 p1.4)) #3 SMP Sat Jun 23 11:31:43 CEST 2018

grep . /sys/devices/system/cpu/vulnerabilities/*

/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI

/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable

/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization

/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Minimal generic ASM retpoline, IBPB, IBRS_FW

cat /proc/cpuinfo | grep micro

microcode       : 0x24

microcode       : 0x24

microcode       : 0x24

microcode       : 0x24

microcode       : 0x24

microcode       : 0x24

microcode       : 0x24

microcode       : 0x24
```

what I am missing? an emerge -e world?

----------

## Vrenn

For others that stumble like me:

First, and always fist before you recompile your kernel after a gcc upgrade make a "make clean" in your /usr/src/linux

Then I added new CFLAGS in my make.conf

```
CFLAGS="-march=native -O2 -pipe -fno-plt -mindirect-branch=thunk -mfunction-return=thunk"
```

Now "emerge -e world" two times (system breaks because of dependencies) begin.

```
grep . /sys/devices/system/cpu/vulnerabilities/*

/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI

/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable

/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization

/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB, IBRS_FW
```

----------

