Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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.


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."




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: