Comment by einpoklum | Hacker News Reader

Comment by einpoklum | Hacker News Reader

"Free Software Foundation position on firmware ... is that if a device has ... firmware ... in a form that users can’t modify, then the system as a whole is not free software. This is technically correct but doesn’t logically imply that the right strategy for advancing free software is to forbid firmware blobs"

It may not be the convenient thing for novice users, but it is an important strategy to "dogfood" fully-free systems, i.e. obtain them, run them, and make efforts to get them to work as seamlessly as possible. This was done with OS-level-and-up software - for the most part - and we have been reaping great rewards all around from those efforts. If it can be done for the full stack of hardware and software, this will be very beneficial and in some aspects even liberating.

Again, joe user is probably better off with a more pragmatic approach at the moment. But joe user can still choose a FOSS operating system, which a few decades ago was not realistic.

The thing is that the FSF's stance is already a pragmatic approach of sorts but the line is drawn in a strange place that doesn't really help advance the cause. The hard line approach of "all firmware must be free, too" would render basically every computer unusable, even RMS can see that's going too far to be practical. So, they make an abstraction boundary where "free" stops: If the kernel doesn't load the firmware then it's as if the chip is implemented completely in hardware. It's a practical decision because you have to stop somewhere otherwise you can't get anything done. I wish the FSF/GNU-aligned folks would just make a slightly different compromise that makes it a lot easier for people to start using free software distros. Not shipping CPU microcode updates is particularly harmful to users. 10 years ago it was not too hard to run a distro without firmware blobs on a laptop if you were cool with just getting a thinkpad, but modern intel hardware requires a blob for graphics so even that path is closed now. My 2022 thinkpad x1 needs blobs for graphics, wifi, bluetooth, and sound and I tried to find something modern that didn't need them and gave up eventually.

Well, it's not like the "line is drawn" in the sense of GNU software not working on such systems. They draw it in what's included in the default repository for guix... so that line does not actually impact many people, and those who are impacted by it can still cross the line pretty easily.

About the CPU microcode updates... why do you believe they are important? I mean, if your system runs arbitrary code off the Internet, or has thousands of people log in and work on it, then sure, but otherwise, I don't know.

This story happens all the time: Someone learns about free software, gets excited, downloads an ISO for a free distro and is then disappointed to find that their wifi doesn't work. They get told to buy a USB dongle or something so instead they just use something else that works. It's the most common onboarding problem I'm aware of.

Are you saying that the security updates in CPU microcode aren't important because you can't think of an attack vector? Feels like a weak reason to justify not shipping updates.

> Well, it's not like the "line is drawn" in the sense of GNU software not working on such systems. They draw it in what's included in the default repository for guix... so that line does not actually impact many people, and those who are impacted by it can still cross the line pretty easily.

And if what's in the install image results in the OS not bringing up important hardware like network cards, then the software is effectively not working on such systems. And yes, of course it's possible to enable it, but you have to find out yourself because telling people about nonguix in any official docs or communication channels is disallowed.

> About the CPU microcode updates... why do you believe they are important? I mean, if your system runs arbitrary code off the Internet [...]

We call that a web browser.

> because telling people about nonguix in any official docs or communication channels is disallowed.

That's pretty bad. I'm definitely against that.

> We call that a web browser.

Are there known exploits based on web browser use, which are foiled by CPU microcode changes? Or, are these speculated to be possible?

> Are there known exploits based on web browser use, which are foiled by CPU microcode changes? Or, are these speculated to be possible?

The exploit certainly was possible: https://security.googleblog.com/2021/03/a-spectre-proof-of-c...

To what degree it's mitigated by CPU microcode patches or browser changes, I couldn't say off the top of my head. I suspect the situation has improved on both fronts.

Equivalently, what you're saying is that the world got more dependent on secret, proprietary software, and that therefore those who wish to have freer systems should just give up.

This is a very bad faith interpretation of what I wrote.

How about a less bad-faith formulation:

the world got more dependent on secret, proprietary software, and therefore the pragmatic way is to concede a little territory to them, so that people can use Free Software at all.

Except it's a lose-lose situation: there will never be an end to those concessions, as long as secret software expands under the guise of firmware. And a hardline stance will alienate new generations and starve the movement. The endgame is no Free Software in either scenario.

How is

"the world got more dependent on secret, proprietary software, and that therefore those who wish to have freer systems should just give up."

a "bad faith interpretation" of

"10 years ago it was not too hard to run a distro without firmware blobs on a laptop if you were cool with just getting a thinkpad, but modern intel hardware requires a blob for graphics so even that path is closed now. My 2022 thinkpad x1 needs blobs for graphics, wifi, bluetooth, and sound and I tried to find something modern that didn't need them and gave up eventually."

They can't distribute firmware blobs simply because FSF and GNU do not in principle participate in distribution of any non-free programs.

Also consider that if a manufacturer can distribute opaque firmware updates to your system, it practically has remote control over it, е.g. Intel can activate a backdoor in specific CPUs when needed by publishing a microcode update.

What is more risky to you: Leaving known vulnerabilities such as spectre unpatched or the possibility of Intel adding a backdoor for some unknown purpose that wasn't present in the shipped hardware?

The former is more risky from the security point of view. The latter is more risky from the freedom point of view. (And, while an FSF supporter, I choose to be more secure.)

Vulnerabilities such as spectre are only relevant if you run untrusted non-free software. Also these vulnerabilities show that sandboxing is not effective on current CPUs, and specific mitigations does not solve the problem in general.

Since nearly everybody uses devices that require firmware blobs, the policy has a huge negative impact, it should have a corresponding benefit to motivate its existence. But what can possibly make up repelling all but the hardiest users, who most likely will have to work around it by installing firmware blobs anyway? There are plenty of alternatives that just work. Sure, the users that can run without blobs deserve a reward, so show them a congratulatory message on boot or something.

There is precedent for not taking a hard line. Nearly all GNU software works on Windows, for entirely pragmatic reasons.

Reply on news.ycombinator.com