linux-kernel - Running new kernel on old (non-supported) CPU: Should it boot?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <f91888aed1914a6ca316369c5068aa94@ukr.de>
Date: Fri, 14 Nov 2025 11:50:53 +0000
From: "Windl, Ulrich" <u.windl@....de>
To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Running new kernel on old (non-supported) CPU: Should it boot?

Hi!

I was confused by dmesg staring with the message

[    0.000000] unchecked MSR access error: RDMSR from 0x8b at rIP: 0xc156f2b0 (microcode_loader_disabled+0x3b/0x5a)
[    0.000000] Call Trace:
[    0.000000]  <IRQ>
[    0.000000]  </IRQ>
[    0.000000] Linux version 6.6.113 (oe-user@...host) (i586-poky-linux-gcc (GCC) 14.3.0, GNU ld (GNU Binutils) 2.44.0.20250715) #1 Sun Oct 19 14:31:02 UTC 2025

(issue can be found at https://unix.stackexchange.com/q/801323/320598, too)

So (as I read it) the kernel failed to update the CPU microcode due to RDMSR failing.
I'm unsure why it failed, but possibly because the old32-bit AMD Geode CPU does not support it.

The question remaining is:
Can the ability to update the microcode be tested with less noise (and then reported in plain words like "This CPU does not support microcode updates"),
Or is the kernel expected to run on such CPU at all? If not, should it panic with a corresponding message?

Sorry for the noise, but I have an embedded system that behaves odd since updating the firmware (and the Linux kernel). I'm just wondering whether it's a software issue, or a hardware issue (not incompatibility, but a defect).

Keep me in CC: when answering, or comment at stackexchange, as you prefer.

Kind regards,
Ulrich Windl