Johannes Schauer Marin Rodrigues <jo...@debian.org> writes: > Hi, > > Quoting Simon Josefsson (2025-03-08 13:43:26) >> My point was that there is no reasonable way to gain confidence about >> security properties of any piece of non-free microcode. Everyone can now >> produce AMD microcode that corrupts your machine in advanced ways that evade >> detection, but we don't know if such malicious corruption is included in the >> official microcode. Having source code for the microcode would help gain >> confidence in it, and is the reasonable request. If the request is denied, I >> would consider the vendor not trustworthy and look into options. > > I do not understand something about this argument. > > If you don't trust the vendor, then it makes no difference whether or not new > official firmware/microcode can be uploaded/flashed or not. If you don't trust > the vendor, then the initial microcode that came with your device might > already > be doing things that go against your interests. > > Of course we cannot have much confidence in a piece of microcode of which we > do > not have the source code. But we also cannot have much confidence in a piece > of > hardware with non-flashable firmware of which we don't have the vhdl/verilog > sources. So what is the difference?
These are good questions and I believe that if you can see that there is a difference between the two positions, it is easier to appreciate the need for fully free operating systems, and that not offering fully free Debian installer images (even as an option) is problematic. Many years ago I also reacted the same way you and many others do -- "there is no difference between the act of loading non-free firmware into my hardware and then using it compared to the act of using my hardware that contains non-free software in it". However I have come to realize that, yes, there is a significant and fundamental difference between these two cases. I'm not good at explaining this difference, and I believe the reason so many still believe there is no differeence between these positions suggests that we need better ways to articulate the difference. I'm sure most people here are familiar with RMS' argument on this: https://www.gnu.org/distros/free-system-distribution-guidelines.html The way that I came to understand and appreciate the difference between the act of loading non-free firmware into hardware, and the act of using non-free firmware in hardware, is to first acknowledge that hardware is different from software. Software people often think that their ideals on how to design things should apply equally to hardware. Hardware people often think the reverse. I've seen these patterns collide many times, notably when I was involved with Yubico. The escape mechanism is to acknowledge that there has to be different ideals. You don't have to design hardware the way you design software, and vice versa. If you are stuck applying the same ideals for both concepts, it is harder to work out what is right for software and what is right for hardware separately. And harder for experts to work efficiently within their own area. So what are good ideals for software? There are many patterns to subscribe to, but I believe https://www.gnu.org/philosophy/free-sw.html and https://www.gnu.org/distros/free-system-distribution-guidelines.html are worthy to aspire to. Non-free firmware doesn't belong here. I'm not a hardware person, so I'm less confident what good designs for hardware should be, and it seems there is less consensus what the desirable properties really are. One fundamental property that I would like is that I want to be able to examine and modify all steps that ultimately lead to production of the hardware. I'm sure there are more properties that are desirable. It is easy to see that this is a required but not sufficient condition: otherwise you can end up producing a closed device ecosystem like an iPhone. > If I don't trust vendor X, then I cannot buy hardware from them independent of > whether or not the vendor allows me to flash proprietary binary blobs from > them. If I do trust vendor X, then why would I not trust their proprietary > binary blobs? One difference is that you could chose to trust their hardware (CPUs) but don't trust their software (non-free firmware). Consumer level protection in society is generally different when I buy a hardware product compared to if I'm granted a license to use some software. If I buy a bike or helmet it has to meet certain criteria for it to be allowed to be sold (at least where I live) but different laws apply if I use a piece of software under some legal terms of services. Just because I place trust in entity X for the purpose of A doesn't mean that I necessarily must trust entity X for the purpose of B. That is the slippery slope that vendors want you to walk into so they can excercise more control. > I do not think you will find many on this list who will disagree with the > sentiment that it would be great if we had sources, schematics etc for many > more things. On the other hand, I don't think you can currently buy a device > that is capable to run, for example, a modern web browser and is fully open. > This is why I voted in the last GR as I did. I'm typing this on an MNT Reform > which is probably among the most open computers you can buy today but the > chips > in it are *not* open silicon. Yes, it would be great if they were and it would > be great if the firmware blobs I need would not be proprietary. But I already > chose to trust the manufacturers of the chips in my laptop or otherwise I > would > not be typing these lines. Why would I trust the silicone from vendor X and > distrust the firmware/microcode from vendor X? Having non-free-firmware > enabled > by default in the Debian installer just continues pursuing a trust > relationship > you already decided on entering when you bought the hardware, no? Right, I see that if you don't appreciate the difference between these two cases, it is reasonable and logical to regard non-free firmware as unproblematic. /Simon
signature.asc
Description: PGP signature
