AMD CPU Microcode Loading On Linux Being Fixed Up To Be Per-Thread

[erniv2]

Sorry for my ignorance, but why is the case that the linux kernel has to (re)load the CPU microcode, after the BIOS has already loaded at boot its own version of cpu microcode?

Is it because BIOSes tend to stay out-of-date either because of user choice/negligence or by the motherboard/laptop manufacturer negligence?

Yes it´s because BIOS/UEFI tends to be older than the OS patches, not every manufacturer provides updated UEFI´s ,it´s too expensive to keep developing them, and for the desktop user at home it´s too much danger to do a bios update on your own, there is a chance to brick your board in case of power fail/bad file download, most home users don´t even know what mainboard they run, where to find the support website to download a new UEFI file or stuff like that not to mention read the mainboard manual or have a UEFI tool like M-flash etc. , do you know why there is a nice colored usb 2.0 slot on the back of your board or if it has one ?

It´s simply easier to update microcode at runtime by the OS but if that work´s you can ask your crystalball for that as seen in this case.

1st the Boot core shit now this we dont patch the SMT threads stuff ~~.

[CommunityMember]

Me neither, but I would like it to have the ability to notify, download, and apply updates.

A few vendors do have email notification lists for various BIOS/firmware updates being available. This is more common for corporate/enterprise targeted IT equipment (workstations, network devices).

[erniv2]

A few vendors do have email notification lists for various BIOS/firmware updates being available. This is more common for corporate/enterprise targeted IT equipment (workstations, network devices).

If you want such a system for the average user you need to plaster ten big red confirmation screens, warning we take no responsibilty for your action once you accept every warrenty will be void, all responsibilty lies with the user.

[jabl]

Sorry for my ignorance, but why is the case that the linux kernel has to (re)load the CPU microcode, after the BIOS has already loaded at boot its own version of cpu microcode?

Both the Linux kernel and (presumably) the BIOS do a version check, and update the microcode only if the version is newer than the one currently running.

Is it because BIOSes tend to stay out-of-date either because of user choice/negligence or by the motherboard/laptop manufacturer negligence?

Yes to both.

So there's like, potentially, three different versions of microcode in play.

1. The microcode version burned into the CPU mask ROM when the CPU is manufactured. This is not changeable, although I think CPU vendors would bundle the latest microcode version whenever they roll out a new stepping.
2. The microcode bundled with the BIOS. When booting, the BIOS checks the microcode version on the CPU, and if it's older than the one bundled with the BIOS, loads the newer version.
3. When the OS boots, it again checks if the currently running microcode version is older than the one supplied with the OS (in the case of Linux, part of the linux-firmware repo which distros typically split out into something like `amd64-microcode` package), and if so loads the newer microcode.

The hope is that at least one of these versions will be new enough to protect the user from the worst bugs. In some cases vendors, for one reason or another, don't keep all these up to date. AMD for example has typically not updated the microcode shipped in the linux-firmware repo, only the AGESA that goes via the BIOS vendors.

[carewolf]

To my understanding, not "just one" but, for example, 6 out of 12 threads on modern Ryzen CPU were patched and 6 out of 12 were running not protected.

And AFAIK it was only one of the fixes that needed to be applied per thread, so most fixes were still in place.

[MorrisS.]

Yes it´s because BIOS/UEFI tends to be older than the OS patches, not every manufacturer provides updated UEFI´s ,it´s too expensive to keep developing them, and for the desktop user at home it´s too much danger to do a bios update on your own, there is a chance to brick your board in case of power fail/bad file download, most home users don´t even know what mainboard they run, where to find the support website to download a new UEFI file or stuff like that not to mention read the mainboard manual or have a UEFI tool like M-flash etc. , do you know why there is a nice colored usb 2.0 slot on the back of your board or if it has one ?

It´s simply easier to update microcode at runtime by the OS but if that work´s you can ask your crystalball for that as seen in this case.

1st the Boot core shit now this we dont patch the SMT threads stuff ~~.

the solutions would be to entrust the updates to the open source via fwupd on linux.

[erniv2]

the solutions would be to entrust the updates to the open source via fwupd on linux.

And now you left out allmost every "home user" that uses some kind of OEM System that does not provide firmware to fwupd, or the fwupd maintainers obtained them trough shady channels.

In the end you have to trust that system, is the UEFI from a trusted source, is it known to work ? And even then to be save from a shitload of lawsuits fwupd has to plaster a dozen warnings over the update process, you sure you want to download this file, you sure want to update your UEFI, be careful things can go south, if things go south we provide no support and have no legal obligation, please note that the process can void warrenty of your hardware, you realy sure you will continue on your own risk?

So much for the open source to the rescue, no coder wants to end up in jail or neck deep in debt because thousends of pepole bricked their systems so nope won´t happen.

[MorrisS.]

And now you left out allmost every "home user" that uses some kind of OEM System that does not provide firmware to fwupd, or the fwupd maintainers obtained them trough shady channels.

In the end you have to trust that system, is the UEFI from a trusted source, is it known to work ? And even then to be save from a shitload of lawsuits fwupd has to plaster a dozen warnings over the update process, you sure you want to download this file, you sure want to update your UEFI, be careful things can go south, if things go south we provide no support and have no legal obligation, please note that the process can void warrenty of your hardware, you realy sure you will continue on your own risk?

So much for the open source to the rescue, no coder wants to end up in jail or neck deep in debt because thousends of pepole bricked their systems so nope won´t happen.

Linux Vendor Firmware Service (LVFS) is not an open source means to update firmwares?

[arQon]

Forcing updated microcode from the OS gets around the user being irresponsible, ignorant, paranoid, or whatever.

While there are certainly a few... let's call them "holdouts" out there, I think they're a *tiny* fraction of the users in this situation. BIOS updates are not only nearly as bad as Android vendors when it comes to support lifetimes, but they can brick a machine. I would *much* rather have patches like this delivered by the OS and installed at runtime when possible, especially when supporting non-technical people.

I had to update the BIOS on an old laptop a few months ago to get it to recognize the RAM upgrade I wanted to give it, and it was an absolute mess (as you can probably guess). The updater *only* worked on 32-bit Windows, so I fully expected to have to backup the whole machine, install 32-bit W10, update the BIOS, reinstall Linux, and then restore everything. It was only by sheer luck that I remembered one of the "repair" options in the Windows installer gives you a Command prompt, which turned out to be enough to run the updater, thus saving me close to an entire day of screwing around.

[skeevy420]

While there are certainly a few... let's call them "holdouts" out there, I think they're a *tiny* fraction of the users in this situation. BIOS updates are not only nearly as bad as Android vendors when it comes to support lifetimes, but they can brick a machine. I would *much* rather have patches like this delivered by the OS and installed at runtime when possible, especially when supporting non-technical people.

I had to update the BIOS on an old laptop a few months ago to get it to recognize the RAM upgrade I wanted to give it, and it was an absolute mess (as you can probably guess). The updater *only* worked on 32-bit Windows, so I fully expected to have to backup the whole machine, install 32-bit W10, update the BIOS, reinstall Linux, and then restore everything. It was only by sheer luck that I remembered one of the "repair" options in the Windows installer gives you a Command prompt, which turned out to be enough to run the updater, thus saving me close to an entire day of screwing around.

That's the problem here -- there's no one size fits all option that'll make everyone happy. Without a dual-slot BIOS setup, forced BIOS updates can go bad. I suppose the best compromise would be a nag screen when running a system updater to constantly nag the user that they have a BIOS update until they either update or disable the nag. Something along that line....For the things that can't be patched at runtime like newer CPU support, newer AGESA, and stuff along those lines.

My last PC was like that. The Windows part....praise Jesus it wasn't the 32-bit one as well. It had of those old DOS BIOS updaters and I did my first Windows install in nearly 10 years to update that PC's BIOS and get my Westmeres to work properly. My current PC is as simple as plug a USB drive into the white BIOS USB slot, copy the BIOS over, reboot, and flash. No dumbass DOS flashers necessary.