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

131–140 of 205 posts

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

#131

Post by thewakalix »

KennyBlanken wrote: post #124
voidhorse wrote: post #105

Earlier quoted context omitted.

I get what you’re saying, but this form of argument sort of talks past the stance of the RMS’s of the world. The fact that the software being used is proprietary is a historical accident and not an attribute of the software that makes it function a certain way—it’s entirely possible to write non-proprietary life saving software. RMS is arguing for principles and ideals. Sure when it comes down to it, it’s absurd to s…

You don't get what they're saying at all. There are about a thousand better ways he could have responded while still trying to convey his ideas. Instead, he said probably the single most offensive thing he could. He either did it on purpose to piss them off, or he didn't understand how offensive it would be, or he didn't care. He has no idea how to be persuasive, no idea how to adjust his arguments or present his ide…

Did he really say those specific words? It's common, on the internet, to use quotation marks to signify "here's what I think someone else is saying, it's not my own belief". (That is also an example of such a usage.)

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

#132

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

#133

Post by mlyle »

marcan_42 wrote: post #130
mlyle wrote: post #114

Earlier quoted context omitted.

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

> 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. The point is that is not feasible when the design layout is randomized. Reverse engineering FPGA bitstreams is a notoriously hard problem. You might detect your synthesis of RISC-V but there is no algorithm that can detect any RISC-V, an…

> With design randomization, you can make it hard to detect patterns like that. Think things like randomizing the polarity of each bit line going in/out of RAM. Again, the point is the backdoor has to work with any design, and this opens up a wide range of mitigations that you can implement at that stage, that make it a lot less practical.

This doesn't really work-- assume the adversary has your design. Then they can appropriately figure out how to get the right bits across some part of it that matters.

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

#134

Post by seanhunter »

marcodiego wrote: post #70
jeppesen-io wrote: post #66

FSF's hardline attitude has always rubbed me the wrong way. I respect and support their goals but at the end of the day software should respect the needs and desires of their users I saw this on the nonguix repo for all non free software for guix > Please do NOT promote this repository on any official Guix communication channels, such as their mailing lists or IRC channel, even in response to support requests! This i…

I understand your position, but it would be better if the compromise was made by "the other side".

Everyone always thinks it would be better if the compromise was made by the other side, don't they?

What you're describing is just a concession. A compromise is where neither side quite gets everything they want and both have to give a little.

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

#135

Post by emptysongglass »

KennyBlanken wrote: post #124
voidhorse wrote: post #105

Earlier quoted context omitted.

I get what you’re saying, but this form of argument sort of talks past the stance of the RMS’s of the world. The fact that the software being used is proprietary is a historical accident and not an attribute of the software that makes it function a certain way—it’s entirely possible to write non-proprietary life saving software. RMS is arguing for principles and ideals. Sure when it comes down to it, it’s absurd to s…

You don't get what they're saying at all. There are about a thousand better ways he could have responded while still trying to convey his ideas. Instead, he said probably the single most offensive thing he could. He either did it on purpose to piss them off, or he didn't understand how offensive it would be, or he didn't care. He has no idea how to be persuasive, no idea how to adjust his arguments or present his ide…

I disagree. The Buddha was the same way in his direct speech because the clarity of a message that would live on and instruct the lives of others thousands of years later was more important than appeasement at clarity's cost:

“Nanda, I do not praise the conception of a life even a little bit. I do not praise the conception of a [new] life for even one moment. Why is that? The conception of life is suffering. In the same way that even a little vomit stinks, Nanda, even the momentary conception of a tiny life is suffering. Nanda, a being for whom there is the arising of material form, establishment [in the womb], development, emergence [from the womb], sensation, intellect, volitions, consciousness, indeed, any being at all that is established, develops, and emerges, is miserable. Abiding [in the womb] is sickness. Emerging [from the womb] is old age and death. Nanda, for this reason, what profit is there for the one lodged in the womb, craving life so deeply?”

Nobody decided for Nvidia to make proprietary drivers for their graphics cards, neither is the customer blameless: Nvidia got its start making gaming graphics card long before it muscled into machine learning. Those gamers funded its purses and every time they did empowered the machine to continue its filthy work.

"But I need to play these games or I'll die," they cry. Well now they've got the data scientists over a barrel and it won't ever stop unless we start saying no.

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

#136

Post by marcan_42 »

mlyle wrote: post #133
marcan_42 wrote: post #130

Earlier quoted context omitted.

> 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. The point is that is not feasible when the design layout is randomized. Reverse engineering FPGA bitstreams is a notoriously hard problem. You might detect your synthesis of RISC-V but there is no algorithm that can detect any RISC-V, an…

> With design randomization, you can make it hard to detect patterns like that. Think things like randomizing the polarity of each bit line going in/out of RAM. Again, the point is the backdoor has to work with any design, and this opens up a wide range of mitigations that you can implement at that stage, that make it a lot less practical. This doesn't really work-- assume the adversary has your design. Then they can…

The idea for Precursor is that every user runs a different random build of the design.

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

#137

Post by iostream23 »

segfaultbuserr wrote: post #78
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…

> how big of a project would it be to create a fully libre (whatever you want to call you it) laptop? But what does it mean by "Libre"? You see, the entire disagreement is about a problem of our definition: How does one define "a hardware system without non-proprietary software"? Ideally, if every single chip in a computer has free hardware design down to the logic gate or HDL level, that would certainly qualify as 1…

You would make an EXCELLENT moderator or facilitator. You gave fair shrift and explanation to the various perspectives anc concerns this thread is full of. I will happily vote for you if you ever run for public office.

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

#138

Post by MathMonkeyMan »

oefrha wrote: post #58
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…

I referred to that when I mentioned "loopholes."

It's a contradiction for sure, but either you have a "libre" device with non-free components isolated over a serial interface, or you have a less capable device.

Disingenuous, maybe.

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

#139

Post by mlyle »

marcan_42 wrote: post #136
mlyle wrote: post #133

Earlier quoted context omitted.

> With design randomization, you can make it hard to detect patterns like that. Think things like randomizing the polarity of each bit line going in/out of RAM. Again, the point is the backdoor has to work with any design, and this opens up a wide range of mitigations that you can implement at that stage, that make it a lot less practical. This doesn't really work-- assume the adversary has your design. Then they can…

The idea for Precursor is that every user runs a different random build of the design.

The only thing that seems to be randomized in building precursor is the P&R seed.

https://github.com/betrusted-io/betrusted-soc/blob/main/betr...

That prevents attacks where you have a known place on the FPGA is naughty, but not when you have a lot of elements that are naughty on certain input.

It doesn't even really protect against known-naughty-place: there's not infinite freedom on P&R with fixed I/O locations.

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

#140

Post by throwaway81523 »

I had a discussion similar to this with RMS a while back and he seemed to think that the x86 and ARM architectures were completely hopeless for this because of the management engines etc. At that time there were credible attempts to build completely blob-free POWER9 systems, so Ifigured that was the thing to get once they got a bit more affordable. I don't think the Talos stuff ended up blob free, but it is way less blobby than x86 stuff. Maybe there is hope of blobless RISC-V systems some day.
Post reply on HN