Recently posted comments
Perfection is the enemy of good
Posted Oct 15, 2025 18:26 UTC (Wed) by farnz (subscriber, #17727)In reply to: Perfection is the enemy of good by ballombe
Parent article: The FSF's Librephone project
Not according to lawyers I've spoken to - either the firmware is not replaceable at all, in which case it's hardware, or it's replaceable by a service team, in which case it's firmware.
There is no case where firmware gets treated specially just because you need a common household tool to change the firmware - that's the same, as far as the lawyers I've spoken to, as firmware that's soft-loaded by a software tool.
Perfection is the enemy of good
Posted Oct 15, 2025 18:24 UTC (Wed) by ballombe (subscriber, #9523)In reply to: Perfection is the enemy of good by farnz
Parent article: The FSF's Librephone project
Because in this case, the firmware count as hardware as far the law and regulation are concerned.
Perfection is the enemy of good
Posted Oct 15, 2025 18:09 UTC (Wed) by farnz (subscriber, #17727)In reply to: Perfection is the enemy of good by cesarb
Parent article: The FSF's Librephone project
I had a CRT TV towards the end of the CRT era that had literally one chip in it, and might well have had software in mask ROM not internal flash. That would count, to me, as genuinely hard-coded software per RYF terminology, since an embedded mask ROM (unlike embedded flash) needs you to replace the entire chip to rewrite it.
Perfection is the enemy of good
Posted Oct 15, 2025 17:59 UTC (Wed) by cesarb (subscriber, #6266)In reply to: Perfection is the enemy of good by pizza
Parent article: The FSF's Librephone project
Most analog CRTs I've used (both computer monitors and TVs) had on-screen menus. I'd have to go back to my very first computer monitor and my very first TV (that TV had fully mechanical controls, including a nice rotating knob to choose the channel with a fine-tune collar around it) to find an analog CRT without some form of built-in software.
Perfection is the enemy of good
Posted Oct 15, 2025 17:57 UTC (Wed) by farnz (subscriber, #17727)In reply to: Perfection is the enemy of good by ballombe
Parent article: The FSF's Librephone project
I don't see how what you're saying follows from what I'm saying.
The FSF says it's fine for a firmware to be vendor-replaceable proprietary firmware, as long as you need to open the case of the device to change the firmware.
I don't see how the difference between "rights and liabilities" for hardware and firmware matters here - in both cases, we're talking about changing the firmware. It's just that the FSF tells me that it's a device is fine, per RYF rules, if replacing the firmware needs a conductive screwdriver, but not if replacing the firmware would need me to toggle a switch on the case.
And I don't see how the need for a conductive screwdriver (or a non-conductive one and a piece of wire) makes a material difference here.
Perfection is the enemy of good
Posted Oct 15, 2025 17:46 UTC (Wed) by ballombe (subscriber, #9523)In reply to: Perfection is the enemy of good by farnz
Parent article: The FSF's Librephone project
If hardware vendors were willing to distribute firmware with the same right and accept the same liability as for hardware, the FSF position would be different.
As it stands, there is a considerable advantage for a vendor to use the firmware terms, since they can disclaim all warranties and limit users rights.
Perfection is the enemy of good
Posted Oct 15, 2025 17:38 UTC (Wed) by pizza (subscriber, #46)In reply to: Perfection is the enemy of good by farnz
Parent article: The FSF's Librephone project
Speaking from experience, the long-obsolete Prism2/3 802.11b wifi adapters also fell into this trap; at initial introduction they would have qualified as RYF as there was no non-OEM way to update the firmware. (The hardware always supported it, but the tools were not publicly available). Once OEMs started releasing firmware update packages out of sheer necessity (due to severe showstopper firmware bugs) the devices no longer would have qualified as RYF.
However, the update procedure carried a nontrivial chance of bricking the device, so OEM drivers switched to a so-called "Ram Load" procedure where the latest firmware was downloaded into the device at runtime. [1] This technique proved so successful that the final hardware iterations eliminated the "large" parallel flash in favor of a small serial eeprom as a cost-cutting measure.
To recap: Firmware in flash with no non-OEM way to update: "RYF". Firmware tools provided to end-users (providing a mechanism to address potentially severe bugs that the OEM has already fixed): No good. Download said firmware at runtime: Get thee behind me Satan! (Despite the firmware -- and hardware -- being *completely identical* in all three cases.
With vanishingly rare exceptions, *all* non-trivial hardware produced over the past couple of decades has some sort of embedded processor running some sort of field-updateable firmware. Because it's the smart engineering (and increasingly, legal/regulatory) choice.
[1] This was only possible because the firmware was already designed to run from RAM; the contents of flash were copied over to RAM with various parameters (eg mac address, operational region, and production trim) "plugged" into the appropriate places.
Perfection is the enemy of good
Posted Oct 15, 2025 17:30 UTC (Wed) by farnz (subscriber, #17727)In reply to: Perfection is the enemy of good by Trelane
Parent article: The FSF's Librephone project
I've raised it with the FSF; they've said that it's OK, because I had to open the cases to change the firmware, and anything where you need to open the case does not count.
Perfection is the enemy of good
Posted Oct 15, 2025 17:24 UTC (Wed) by Trelane (subscriber, #56877)In reply to: Perfection is the enemy of good by farnz
Parent article: The FSF's Librephone project
Perfection is the enemy of good
Posted Oct 15, 2025 17:06 UTC (Wed) by farnz (subscriber, #17727)In reply to: Perfection is the enemy of good by Trelane
Parent article: The FSF's Librephone project
Define "hard code".
Let's use the various non-volatile storage options in a typical microcontroller as a guide.
- There's the internal ROM. This is mask programmed, and is set permanently at the time the chip is manufactured. Nobody can change it after that - you have to change the chip to change its contents.
- There's the OTP eFuses. These can be written exactly once after the chip is manufactured, and cannot be written again once they've been written once.
- There's internal flash, which can be in one of several states:
- Read-only, cannot be written.
- Only writable if you can digitally sign the data you want to write, otherwise it's indistinguishable from the read-only state. Without the private key, you cannot distinguish this from read-only.
- Only writable if you connect to external pins correctly, not writable from software running on the MCU. This may, or may not, require a correct digital signature as in the previous state.
- Writable by anyone who can get code execution on the MCU, possibly needing an "unlock" sequence to go from read-only to writable.
- There's external flash, which can be in one of two states, and which may be encrypted with a key in any of the above storage methods:
- Writable under control of the MCU.
- Read-only from the MCU's perspective, writable with external tools
At what point in that list do you consider it hard coded?
I think it's unarguable that the internal ROM is hard coded - it's literally a diode matrix in the chip, generally. I'd also be willing to argue that, once written, the OTP eFuses are hard coded, since nobody can change them
If you could prove that the internal flash was stuck in read-only state, then I'd agree that's also hard coded. However, actually showing this is hard, because you have to show the non-existence of either a magic unlock sequence that will transition it to a writeable state, or a digital signature check that will permit writes if I only knew the asymmetric crypto key. Worse, this needs not just the final device vendor involved, but the chip maker - I've dealt with more than one device where the internal flash was "read-only" according to the final device vendor, but the chip maker (with whom we had commercial ties) happily let us know about the back door to make the flash writable again.
And I'm never willing to consider external flash read-only - I've yet to encounter a device with "read-only" external flash that I can't write to without getting the soldering iron out. Even if I did encounter one where I needed the soldering iron to write to it, I'd still consider it writable unless I had to remove the flash chip completely from the board - if all I need to do (as is common on RYF devices) is solder a wire bridge over a cut track, then it's writable as far as I'm concerned.
Crashes with GCC 15.2
Posted Oct 15, 2025 17:03 UTC (Wed) by atai (subscriber, #10977)In reply to: Crashes with GCC 15.2 by azz
Parent article: Firefox 144.0 released
Mixing variants
Posted Oct 15, 2025 17:00 UTC (Wed) by abatters (✭ supporter ✭, #6932)Parent article: A new API for interrupt-aware spinlocks
spin_lock_irq(&irq_aware_lock1);
spin_lock(&irq_aware_lock2); /* irqs already disabled */
The irqsave variant is for situations where you don't know if interrupts are already enabled or disabled.
If you release the two locks above out-of-reverse-order, you would enable irqs on the last unlock:
spin_unlock(&irq_aware_lock1);
...
spin_unlock_irq(&irq_aware_lock2);
The new API will perhaps make this pattern less confusing.
Perfection is the enemy of good
Posted Oct 15, 2025 16:33 UTC (Wed) by mb (subscriber, #50428)In reply to: Perfection is the enemy of good by pizza
Parent article: The FSF's Librephone project
This is not as clear cut as you make it seem like.
Why is an algorithm running on a processor core implemented in C executing from an OTP memory different from running the same algorithm in hardware synthesized from HDL?
From a freedom perspective this is not different at all.
How would you even *know* whether the chip runs software or implements the same thing in pure silicon?
It doesn't make a difference.
There are so many chips these days that run not upgradable software internally and it's not visible at all from the outside.
Perfection is the enemy of good
Posted Oct 15, 2025 16:14 UTC (Wed) by farnz (subscriber, #17727)In reply to: Perfection is the enemy of good by Trelane
Parent article: The FSF's Librephone project
The law says that the product has to (a) not have certain capabilities, and (b) be locked down so that a "normal" consumer cannot easily modify the device to have those capabilities. A device sold such that you need the manufacturer's private key to change the firmware meets the letter of the law, even if an alternative firmware would enable illegal capabilities, and regardless of whether the firmware itself is Free or proprietary.
Perfection is the enemy of good
Posted Oct 15, 2025 16:11 UTC (Wed) by farnz (subscriber, #17727)In reply to: Perfection is the enemy of good by Trelane
Parent article: The FSF's Librephone project
E.g. this certified RYF device has upgradeable proprietary firmware, as long as you're the OEM and not the user. Similar for this certified RYF device - again, the firmware is upgradeable, just not by the user (you need special tooling that the user won't necessarily have in both cases).
And that's just the ones I'm able to personally confirm that have upgradeable firmware given the tooling I have in my home lab. I'm pretty certain, based on the track record, that I'd see the same if I grabbed other RYF devices that do RF - devices with upgradeable proprietary firmware, where the in-field upgrade circuitry has been cut, but the firmware can still be upgraded by someone with the tools to clip onto the flashing lines.
Perfection is the enemy of good
Posted Oct 15, 2025 16:04 UTC (Wed) by Trelane (subscriber, #56877)In reply to: Perfection is the enemy of good by Wol
Parent article: The FSF's Librephone project
Perfection is the enemy of good
Posted Oct 15, 2025 16:03 UTC (Wed) by farnz (subscriber, #17727)In reply to: Perfection is the enemy of good by Trelane
Parent article: The FSF's Librephone project
Note that not all binary blobs are software with source (at any point in their history). Some are data tables, where they're separate to the hardware because it's cheaper and faster to fab a chip without the data tables built in, and supply them later than it is to leave space for a mask ROM and a sequencer to try each line in the table separately, fab without the mask ROM, and respin with the mask ROM.
I'd agree that we should know what the data table is, but it can be "list of values to try on the R_offset register for each lane - see the documentation for the R_offset registers for more", rather than "binary code produced by compiling source".
Perfection is the enemy of good
Posted Oct 15, 2025 16:03 UTC (Wed) by Trelane (subscriber, #56877)In reply to: Perfection is the enemy of good by farnz
Parent article: The FSF's Librephone project
Where does it say this?
Perfection is the enemy of good
Posted Oct 15, 2025 16:02 UTC (Wed) by Trelane (subscriber, #56877)In reply to: Perfection is the enemy of good by pizza
Parent article: The FSF's Librephone project
Yes, user-serviceable software would be better.
Perfection is the enemy of good
Posted Oct 15, 2025 16:00 UTC (Wed) by Trelane (subscriber, #56877)In reply to: Perfection is the enemy of good by pizza
Parent article: The FSF's Librephone project
Yes exactly.
> And not just illegal to use, but illegal to produce/sell with those capabilities in the first place.
If that is the case why are they producing hardware that does not comply with theaw?