nixos-generate-config: generate updateMicrocode

[lukateras]

It would be nice if nixos-generate-config generated hardware.cpu.intel.updateMicrocode and hardware.cpu.amd.updateMicrocode options (only lib.mkDefault).

Processors without microcode update might run with misbehaving flashed microcode: https://lists.debian.org/debian-devel/2017/06/msg00308.html

/cc @copumpkin

[zarelit]

Do you mean like setting it to true or just mentioning it? It's a good thing for sure to have working hardware as opposed to not working, but OTOH it pulls non free code...

[lukateras]

Of course setting it to true (actually to lib.mkDefault true), mentioning it would have no effect.

First, nixos-generate-config already pulls in literal unfree code, e.g. Wi-Fi drivers on MacBook Air 6,x, not even redistributable.

Second, non-free code is already running on Intel processors, I don't see any difference whether it's flashed or not (I know this is controversial).

Third, for purposes of Nixpkgs, licenses.unfreeRedistributableFirmware is free.

And of course the kernel contains a whole lot of firmware blobs.

[cx405]

@yegortimoshenko Strongly disagree here as its an equivalent of setting nixpkgs.config.allowUnfree = true; thus will taint every installation by default, which is a reverse policy of the current nixos from optin to optout.

That said, being complete new user, I have myself figured and found these options myself. My system booted without them likewise fine. In general, AMD patches CPUs with AGEISA BIOS updates, so does Intel - however these updates are optional and up to the user.

This is should be mentioned on a) Installation page b) NIxos wiki - not be made default option, because this action is in conflict with policy.

[lukateras]

I disagree that this is equivalent. CPU comes preflashed with microcode, BIOS comes with updated microcode for the processor to boot correctly (microcode that comes with CPU is very buggy and usually can't go through boot sequence correctly). It's not clear how it would add to the problem if we were to load an up-to-date microcode image.

This is equivalent to shipping firmware to users that haven't set allowUnfree flag, which is current NixOS policy. Intel microcode is freely redistributable AFAIK.

[cx405]

@yegortimoshenko The default state for these two switches is very clearly "disabled", plus they have no affect on non-AMD/intel CPUs. Flipping the switch in hardware-configuration.nix, is basically flipping the default state in the backstage, which is much worse than setting the defaults to "enabled", as it creates distrust and inconsistency cases.

Further, firmware updates can cause real issues, not only solve them. It is irresponsible to think that they only solve issues. AMD AGEISA updates on 785G on has actually been broken for over a year for me, refusing to react to USB events on boot until I manually bypassed the tier 1&2 support (which is hell of a job for Linux user) to get to actual support for testing.
About Intel, I have only encountered issues with gen3 PCIe cards in Intel motherboard for 2nd gen Core CPUs, but fixing this also required a year of waiting and UEFI reflash.
Also speaking as an owner of HP(b209a) and Epson(sx525wd) printers - updating ucode actually caused hardware reflash and made legally purchased cartridges worthless.

I am yet to encounter a CPU that can't pass boot sequence due to buggy ucode, but I doubt hot-loading it on OS stage would fix it, because it needs first to get to this stage. However I can clearly imagine the added unpredictability if these switches are properly enabled.

[lukateras]

Flipping the switch in hardware-configuration.nix, is basically flipping the default state in the backstage, which is much worse than setting the defaults to "enabled", as it creates distrust and inconsistency cases.

Microcode is essentially a firmware for the CPU. NixOS, more specifically, the Linux kernel, will load firmwares for any device with support for that without asking the user. Loading microcode updates does not require a policy change, if anything, this would make the policy more consistent across the board.

On a tangent, I don't understand why anyone would tolerate a blob flashed on CPU, and in BIOS, but would not tolerate the same blob being loaded by the kernel.

Further, firmware updates can cause real issues, not only solve them

That can be said about any software. Usually, the opposite is true.

I am yet to encounter a CPU that can't pass boot sequence due to buggy ucode [...]

What I mean is that every BIOS except Libreboot contains microcode blobs that it loads onto the processor early in the boot sequence. Without that blob, boot sequence will most likely fail somewhere along the way. That's the reason why Libreboot doesn't support modern Intel/AMD CPUs, and why there is Coreboot/Libreboot split in the first place.

[cx405]

@yegortimoshenko You are mixing very different cases into one bottle. Some hardware requires ucode to be loaded to function and won't function without. Some hardware has optional ucode updates. For this hardware, some classes load firmware update and then flash themselves - some lock the possibility to install previous revision, and some classes load the ucode as temporary override (which is case with AMD/Intel). Some hardware has open firmware (sources), but majority does not offer source. In essence, ucode is a blackbox and live-updating ucode is unpredictable black box. For some devices, ucode loading is a must, for others its optional.

I suggest that we limit ourselves to specific case of Intel/AMD ucode, for which ucode updates are optional and crucial updates are applied only via hardware flashing.

That's the reason why Libreboot doesn't support modern Intel/AMD CPUs, and why there is Coreboot/Libreboot split in the first place.

I am pretty sure that the reason why Libreboot supports less hardware has to do purely with acceptance criteria for how tainted ("blackboxed") the firmware is, and that both support little of x86, because Intel refused to provide specifications and AMD was open to some extent, but then closed up the AGESA after Phenom II because they most possibly implemented TPM in firmware(fTPM).

That can be said about any software. Usually, the opposite is true.

About EULA-d + encrypted software, we are talking about closed-source hardware. For manufacturers of such software, surely opposite is true and the updates are usually used to keep their policy consistent and enforced, for users it means giving up and restricting all rights.

That said, I found those options myself easily as a new user (yet my hardware functioned without issues without them) and I see a problem if they default to one value, but change "automatically" and unnoticed at run-time. Either way, this option should be documented better - and this includes places where its flipped.

[lukateras]

You are mixing very different cases into one bottle. [...] For some devices, ucode loading is a must, for others its optional.

It's not clear what difference does it make. Say, from freedom perspective, it would not be OK to use Windows even if I were to ignore any updates for it. If we ship updated microcode, which includes security fixes foremost, how would that taint installs any more than they currently are, with in-kernel blobs and such?

[lukateras]

I am pretty sure that the reason why Libreboot supports less hardware has to do purely with acceptance criteria for how tainted ("blackboxed") the firmware is [...]

It has to do with blobs for the most part. See:

• https://www.coreboot.org/Binary_situation
• https://libreboot.org/faq.html#microcode

[zimbatm]

It replaces non-free code with a more up2date non-free code. Given Meltdown and Spectre this should be the default.

Especially since it would be generated at installation time. Accompanied with the right comment, users who really want to have outdated CPUs will be notified and can delete one line. (well two with the comment).

[lukateras]

I would like this to default to config.hardware.enableRedistributableFirmware (microcode essentially is firmware).

Especially since it would be generated at installation time. Accompanied with the right comment, users who really want to have outdated CPUs will be notified and can delete one line. (well two with the comment).

hardware-configuration.nix isn't supposed to be edited, it should just use lib.mkDefault so that user can override it in their config.

[stale]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[florianjacob]

still think this should be done, as new users probably don't know this option exists at all and that you have to enable it by yourself in NixOS. With concerns on, this should at least be generated as commented out, with a hint "while you will probably want this, note that it is unfree software".

[stale]

I marked this as stale due to inactivity. → More info

[totoroot]

Why is this no longer in discussion? As someone new to the NixOS universe and coming from Ubuntu I wasn't aware that I had to explicitely include this in my hardware configuration on NixOS until I stumbled across other people's configuration files. I definitely think it should at least be prominently featured in the installation manual or even better be enabled by default, as @yegortimoshenko mentioned.

[gebner]

One way or another, updateMicrocode needs to be enabled by default. These updates fix security issues, there are probably a lot of NixOS users now that don't even know that they're running insecure microcode.

See also the discussion in NixOS/rfcs#70

[Artturin]

#146179

[zarelit]

@alpakido I've never replied to the first comment!
While I still support the open hardware movement (and thus free software firmware) I also believe that having QEMU misbehave because of a missing update is not really a good default option. If the user is concerned about the microcode updates or about managing security at this level then they will probably read the auto-generated configuration and immediately spot an updateMicrocode and will comment it out :-)
So thanks @Artturin for the PR, I can't review because I don't know perl :-p