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

[phoronix]

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

Up to this point loading updated CPU microcode on AMD processors under Linux has checked just to ensure every physical CPU core was loaded with the new microcode but not sibling threads for SMT processors. While logically that makes sense, it turns out some AMD microcode updates do carry out per-thread modifications that means the microcode updating needs to be carried out on every thread. A Linux fix is on its way to the kernel to adjust that behavior...

https://www.phoronix.com/news/AMD-CPU-Linux-Microcode-Thread

[Svyatko]

ILL this problem exists only with AMD Bulldozer Family 15h microprocessor micro-architecture with "Clustered Multithreading" (CMT), which is distinct from hyperthreading - SMT.

AMD calls this design a "Module"

1 module = 2 integer + 1 FPU cores.

[bezirg]

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?

[Svyatko]

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?

Both cases are observed in the wild.

[skeevy420]

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?

Both. Most BIOS systems don't self-update and a lot of manufacturers suck. It's one of the few situations in modern computing where the end-user is 100% in charge of handling it since most end-user operating systems do a good job of handling hardware and driver updates these days. If the end-user is in charge then the update might never happen. I know people who refuse to update from XP because they don't want to spend $40 on the update to their bookkeeping software to run on 7 and higher. I literally had to deal a crap-ton of issues stemming from Firefox 37 a few months ago. That's Firefox from 2015.

Forcing updated microcode from the OS gets around the user being irresponsible, ignorant, paranoid, or whatever. That's also why people who don't want to be mitigated tend not update linux-firmware or make their own custom one that doesn't contain updates for their CPU. They're at the opposite end of the spectrum -- too smart for their own good.

[schmidtbag]

Wait so if per-thread fixes are possible, then I think it'd be interesting to actually take advantage of that and have certain cores run "insecurely" for the sake of better performance. There are a lot of tasks out there that, even if they were of any security risk, could not be exploited in any meaningful way. For example, rendering or code compiling - they may contain valuable data but tapping into what the CPU is churning isn't the most practical way of stealing it. If the parent process always runs on the secured core(s) but the child processes run on the unmitigated cores, that could be a good middle ground for decent security and good performance for those who don't need everything to be locked down so tight all the time.

[MorrisS.]

So, just one AMD thread get the microcode update before this patch?

[Developer12]

Both. Most BIOS systems don't self-update and a lot of manufacturers suck.

I really don't want my bios self-updating. Far too much code lives in the bios already. With the current quality of bios code adding any kind of networking stack means instant mass rootkit download, if you can even get around the need for network adapter/proxy setting/etc config.

The correct solution is to have the OS/userland apply the updates and to distribute them through something like LVFS. LVFS has considered distributing coreboot images but it would work for any vendor BIOS.

[piorunz]

So, just one AMD thread get the microcode update before this patch?

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.

[skeevy420]

I really don't want my bios self-updating. Far too much code lives in the bios already. With the current quality of bios code adding any kind of networking stack means instant mass rootkit download, if you can even get around the need for network adapter/proxy setting/etc config.

The correct solution is to have the OS/userland apply the updates and to distribute them through something like LVFS. LVFS has considered distributing coreboot images but it would work for any vendor BIOS.

Me neither, but I would like it to have the ability to notify, download, and apply updates. From my perspective, LVFS updating the BIOS isn't any different than a self-updating BIOS since both have the unintended consequence of an update you don't want slipping through.