Notices by Matthew Garrett (mjg59@nondeterministic.computer)

Every single ACPI vs Device Tree argument needs to start with the observation that I can boot a modern Linux kernel on an arbitrary x86 board from 1998 and it will probably suspend and resume correctly, and I can't do that with an arbitrary Arm board from 2026

@lxo what? The device provides an interface to update the software included in it, and it is intended that this occur after the user purchases the device. It's the extremely clear and plain reading of the language. The guideline doesn't say "It's fine if the user chooses not to do this".

@lxo That's not what RYF says:

"The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product"

Hard drive firmware is intended to be installed after the user obtains the product. Vendors routinely ship bug fix and reliability updates and won't provide support unless you install it. Hard drives don't meet the RYF guidelines.

@lxo It's intended that the software be updated and so the exception doesn't apply, and so it needs to be free software to meet RYF. It's not, so doesn't. Sorry, I didn't write the rules.

@lxo the firmware in your WiFi card isn't doing your computing, but RYF insists that the program running there must either be in ROM or free. Why is it different to your hard drive?

@lxo if you're willing to call them programs, why do the four freedoms not apply? At minimum, why do you not deserve the right to know what these programs are actually doing?

@lxo (the program in your hard drive can, by the way, be updated by the vendor - but it's different to the microcode case because it's in mutable storage and never in ROM and so the update is permanent)

@lxo yes, you have come up with an incorrect model in order to avoid admitting you're running non-free code.

@lxo it makes no retroactive difference - it is software, it always was software, all the normal ethical considerations should apply. Now, in the same way that free software published in a book can't be modified in place, there may be practical considerations that would limit exercise if those freedoms - in which case we should argue that implementations that make their exercise easier are preferable to ones that don't

@lxo yes, it's a fantastical example that's intended to demonstrate that your argument is non-sensical. Your position seems to be that if the box is closed then it's not software, but if someone were to figure out how to open it it would become software. That's clearly not how any of this works.

@lxo except it's clearly *not* equivalent to a hardware circuit, that's just an assertion you've made. And in your repeated mentioning of replacing ROMs I'm becoming concerned that you don't actually know much about hardware.

@lxo I'm somewhat bewildered to have an FSF board member say that I should have no ethical expectation to be able to modify GPLed software running on something I own as long as the vendor does a good enough job of nailing the box shut.

@lxo @wouter you encourage users to buy hardware containing software they will never be able to free instead of buying hardware that a sufficiently driven user may be able to free. But even if it's never freed, it is easier in many cases to examine and audit that non-free software if it's loadable and very hard if not impossible if it's embedded in ROM in the device. I have personally done so for various devices I own, and have identified security issues that were rectified by the manufacturer.

@lxo does sticking a copy of Linux on a CD and locking the player and attached computer in a black box mean that the owner of that box should have no expectations of being able to modify what is very clearly code? From an external perspective the operation of the box may be indistinguishable from a hardcoded CPU, but if we *know* that it contains free software, why is it ethical to prevent the owner from performing any modifications they desire?

@lxo @wouter but you're happy to endorse hardware that contains code that can never be modified, even to the extent of promoting it over hardware that runs non-free code that *could* be freed. I accept this isn't the case for Intel microcode, but it's still an incoherent position.

@lxo putting non-free code on a read-only optical disk doesn't stop it being non-free code. Putting it in read-only memory doesn't stop it being non-free code. It's code. You've come up with an entirely arbitrary definition to stop having to care about it.

@lxo If I don't trust Intel to avoid introducing deliberate security backdoors via microcode updates, I should also not buy any new Intel CPUs - they might have introduced a backdoor. I shouldn't buy an old one either - the old one might have a backdoor that my current one doesn't. Either Intel is trustworthy, in which case the microcode updates are as safe as the microcode the CPU ships with, or they're not, in which case I should never trust any Intel CPUs at all.

@lxo Brings no benefit for you, brings significant benefit for others. And, clearly, the CPU is running non-free microcode whether an update is loaded or not - replacing one blob with another doesn't increase the number of blobs the running system depends on.

But "fallacy"? Obviously it's removed. https://www.fsfla.org/ikiwiki/selibre/linux-libre/ uses the word "removed" several times. You removed the code that allowed someone to update the microcode. The fact that it can be added back doesn't mean it wasn't removed.

@lxo and I completely understand you making the choice not to trust an opaque update! For a bunch of threat models it's probably the right choice. What I object to is you making that choice on behalf of all of your users, and not making it clear to them what the impact may be.

@lxo the majority of the performance loss isn't in the microcode updates, it's in the OS making use of new functionality in those updates - if you pass mitigations=off you regain the performance even with the new microcode, and you can choose the set of mitigations applied to fit the particular threat model you have. By removing the ability to update it you remove the ability for users to make that choice, without reducing the quantity of non-free blobs the system depends on.