Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The FSF’s relationship with firmware is harmful to free software users

ariadne.space

Post reply on HN
Print view View original

91–100 of 205 posts

Re: The FSF’s relationship with firmware is harmful to free software users

#91

Post by r283492 »

kryptiskt wrote: post #14
jeroenhd wrote: post #5

I think the ideology of the FSF is a perfectly fine one. It's the hardware vendors that insist on binary blobs that are the problem here. Nobody produces truly free consumer hardware and nobody has produced any for years now. Everything is hidden away because of fears of patent lawsuits and other people copying this One Neat Trick when initializing the devices. Intel would lose very little if it published the source…

> I think the ideology of the FSF is a perfectly fine one. It's the hardware vendors that insist on binary blobs that are the problem here. Their ideology has led them into preferring proprietary firmware that is inaccessible to the user like in the Purism example. I hate that, there is hope that a device that requires binary blobs from the main OS can be reverse engineered and free software developed for it. Making…

> Making it inaccessible to tinkering is strictly worse for the user in all respects.

"all respects" is wrong. It also makes it so the proprietary developer can't say "here is a new version, but you must agree to some very nasty license terms, or accept some malicious feature along with it." NOT having a capability does have advantages, a physical book is impossible to be remotely deleted out of existence by DRM, but sure, you can't tinker with the software.

edit: yes, I understand in that the case of sticking the exact same software in a rom vs a read-write memory hurts the ability of a user reverse engineering it, which could ironically decrease user freedom over time. Calling this out for FSF to address is a good thing.

Re: The FSF’s relationship with firmware is harmful to free software users

#92

Post by chii »

d0mine wrote: post #89
BrS96bVxXBLzf5B wrote: post #74

Attending an RMS talk at a university ~8 years ago, some (increasingly irritated) lecturers questioned him on the use of proprietary graphics drivers in image processing for use in medical equipment and research. While RMS argued his absolute stance that proprietary drivers are never permissible, the lecturers argued that the drivers were literally saving lives and people would die without them. "They should die for…

Imagine you are fighting for peasants rights; feudal doesn’t like it and orders to kill one peasant per day until you surrender. Question are you the bad guy for not surrendering?

> are you the bad guy for not surrendering?

those peasants who died are killed by the feudal lord, so no - 100% not the bad guy for fighting.

The only way you could be considered a bad guy is if you used peasants as suicide bombers - and only if those people didn't volunteer.

Re: The FSF’s relationship with firmware is harmful to free software users

#93

Post by zauguin »

wmf wrote: post #22
oshiar53-0 wrote: post #18

Earlier quoted context omitted.

See https://www.fsf.org/campaigns/free-bios.html for the rationale. Basically, FSF had to make a compromise here. If you use Flash ROM (or other writable medium), the firmware counts as a nonfree software . However, if you use actual ROM, the firmware might as well have been a circuit baked right in the product, so it counts as hardware ; nevertheless, it counts as non-free. FSF's ultimate goal would of course be to…

The FSF had to make a compromise, but many people think they drew the line in the wrong place. When no reasonable hardware can meet the "compromise" version of RYF it just causes users to bounce off.

I think the issue isn't that much that no reasonable hardware can archive it, but that the "compromise" actively encourages not just insecure systems, but also making systems even less free.

It's a bit like saying that a Windows notebook is only "free" if you can't install other systems and updates are disabled. There probably is more or less reasonable hardware which could implement these restrictions, but such hardware would in no way be more "free" than a notebook where you could just install Linux.

Re: The FSF’s relationship with firmware is harmful to free software users

#94

Post by [deleted] »

marcan_42 wrote: post #43
DarylZero wrote: post #39

Earlier quoted context omitted.

You can still backdoor a FPGA in the style of Reflections on Trusting Trust... wait for known code to be installed into the FPGA and then patch it.

"Known" is the key word. You can randomize an FPGA design's layout and synthesis details, and it is impractical to implement dynamic reverse engineering of the design in order to patch it (certainly in an undetectable way - that's more compute power you'd need than was available to begin with). That's the premise behind Precursor, that users can run their own randomized bitstream, not a shared build.

[deleted]

Re: The FSF’s relationship with firmware is harmful to free software users

#95

Post by pabs3 »

marcodiego wrote: post #56
pabs3 wrote: post #55

Earlier quoted context omitted.

I expect the USB-C chip has proprietary software running on it, since USB-C chargers have more computing power than the Apollo 11 Guidance Computer: https://forrestheller.com/Apollo-11-Computer-vs-USB-C-charge...

Fully ROM, secondary processor. Ryf-certifiable.

Software in ROM is worse, since you can't pull vendor updates to fix any security bugs and you can't reverse engineer it, produce free firmware and replace the proprietary firmware.

Re: The FSF’s relationship with firmware is harmful to free software users

#96

Post by marcodiego »

floatingatoll wrote: post #85
marcodiego wrote: post #75

Earlier quoted context omitted.

Hmmm... I like RK3399-based devices because they need very few blobs. Would you mind to list which blobs the pinebook pro needs?

https://forum.pine64.org/showthread.php?pid=97828 The above link contains the answers applicable to your question.

The imx.8 can't even initialize RAM without blobs. If it comes with a modern WiFi it will need blobs too. Don't know the details about the display, but I don't think it affects all RK3399 devices.

Re: The FSF’s relationship with firmware is harmful to free software users

#97

Post by koprulusector »

I’m confused. Who’s the target audience of this post? Anyone strictly adhering to FSF recommendations is most likely not a for profit business, and therefore probably doesn’t give a care about spectre or meltdown, for example. I for one add mitigations=off to all my personal systems boot flags.

Re: The FSF’s relationship with firmware is harmful to free software users

#98

Post by marcodiego »

pabs3 wrote: post #95
marcodiego wrote: post #56

Earlier quoted context omitted.

Fully ROM, secondary processor. Ryf-certifiable.

Software in ROM is worse, since you can't pull vendor updates to fix any security bugs and you can't reverse engineer it, produce free firmware and replace the proprietary firmware.

And then we fall on the whole subject we're discussing here. In this particular case, a "power controller chip" I can even consider a fix or a change that improves efficiency... Nevertheless, I doubt most devices allow the update of a firmware for such a thing, in the end, it wouldn't make much of a difference.

If the firmware is open source, sign me in! No opposition! Neither from me nor from the FSF. FSF would not oppose libre firmware.

If it is not open source... well, then this is discussed in the other comments.

Re: The FSF’s relationship with firmware is harmful to free software users

#99

Post by smoldesu »

BrS96bVxXBLzf5B wrote: post #74

Attending an RMS talk at a university ~8 years ago, some (increasingly irritated) lecturers questioned him on the use of proprietary graphics drivers in image processing for use in medical equipment and research. While RMS argued his absolute stance that proprietary drivers are never permissible, the lecturers argued that the drivers were literally saving lives and people would die without them. "They should die for…

In the case of medical training, you're taught that you should assume an incapacitated person would like to receive care unless otherwise instructed. I think that pretty easily carries over to software licensing too; unless your patient refuses to receive treatment aided by proprietary software, you should assume that they're comfortable having their body fed to the proprietary meat-grinder.

Re: The FSF’s relationship with firmware is harmful to free software users

#100

Post by oshiar53-0 »

Teknoman117 wrote: post #37
irfwashere wrote: post #28

If you'll forgive my naivete here I've been thinking a lot about the FSF philosophy and wanted to ask HN: how big of a project would it be to create a fully libre (whatever you want to call you it) laptop? Like how feasible is it to use "free" components put together into a package and what kind of budget would be required? I think China has a few companies working on domestic processors. Let's say they are convinced…

For something considered modern, pretty much next to impossible. All of the modern CPUs require blobs to function, whether it's microcode, embedded firmware, binary driver blobs, or otherwise. I don't believe there is a wireless card (wifi, Bluetooth, etc.) on the market that doesn't use binary, closed source firmware. In fact, it's almost mandated by law that there can't be. FCC regulations require that devices be m…

> it's almost mandated by law that there can't be. FCC regulations require that devices be made resistant to attempts to change their function in an effort to limit people's ability to transmit stuff unintentionally (or intentionally). Modern radio protocols are heavily dependent on SDR (software defined radio), so fixed function is probably infeasible. You could make the firmware unchangeable, but now any bugs discovered in your public source code are now entirely uncorrectable.

1. You can use signed firmwares to make it both compliant and upgradable.

2. You can separate the controller/receiver and the transmitter, and only lock up/restrict the transmitter part. Alternatively, you can implement the restriction at the hardware level if feasible (effectively making it fixed function).

3. Finally, you can sell the parts individually to serve a separate market segment.

Post reply on HN