Live data from Hacker News

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

ariadne.space

31–40 of 205 posts

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

#31

A 2009 thinkpad is rather capable of being a daily driver for most people. Saying otherwise, you're only contributing to the growing problem of ewaste. Even the T60 offers a decent performance if your usecase is browsing the web, mail and other simple tasks. The FSF might be wrong in some aspects but there's no real alternative to Libreboot. The Framework laptop is not free software friendly. Even if it was coreboote…

That 2009 ThinkPad that the FSF certified is running proprietary blobs in updatable microcontrollers connected to the LPC bus which have full access to RAM and to take over the OS. Blobs which you can't audit, modify, sandbox, nor verify are the correct intended version.

I'd rather buy an M1; sure, it runs a pile of blobs, but at least I know those blobs are there and they're all sandboxed behind IOMMUs and cannot take over or compromise my OS.

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

#32
post #26

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…

> 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 feature, not a bug, that the RYF certification process makes it more painful and expensive to release devices that rely on proprietary software.

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

#33
post #2

Properly isolated accessory non-free hardware is a good thing, and for a user whose threat model requires libre hardware, the security model of the PinePhone or Librem 5 where the LTE modem is isolated with a kill switch to interact via USB (rather than connected via PCIe, which would have direct memory access) is the right choice. Is a Thinkpad T400 with a Core2Duo and SSD the right choice in 2022? What about a Pine…

FYI, that ThinkPad T400 that the FSF certified has multiple microcontrollers running proprietary updatable blobs on the LPC bus with full access to DMA to all of system memory. I am literally more insulated from blobs with an Apple M1, which runs a dozen blobs none of which can take over my OS (thanks to pervasive IOMMU use), than with hardware that the FSF claims "respects my freedom".

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

#34

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…

[deleted]

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

#35

Earlier quoted context omitted.

People are parroting "the purism example...". Just stop it! Librem-5 is NOT certified!

But they want to be certified, and the hilarious RAM initialization workaround was absolutely done as part of trying to get certified.

Here's where Purism says that the reason for the workaround is indeed for attempting to get RYF certified: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...

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

#36

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 just a physical reality.

There is one exception: FPGAs, under the premise that "generically" backdooring an FPGA is computationally infeasible. That's how Precursor gets to seriously claim trustability.

https://www.crowdsupply.com/sutajio-kosagi/precursor

But if you want more than a 100MHz RISC-V softcore you're going to have to trust the silicon vendor.

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

#37

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

Heck, even the SDR community is having to be really careful about not drawing the ire of the FCC. That's why so few of them tend to advertise transmit capabilities.

The main ARM cores have been generally blob-less, but that's only the cores. Various SOCs require blobs to initialize. Their GPUs are all proprietary blobs up and down the stack.

So you basically would have to make your own GPU, your own radios, etc. and integrate them into your own SOC - and get the regulatory bodies to certify them for sale in their various countries. You then have to fight the entrenched companies in court over IP for years. The GPU portion will be especially tricky. The moment you try, lawyers from Nvidia, AMD, Imagination Technologies, Apple, etc. will be all over you. The radios will have Qualcomm, Broadcom, and Intel all over you.

So technical, legal, and regulatory hurdles - which is why I say next to impossible, especially on the FSF's budget.

- a jaded hobbyist

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

#38
post #35

Earlier quoted context omitted.

But they want to be certified, and the hilarious RAM initialization workaround was absolutely done as part of trying to get certified.

Here's where Purism says that the reason for the workaround is indeed for attempting to get RYF certified: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...

At most, the Purism case is a good a example of how hard it is to game the certification.

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

#39

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…

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.

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

#40

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.

Post reply on HN