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

51–60 of 205 posts

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

#51

Post by pabs3 »

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…

There are some old WiFi devices with libre firmware, but they only support old WiFi standards.

https://github.com/qca/open-ath9k-htc-firmware https://github.com/chunkeey/carl9170fw http://netweb.ing.unibs.it/~openfwwf/

Some also call into the initial version of their code that is in the ROM, and don't have enough RAM to update all of the ROM to the current code. Things like the Osmocom Baseband code also do this.

https://www.osmocom.org/projects/baseband/

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

#53

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

#54

Post by r283492 »

jancsika wrote: post #42

Anyone know if the mnt reform laptop is blob-less? https://mntre.com/media/reform_md/2020-05-08-the-much-more-p...

It has one tiny blob for ram initialization, people are looking into removing it. It may become RYF certified. Freedom wise, it is the best modern laptop.

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

#55

Post by pabs3 »

marcodiego wrote: post #40
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…

I questioned myself about it many times. AFAIK, the rockpi4 without WiFi is ryf-certifiable. DisplayPort may need blobs, but USB-C is used only for power.It has blob free FLOSS drivers for the GPU and VPU. Its arm trusted firmware is fully open source. So, yes it is possible to have a modern and affordable ryf-certified system.

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

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

#56

Post by marcodiego »

pabs3 wrote: post #55
marcodiego wrote: post #40

Earlier quoted context omitted.

I questioned myself about it many times. AFAIK, the rockpi4 without WiFi is ryf-certifiable. DisplayPort may need blobs, but USB-C is used only for power.It has blob free FLOSS drivers for the GPU and VPU. Its arm trusted firmware is fully open source. So, yes it is possible to have a modern and affordable ryf-certified system.

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.

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

#57

Post by marcan_42 »

r283492 wrote: post #49
giantrobot wrote: post #13

Earlier quoted context omitted.

> Why accuse the FSF of hypocrisy? If I ship some piece of hardware on a PC with its firmware burned into a ROM and do not provide the source (a binary blob), the FSF will happily say my hardware is RYF-certified. If I ship the exact same hardware with the exact same firmware as a binary blob but in Flash RAM or loaded at init by a driver they'll accuse me of not "respecting freedom". Same hardware. Same firmware. Sa…

The malicious/abusive parts of nonfree software are almost always tied to it's updatability. Avoiding updatable nonfree software prevents users from entering into an abusive relationship with a nonfree software vendor. https://www.gnu.org/proprietary/proprietary.en.html , 550 instances of malicious functionalities, I'd bet all instances are for software where the vendor can update it. Your argument is like "Banning g…

People keep bringing this up like proprietary software can always be unilaterally updated by the vendor. That's not how it works with firmware blobs, the vast, vast majority of the time. The user has the choice to run whatever firmware version they want, for as long as they want. They have strictly more freedom than if the software were not updatable, since they can choose the least evil version.

I can't believe people are still trying to use this argument. It's plainly evident that mutable software gives you more choice than immutable software. Making the argument that autoupdaters are evil and can be abused doesn't suddenly make all mutable software more evil than immutable software.

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

#58

Post by oefrha »

MathMonkeyMan wrote: post #3

I'm well out of my realm of expertise here, but I had a gut reaction to: > Libreboot, being FSF-recommended, also has this policy of disallowing firmware blobs in the source tree, despite it being a source of nothing but problems. Later the author points out how there isn't any contemporary libre hardware that would satisfy users (vaguely but reasonably described), and so "free" solutions utilize loopholes in the leg…

TFA is very specific about the harm done by FSF's policy, unfortunately you either missed the arguments or chose to left them out. E.g.

> The FSF “Respects Your Freedom” certification has a loophole so large you could drive a truck through it called the “secondary processor exception”.

> ...

> This means that users of the Librem 5 phone are objectively harmed in three ways: first, they are unaware of the existence of the blobs to begin with, second they do not have the ability to study the blobs, and third, they do not have the ability to replace the blobs. By pursing RYF certification, Purism released a device that is objectively worse for the practical freedom of their customers.

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

#59

Post by r283492 »

About the microcode: the argument is basically "It is good nonfree software, just give up and accept it." Sorry? This is FSF. And no, it is not always good: https://www.theregister.com/2018/08/21/intel_cpu_patch_licen..., and when people don't accept it, https://www.theregister.com/2018/08/23/intel_microcode_licen.... If a majority of intel's customers said: sorry, we'll find other solutions rather than accepting your nonfree license, intel would freely license it.

> In other words, you can’t microcode update a CPU to add or substantially change capabilities.

There is CCC security presentation floating around where someone reversed engineered microcode before it was signed, and designed a backdoor into it, a remote code execution triggered by going to a specific webpage. That is a substantial capability that exists in todays microcode.

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

#60

Post by marcodiego »

r283492 wrote: post #54
jancsika wrote: post #42

Anyone know if the mnt reform laptop is blob-less? https://mntre.com/media/reform_md/2020-05-08-the-much-more-p...

It has one tiny blob for ram initialization, people are looking into removing it. It may become RYF certified. Freedom wise, it is the best modern laptop.

Better than the pinebook pro?
Post reply on HN