New dracut kernel/modules question. [Solved]

[vespaman]

Hi all,

Warning: This is a "chicken question"

I have a headless server, that I prefer to mess as little as possible with the kernel.
But now I see that there's things happening with micro code management, and I figure I need to make sure this box is up to date while this is still a new change.

My question is regarding the statement in the news file;

Code: Select all

Other users may wish to disable the "initramfs" USE flag on
sys-kernel/linux-firmware and/or sys-firmware/intel-microcode
if they already have other mechanisms in place for updating the CPU
microcode (such as kernel built-in CPU microcode). Users who do not
use sys-kernel/dracut or Distribution Kernels can safely disable
the "initramfs" USE flag globally.

Can I assume that for my box, using gentoo-sources, built manually, without initramfs (AMD cpu), dracut not installed, that I don't need to do anything?

Shall I disable the initramfs use flag globally, perhaps?

[logrusx]

I switched to no-initramfs kernel a few months back, around the changes referenced in this news item and I don't remember details, but I see I have

Code: Select all

sys-kernel/linux-firmware -initramfs

in my package.use. I don't usually put unnecessary stuff in package use, so I believe you need it too.

Your headless server can be hard-rebooted, can't it? If so just keep the old kernel and try the new one.

I also have the following:

Code: Select all

sys-kernel/installkernel -dracut -systemd

because I don't want dracut run automatically. I actually had it before going intramfsless because I used to run dracut manually and I didn't want it run twice for no reason. The -systemd I think is because I didn't want the naming scheme of the files changed.

In summary:
if you don't want dracut being run on make install - disable dracut on installkernel;
if you don't want the naming scheme of the files being installed in boot - disable systemd on installkernel;
if you aren't using initramfs or if you create it manually and you don't want dracut run automatically on firmware/microcode update - disable initramfs on linux-firmware.

Best Regards,
Georgi

[pietinger]

[...] using gentoo-sources, built manually, without initramfs (AMD cpu), dracut not installed, [...]

Shall I disable the initramfs use flag globally, perhaps?

Yes.

I have disabled it globally ... I have the same setting (manually configured monolithic kernel from gentoo-sources; no dracut; intel CPU microcode, microcode for eth, and microcode for intel GPU in kernel via CONFIG_EXTRA_FIRMWARE=)

[vespaman]

OK, great, that gives me comfort to update this box.
The reason for asking was that it is not possible to connect a monitor to it, where it is located, and it is hosting some crucial services, so downtime must be at a minimum.

[Chicken mode off].

Thanks

[Nowa]

Can I assume that for my box, using gentoo-sources, built manually, without initramfs (AMD cpu), dracut not installed, that I don't need to do anything?

How are you updating the CPU microcode? If you don't build the microcode into the kernel, and are also not using dracut, then I recommend against disabling USE=initramfs on sys-kernel/linux-firmware because then your CPU microcode will not be updated at boot.

[vespaman]

How are you updating the CPU microcode?

TBH I have never given this much thought at all. Maybe I don't have the microcode updated at all?
And while I am a long time linux/Gentoo user, I have never used initramfs. Only recently did I learn that there's something called dracut. :--)

Should I take action, since this is a business web/mail/etc etc server? The services of this machine has grown over the years, it started very simple, without much thoughts about security at all.

[Nowa]

Should I take action, since this is a business web/mail/etc etc server?

I think that is a good idea, it's a small and easy change to mitigate whatever vulnerabilities AMD discovered since they launched your CPU.

Either:
- Keep the "initramfs" flag on linux-firmware enabled. If you're using GRUB or rEFInd as the bootloader no further action is required, these bootloaders will find the microcode automatically. Or,
- Since you're manually configuring the kernel anyway, you can build the required microcode into the kernel directly.

See here for the details: https://wiki.gentoo.org/wiki/AMD_microcode

[vespaman]

I think that is a good idea, it's a small and easy change to mitigate whatever vulnerabilities AMD discovered since they launched your CPU.

Either:
- Keep the "initramfs" flag on linux-firmware enabled. If you're using GRUB or rEFInd as the bootloader no further action is required, these bootloaders will find the microcode automatically. Or,
- Since you're manually configuring the kernel anyway, you can build the required microcode into the kernel directly.

See here for the details: https://wiki.gentoo.org/wiki/AMD_microcode

Thanks, i chose the second option, and now the box should be running with new microcode. Should have done this ages ago..

[vespaman]

Thanks, i chose the second option, and now the box should be running with new microcode. Should have done this ages ago..

...or so I thought. It turns out, it does not, afaict;
# dmesg | grep microcode
[ 0.000022] Zenbleed: please update your microcode for the most optimal fix
[ 0.261651] microcode: Current revision: 0x08600103

I have tried numerous solutions now, but there's nothing is happening.

Code: Select all

# grep -F -m 1 "cpu family" /proc/cpuinfo
cpu family      : 23

I have added all three (just to be sure, i started with only the first bin file);

Code: Select all

amd-ucode/microcode_amd_fam17h.bin 	23 	17h 	Zen, Zen+, Zen 2 	2017 	Ryzen 1000-5000 series, Threadripper, EPYC 7xx1/7xx2
  amd/amd_sev_fam17h_model0xh.sbin 	EPYC 7xx1[3] (Zen 1) 	2017 	SEV (Secure Encrypted Virtualization) firmware update for models in the range 00h to 0fh[4]
  amd/amd_sev_fam17h_model3xh.sbin 	EPYC 7xx2[5] (Zen 2) 	2019 	SEV firmware update for models in the range 30h to 3fh[6]

..to my kernel. The files are present in the filesystem.
Path is correct afaict.

Then I gave up the kernel way, and tried to do the initramfs way, by re-enable the use flag, and re-emerge firmware files.
That did not give me any success either, so I guess i need to do the "Manual initramfs creation (AMD)https://wiki.gentoo.org/wiki/Microcode", but that seems not so easy to maintin going forward.
So I will once again try the manual kernel way, giving up the initramfs way, which seems to complicated for me...

Edit: So I disabled initramfs use flag, re-emerged the firmware, removed initramfs from kernel, and rebuilt/installed/rebooted again. Still no change in kernel boot log.
Maybe there's some incompatibilty with 6.9.x kernels. Or I'm missing some kernel setting.

[Nowa]

Does your kernel support loading the microcode early?

See https://wiki.gentoo.org/wiki/Microcode# ... figuration

[vespaman]

Does your kernel support loading the microcode early?

See https://wiki.gentoo.org/wiki/Microcode# ... figuration

According to that article, the kernels above 6.6 should have this always enabled (the config option is no longer available). And I'm on 6.9.2-gentoo now, and I could not find the mentioned option, so I think the answer ought to be yes. (my CONFIG_CPU_SUP_AMD is true).

[Nowa]

Does your kernel support loading the microcode early?

See https://wiki.gentoo.org/wiki/Microcode# ... figuration

According to that article, the kernels above 6.6 should have this always enabled (the config option is no longer available). And I'm on 6.9.2-gentoo now, and I could not find the mentioned option, so I think the answer ought to be yes. (my CONFIG_CPU_SUP_AMD is true).

hmm, what about support for loading an initramfs? is this enabled?

Which bootloader are you using?

[vespaman]

hmm, what about support for loading an initramfs? is this enabled?

No, I think I have disabled it everywhere;

Edit: So I disabled initramfs use flag, re-emerged the firmware, removed initramfs from kernel, and rebuilt/installed/rebooted again. Still no change in kernel boot log.
Maybe there's some incompatibilty with 6.9.x kernels. Or I'm missing some kernel setting.

Which bootloader are you using?

Grub

[logrusx]

Are you sure there's a new microcode for your CPU? Mine for example has never had a microcode update and it either have the latest one in the EFI firmware or it's the latest microcode available in the CPU itself.

What's your CPU?

Best Regards,
Georgi

[vespaman]

Are you sure there's a new microcode for your CPU? Mine for example has never had a microcode update and it either have the latest one in the EFI firmware or it's the latest microcode available in the CPU itself.

What's your CPU?

Best Regards,
Georgi

Lol, no I am not sure at all! But it is a couple of years old by now, I think I installed it in autumn 2020, and as far as i can remember, I have not updted the firmware/bios since then.

Code: Select all

# cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 23
model           : 96
model name      : AMD Ryzen 5 4500U with Radeon Graphics
stepping        : 1
microcode       : 0x8600103
cpu MHz         : 1397.227
cache size      : 512 KB
physical id     : 0
siblings        : 6
core id         : 0
cpu cores       : 6
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 16
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip rdpid overflow_recov succor smca
bugs            : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass retbleed smt_rsb srso
bogomips        : 4741.14
TLB size        : 3072 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]

[Nowa]

Lol, no I am not sure at all! But it is a couple of years old by now, I think I installed it in autumn 2020, and as far as i can remember, I have not updted the firmware/bios since then.

Well dmesg asks you to update it, I doubt it would do that if there was no update available.

No, I think I have disabled it everywhere;

That explains why the early microcode initramfs is not loaded. Though I don't understand why it doesn't work if the microcode is built-in.

[vespaman]

That explains why the early microcode initramfs is not loaded.

Sure, but I did test to also do it the initramfs way, by enabling the initramfs use flag, re-emerge the firmware, enabled the kernel initramfs. But that did not work either, so after that I tried to remove all initramfs, to be sure that initramfs way would not hinder the in-kernel microcode to load. (Just a long shot)
I did not, however, generate the initramfs files manually, because I thought that was "too far" a job to maintain. The examples doing that also had a very old 4.x kernel so I'm not even sure this is still a valid thing to do.

Maybe there's some incompatibility between the kernel and the firmware/microcode. It says to use (decimal) 23 (17 hex), which is what I am doing, the other two files did not make any difference either, when I added also them. Actually, "model" says 96 in /proc/cpuinfo. The microcode readme does say:

Code: Select all

Microcode patches in microcode_amd_fam17h.bin:
  Family=0x17 Model=0x08 Stepping=0x02: Patch=0x0800820d Length=3200 bytes
  Family=0x17 Model=0x31 Stepping=0x00: Patch=0x0830107b Length=3200 bytes
  Family=0x17 Model=0xa0 Stepping=0x00: Patch=0x08a00008 Length=3200 bytes
  Family=0x17 Model=0x01 Stepping=0x02: Patch=0x0800126e Length=3200 bytes

- so model 96 (60 hex) is not actually available in this blob. That is the only reasonable thing I can think of. It is a bit unfortunate, if this is the case, that the kernel does not spit out that it does not make use of the suplied microcode b/c mismatch.


Oh well..

[Nowa]

Sure, but I did test to also do it the initramfs way, by enabling the initramfs use flag, re-emerge the firmware, enabled the kernel initramfs

Sorry, I am a bit confused now. Is CONFIG_BLK_DEV_INITRD enabled or disabled?
Just enabling the "initramfs" flags is not enough, the kernel must support loading an initramfs, and the grub configuration should be updated so grub will actually load this at boot (if it's correct grub will show you "loading amd_uc.img" or similar at boot).

I think the initramfs way is less error prone since you get all of the microcode in that initramfs, thus the correct ones should always be available.

[vespaman]

Sure, but I did test to also do it the initramfs way, by enabling the initramfs use flag, re-emerge the firmware, enabled the kernel initramfs

Sorry, I am a bit confused now. Is CONFIG_BLK_DEV_INITRD enabled or disabled?
Just enabling the "initramfs" flags is not enough, the kernel must support loading an initramfs, and the grub configuration should be updated so grub will actually load this at boot (if it's correct grub will show you "loading amd_uc.img" or similar at boot).

I think the initramfs way is less error prone since you get all of the microcode in that initramfs, thus the correct ones should always be available.

Well that is what I meant with "enabled the kernel initramfs", so yes, it was enabled when I tried the initramfs way. I install the kernel with make install, which triggers grub update.