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

41–50 of 205 posts

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

#41

Post by DarylZero »

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.

Apparently it's OK because both the vendor and the user are prevented from updating it. Thus there's no power differential between them on that specific point.

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

#43

Post by marcan_42 »

DarylZero wrote: post #39
marcan_42 wrote: post #36

Earlier quoted context omitted.

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…

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.

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

#44

Post by [deleted] »

oshiar53-0 wrote: post #18
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…

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…

[deleted]

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

#45

Post by thrwawy283 »

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…

I just wanted to say I appreciated this comment. You clearly condensed what the problem is, and now I feel like I better understand the situation. It does sound like hypocrisy but in an unworkable, non-starting situation for the FSF.

(Bravo.)

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

#46

Post by tedunangst »

kevin_thibedeau wrote: post #30
tedunangst wrote: post #27

Earlier quoted context omitted.

Sounds like a good reason to certify hardware that puts firmware in RAM.

Most peripheral ICs have an on board micro with internal RAM and flash. Their RAM isn't typically accessible.

Nevertheless, the first thing the driver for wifi in my laptop does is load up a big firmware file from disk, caused to be shoved into IC RAM, and then proceed to connect to the network. That this process could somehow become more free by embedding a frozen firmware image blows my mind.

And it's not like I haven't seen what the other side looks like. The Broadcom "full MAC" chipsets are also supported, with their remotely exploitable firmware. But those are also "fully" free. Hurray.

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

#47

Post by [deleted] »

not2b wrote: post #26
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…

Yes, they have a rationale, but it's a poor one. Followed to its logical conclusion, I can make any program free. All I have to do it put it in ROM. Then I can pretend it is part of the hardware. Software in ROM is not hardware, it's just software that can't be improved or fixed. The other point they ignore that if some part is programmable but currently requires proprietary firmware, it's possible (and this has happ…

[deleted]

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

#48

Post by ndiddy »

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…

The rationale seems to be that if the vendor is able to update the firmware at a later date, then the customer should also have that ability in order for it to be certified.

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

#49

Post by r283492 »

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…

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 guns will incentivize people to use knives, people who want to only ban guns for violence sake are hypocrites." There is a kernel of truth, but it's really just ignoring the bigger reality.

Post reply on HN