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

111–120 of 205 posts

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

#111

Post by ziml77 »

yellowapple wrote: post #103

Not only does the FSF object to the inclusion of nonfree firmware, but it also objects to even so much as making it available. Case study here would be OpenBSD, which is about as free of an operating system as it gets, and which does not ship with nonfree firmware by default. However, because of the existence of the `fw_update` command (which - by the explicit consent of the user/owner of the machine - fetches any no…

They explicitly rationalize the Windows builds of Emacs, so I can only assume that's the same rationale as for any other GNU software

> To improve the use of proprietary systems is a misguided goal. Our aim, rather, is to eliminate them. We include support for some proprietary systems in GNU Emacs in the hope that running Emacs on them will give users a taste of freedom and thus lead them to free themselves.

Taken from https://www.gnu.org/software/emacs/download.html

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

#112

Post by R0b0t1 »

r283492 wrote: post #91
kryptiskt wrote: post #14

Earlier quoted context omitted.

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

You're taking the vendor at their word. You can't do this. It has happened before (see Intel vPro) that some feature is not actually impossible to activate, etc.

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

#113

Post by aragilar »

The author seems to limit their analysis to laptops. As far as I know, desktop/server class hardware does have reasonable options like those from Raptor Engineering (such as Talos: https://www.raptorengineering.com/TALOS/talos_comparison.php), though I could be wrong. Could this more of an issue relating to how laptops/phones are built/marketed/sold compared with desktops/servers (and given those effects, building a free-software-based laptop/phone is practically impossible given the lack of possible components)?

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

#114

Post by mlyle »

marcan_42 wrote: post #36
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…

That "libre" gives you auditability is a common myth believed by those pushing for libre hardware. The reality is you can't audit silicon, because it's a destructive process requiring extremely expensive analysis equipment. You always have to trust the chip manufacturer; doesn't matter how documented the chip design is, even if the masks are outright public. You can never know that your CPU is not backdoored. That's…

> There is one exception: FPGAs, under the premise that "generically" backdooring an FPGA is computationally infeasible.

IMO, this isn't a reasonable premise.

- The entire boundary scan chain is a backdoor. You could have an embedded processor poking around looking for things that look like RISC-V code and adding implants or observe state.

- You could make SERDESes do various kinds of naughty things when certain patterns go by-- dump some scan chain info, so you can kick some special packets and read out state remotely. Same thing for other dedicated peripherals that are connected to the outside world. This could be a pretty small number of gates compared to the processor implant idea.

- You could make naughty patterns of bits crossing places do bad stuff. Think of dynamic effects like rowhammer being deliberately included, so if you know the design you can figure out what outside data will trigger bits to flip and state to leak. (Yes, I know that block rams are SRAMs, but that doesn't mean you can't deliberately add capacitive coupling or screw up synchronizers in various ways. And it looks like we may have block NVRAMs soon, so that opens the possibility for various evil even more).

- You could deliberately break some kinds of operations-- e.g. make elliptic curve cryptography unreliable in some cases so you leak key data.

Note the various defense and national security applications of FPGAs. They're a wonderful target for state actors to try to backdoor.

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

#115

Post by Teknoman117 »

oshiar53-0 wrote: post #100
Teknoman117 wrote: post #37

Earlier quoted context omitted.

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 disco…

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

The FSF would not be okay with this though, as it would be a GPLv3 violation to prevent users from replacing the firmware with a modified version.

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

#116

Post by TT-392 »

garaetjjte wrote: post #7
roenxi wrote: post #4

> ...In other words, you can’t microcode update a CPU to add or substantially change capabilities... > ... vulnerabilities such as Meltdown and Spectre, which were partially mitigated through a microcode update ... Of these two snippets, only one can be true. Either opaque microcode updates can substantially change how a system performs, or they can't. These mitigations are major changes to how the processor works. T…

Yet they are fine with running microcode as long you don't update it. It doesn't make sense. Blobs don't disappear just because they are hidden in ROM.

That one kinda makes sense, because, when you can't update it, there isn't really much of a practical difference between something implemented in hardware or firmware. So not allowing blobs in rom would almost be hypocritical if you don't also mandate that the actual silicon of the chip is completely free.

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

#117

Post by csande17 »

comex wrote: post #108
csande17 wrote: post #32

Earlier quoted context omitted.

> The other point they ignore that if some part is programmable but currently requires proprietary firmware, it's possible (and this has happened) that people reverse-engineer it and produce free software that runs on it. If this is possible, then device makers should do it, ship the free-software firmware on the device, and then get it RYF-certified. No blobs needed, ROM or otherwise! Problem solved! It seems like a…

> If this is possible, then device makers should do it, ship the free-software firmware on the device, and then get it RYF-certified. No blobs needed, ROM or otherwise! Problem solved! The device maker could ship with programmable proprietary firmware and have the possibility of being RYF-certified in the future if someone writes free firmware. Or they could ship with proprietary firmware in ROM and be guaranteed RYF…

It sure sucks that device makers just have to wait and hope someone writes free firmware. If only they had some way to cause the firmware to be written, perhaps involving things like "money" or "employees" or "contracts with vendors".

The alternatives to this policy are allowing all blobs, in which case the RYF certification isn't actually verifying anything, or not allowing any blobs, in which case RYF cannot certify any devices made after 2009 (something the author also takes issue with). Making it expensive and risky for device makers to rely on blobs is the only middle ground that makes sense.

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

#118

Post by MathMonkeyMan »

giantrobot wrote: post #13
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…

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

This is what I missed, well put.

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

#119

Post by marcan_42 »

aragilar wrote: post #113

The author seems to limit their analysis to laptops. As far as I know, desktop/server class hardware does have reasonable options like those from Raptor Engineering (such as Talos: https://www.raptorengineering.com/TALOS/talos_comparison.php ), though I could be wrong. Could this more of an issue relating to how laptops/phones are built/marketed/sold compared with desktops/servers (and given those effects, building a…

Indeed, the Raptor systems are about as free as you can get for a desktop system, as far as I can tell. I was particularly impressed when they pointed me at the source code for their RAM training routine; that one has been a sticking point in many other systems.

They still aren't 100% free because that is impossible; there is no clear line to be drawn between hardware and software, and the hardware isn't free. But at least we can truthfully say they have no nonfree mutable blobs or large ROMs, and even some critical small ROM blobs are documented and open source, like the CPU boot ROM.

(We can't say there are no nonfree ROM blobs - I guarantee there's a small CPU running nonfree ROM code somewhere in an IC on the board and they just don't know about it, because manufacturers do that all the time - and besides, even if their systems somehow avoid that, your monitor, keyboard, and mouse will all have that problem).

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

#120

Post by neilv »

BrS96bVxXBLzf5B wrote: post #110
neilv wrote: post #104

Earlier quoted context omitted.

I don't know how much to read into this anecdote, given a related one from around the same time... In a discussion with RMS, after a little argument, he agreed that the immediate safety of certain underdogs who needed secure communications trumped libre software goals. (The question was something about the libre software solution at the moment being inferior for some threat model.)

That's interesting! He was definitely playing an antagonistic character ("I have a bad ear", "I can't hear you" whenever someone said something disagreeable; one person didn't get it and kept repeating their sentence more loudly to no change). I could imagine him having that more liberal private stance whilst keeping the public one consistently firm.

RMS seems absolutely uncompromising on his principles (whether publicly, or in smaller groups), but I think his principles aren't only about libre software.

Maybe the difference between the two anecdotes was details of what was being weighed against libre software. In his value system, maybe the success of an underdog's mission (maybe for a different kind of freedom) is more important than lives saved? Or maybe he was just feeling punchy in one of the meetings?

Post reply on HN