Trisquel 9.0 Released - Powered By The Linux 4.15 Kernel

[bridgman]

Maybe i'm misunderstanding the issue but wouldn't it be possible for them to release updated firmware for a device that is also open source ?

Yes and no. Vendors become able to provide open source drivers by moving sensitive things like content protection into firmware. If they then open up the firmware they lose the ability to sell hardware into the largest part of the market, which is OEM systems where the system vendor or OS vendor requires robust DRM as a pre-requisite for using the parts.

We could design a new and different chip that could accept open source microcode but we could only sell it into a tiny segment of the market, nowhere near enough to cover the R&D costs. There has been some investigative work into fully open DRM solutions but I don't believe anything has come out yet that the movie industry would consider sufficiently secure.

I'm going to switch terminology here from "firmware" to "microcode" in order to make a clear distinction between things like SBIOS/UEFI/VBIOS (which execute on the CPU and are legitimately called firmware) and things like hardware microcode which execute on the GPU's state machines and which are required to make the hardware functional.

If FSF and the libre distros actually enforced the "no closed source microcode rule" then that would exclude pretty much every CPU and GPU on the market. In order to avoid this they made an arbitrary decision to support devices which kept their closed source microcode in ROM on the chip and to exclude devices which executed microcode from RAM on the chip and hence required microcode loading at startup. That in turn led to the statement that "microcode you can change is software, microcode you can't change is not" in order to support the decision.

The only thing I see the FSF policy accomplishing is moving more closed source microcode into on-chip ROM and closing the door on ever replacing it with open source code in the future.

[chocolate]

My only thing to criticize is the stance on firmware so hardware works. I think the best compromise would be to use the external firmware that was available at the time of release and to treat that as fixed, in-place like they do with ROMs. IMHO, it simply isn't reasonable to expect any hardware manufacturer these days to be able to produce a 100% bug-free firmware on the release day...too many scenarios and setups and software combinations for them to test everything. CPUs and GPUs do too much for that to be a reasonable expectation; not to mention when vulnerabilities are found and patched.

How do Libre Distributions deal with mitigations at the hardware level if they don't allow (updated) microcodes or firmware? Are compiler level mitigations the best they offer? Maybe SELinux? Does that make them insecure by default? I'm genuinely curious.

This is a legitimate concern. I'm afraid I don't have all the answers... yet, therefore I'm not going to judge the stance of the FSF regarding libre distros. I'll just say I'm glad libre distros exist: if anything, they provide infrastructure for those that want to avoid the risk of running non-libre software, as I said in my previous comment. This is very valuable, despite Linux-libre raising the issue of "libre-friendly hardware", as arbitrary as that definition may be -- for now. Of course it's fundamental, but I don't see it as the most important part of what constitutes a libre distro, or the only one worth discussing. Then again, the "ah, so it doesn't run on anything" pseudo-joke feels as old as the world now, and always skews the discussion towards Linux-libre.

Personally, I recently bought an RDNA GPU knowing perfectly well what I was getting into. I typically run Fedora for work (no issues there, with an updated system) and Pop!_OS plus XanMod and kisak-mesa for videogames. Works like a charm (thanks AMD and early adopters who reported any bugs!).
This is to say, I'm sceptical about microcode running on peripherals as well, but I'm not having issues with it at the moment. I believe motherboard firmware/CPU microcode that could potentially interfere with the whole system are of greater concern. That's where stuff like Raptor Engineering's Talos workstation comes into play. As things are right now, I would retain a current-gen AMD GPU in a Talos workstation, instead of choosing an older GPU with burned microcode just to make the machine FSF-approved.

If FSF and the libre distros actually enforced the "no closed source microcode rule" then that would exclude pretty much every CPU and GPU on the market. In order to avoid this they made an arbitrary decision to support devices which kept their closed source microcode in ROM on the chip and to exclude devices which executed microcode from RAM on the chip and hence required microcode loading at startup. That in turn led to the statement that "microcode you can change is software, microcode you can't change is not" in order to support the decision.

The only thing I see the FSF policy accomplishing is moving more closed source microcode into on-chip ROM and closing the door on ever replacing it with open source code in the future.

Indeed that seems to be the case. Thanks for the satisfactory answer.
One last thing is not clear to me: could GPU microcode be "modular" in the sense that DRM mechanisms and other sensitive bits could be excluded from a "minimal" open source release, still capable of e.g. running videogames?

[bridgman]

One last thing is not clear to me: could GPU microcode be "modular" in the sense that DRM mechanisms and other sensitive bits could be excluded from a "minimal" open source release, still capable of e.g. running videogames?

I guess it depends on what you mean by "open source" - it might be possible to do a technically open source release like that - source code and signed binary but without a toolchain and without the signing tools required to allow user-built versions to install. Even that would have fairly high risk, and would be unlikely to satisfy FSF, ie no benefit just high risk.

The problem with doing anything more is that we would effectively be saying "here is everything you need in order to defeat DRM on our products", which is equivalent to saying "please drive us out of business" since perhaps 90% of the consumer GPU market requires robust DRM.