Duplicate of #336331

How can we trust this repo? How can we guarantee the files are from where they claim to be and their integrity?

Because there's a hash check every single time Nix build a derivation.

Why did you 👎 the PR ?

At some point I would like to implement ucodenixin house, as well. But that's for another day.

Wouldn't it be worth to try fixing hardware.cpu.amd.updateMicrocode instead?

My take here for this derivation is: find out the procedure @platomav uses to extract these files, and reproduce it here with Nix instead, fetching the files directly from Microsoft/AMD/BIOS manufacturers. Make it safe!

Why did you 👎 the PR ?

I clearly disagree with running code from a random repo in a security ring deeper than the kernel itself. Microcode was used as a backdoor by researchers before.

This was brought up before and rejected by others as well: https://discourse.nixos.org/t/amd-microcode-updates-not-applying/31923/20

Anyway, I don't have the authority to reject this, but should be something for @NixOS/security (skipped tagging deliberately) to maybe have a look.

Admittedly I had considered the security implications of this, ie, trusting microcode updates from a GitHub repo. I was unsure so I thought it would be better to have a PR up for discussion as a starting point.

Duplicate of #336331

Wish I had seen it before :)

From @ElvishJerricco's reply on Discourse
It’s based on this repo, which appears to be a crowdsourced collection of microcodes. This isn’t exactly something I would be encouraging typical users to use

I agree.

However I would argue that just having this package merged doesn't let any one deliberately use it. Unlike #336331, which packs it properly into a microcode/AuthenticAMD.bin.

We have official microcode releases from both Intel and AMD. Why this?

The main reason for the existence of solutions like ucodenix is that AMD allegedly doesn't update microcode for their consumer level CPUs (only for server grade CPUs) through linux-firmware. They are only distributed through BIOS updates.¹²

This has been observed by other users as well.³ Not using the latest BIOS means that you'll be left out. That itself is a security issue that AMD themselves raise.

Admittedly I can not verify the authenticity of microcodes in platomav's repo, but it is claimed that they are signed by their vendors as they come from official sources.

AMD allegedly doesn't update microcode for their consumer level CPUs

Counterpoint. On a Ryzen 5600X:

[    0.885532] microcode: Current revision: 0x0a20102d
[    0.885534] microcode: Updated early from: 0x0a201016

Looking at https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amd-ucode/README I learn that this processor gets microcode from microcode_amd_fam19h.bin.

That file was updated quite a bit over the last few years, but indeed mostly only for a very select list of CPUs.

The latest ucode bump (2024-11-21) however added quite a few models, including the Ryzen 5600X as seen above.

So it is possible they've neglected shipping microcode updates for consumer CPUs in the past. But is that still true?

I find it difficult to retrieve microcode updates from arbitrary sources, because even though they might be signed we don't have any changelog or knowledge whether these updates are specific to an OEM platform.

Also does it work with a kernel > 6.13.6?

I was under the impression that since https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking (which is pretty bad if the origin of the microcode cannot be proven), older microcode would not be loaded due to gregkh/linux@c162ba4
Looking at the dates in the file name it looks like a bunch of them will be rejected (at least for AMD CPUs).

Also does it work with a kernel > 6.13.6?

Yes, if as far as I can tell, at least for my CPU Ryzen 5 7600, microcode for it from platomov's repo is signed by AMD, and it loads perfectly.

Which wouldn't otherwise be possible, without turning the verification explicitly off using something like this (NOT RECOMMENDED):

boot.kernelParams = [ "microcode.amd_sha_check=off" ];

Hello! I am the author of #336331.

Regarding the possible security issues, as far as I understand, on a Kernel > 6.13.6:

• If the microcode provided by the BIOS is more recent than the ones hardcoded in gregkh/linux@c162ba4, the signature of the firmware loaded by the Kernel will be securely verified. In this case there is no reason to worry about the crowdsourced images provided by this repo.
• Otherwise, the SHA of the loaded firmware must match one of the ones hardcoded in gregkh/linux@c162ba4, which are probably just the ones officially released by AMD itself. In this case, applying any of the images provided by this repo will fail.
• If the manufacturer is not providing a BIOS image with a more recent microcode, the (only?) option to update the microcode (mostly to patch vulnerabilities) is to blindly use the ones provided in this repo by setting microcode.amd_sha_check=off and hoping that somebody else has verified them with a more recent BIOS. Forging microcode images is possible, as already mentioned.

In my opinion, I would leave the choice to the user (and I don't think that packing the images into microcode/AuthenticAMD.bin is a problem), as (if the user is running a kernel > 6.13.6) the user has to willingly disable a (poorly documented) security check in order to actually be at risk.
If the user is running a kernel < 6.13.6, then the risk is much higher.
I stopped updating #336331 just because my BIOS is too old and I couldn't test newer images properly.

Yeah, given that all microcode is signed we could make this a user decision.

I agree, however the current microcode option interface doesn't allow it, I have made a PR. #434472