18 years of the Linux fork that refuses to load the microcode that mitigates a range of CPU vulnerabilities
Never going to stop being angry about the subset of the free software community that would rather pretend that non-free software embedded in hardware doesn't exist than allow that non-free software to be replaced with equivalently non-free software that fixes bugs
I agree that hardware shouldn't embody non-free software! I also don't think we're giving up freedom by allowing people to replace the non-free software they already depend on with different non-free software!
@mjg59 and as a follow-up and service to the assholes that like to ship malware; If you wanna get past the filters of “open-source software or death” morons just keep shipping .rar files.

@mjg59 yes, exactly. I want my software:

  • free when possible
  • updated when possible
  • never hidden from me

@mjg59 A lot of hardware has to embed non free firmware because incorrect firmware could cause physical damage to the device, and also because there's not really much other firmware it can run.

Most of the embedded firmware hidden out of sight and often not even upgradeable is tiny tiny embedded sequencing and the like or a deeply embedded 8051 running a 40 byte program because it was simpler to paste that in that write custom logic for it

@etchedpixels I've patched the firmware for my laptop's embedded controller, I'd really rather have that freedom even though I could have fucked up the fan control in the process

@mjg59 Most of it is much more low level than that and in many cases you are talking about turning an input into an output and putting conflicting voltages on the same wire.

Fan control is minor. If your EC messes up the fan then you'll get a CPU shutdown, and maybe shorten the life of components a bit.

@etchedpixels @mjg59 Linux is certainly capable of destroying the machine it's running on when booting with device trees on some boards. It directly controls the pmics and can overvolt the cpu.
@etchedpixels
@mjg59 So what? Don't run out of spec firmware if you don't want to risk damage. If this is a safety critical device, sure, protect against altered firmware being loaded, and otherwise just make sure it requires physical interaction and that the system can attest to its firmware hashes. At the very least it should still be source available for audits and local changes even if those changes aren't redistributable.

@etchedpixels @mjg59 the producers could still provide the complete¹ source for that firmware, with the caveat that installing a custom firmware will void any kind of warranty

of course it would be an expense for the producers, and they have zero incentives to do so when even the niche that could have likely to be asking for it and buying from the few producers who did decided to ask for silly “proprietary firmware on a read-only chip” instead.

¹ availability of building tools etc. included

@valhalla @mjg59 A lot of deeply embedded firmware is hidden in ROM in devices people don't even know has firmware in the first place.

Eg you buy a USB adapter chip, or a trivial clock sequence generator but you've got no idea there's a whole 8051 buried in it.

@etchedpixels @valhalla @mjg59 yes, but how's that really different from other discrete logic?

@valhalla @mjg59 If you can update the firmware then other people can update your firmware.

That's a chunk of where the whole thing comes from. The number of custom firmware people is tiny, their usecase is non existent.

The number of bad actors who would like to make your firmware leak secrets or remote shutdown until you pay the ransom is probably larger.

Nothing about that *requires* it to be proprietary. It's *inadvisable* to change it if you don't know what you're doing, and you may well void the warranty, but that's fine.

There's plenty of Open Source audio routing configuration for which the wrong configuration will destroy a speaker and make literal smoke come out. That doesn't mean it should be proprietary instead.
@mjg59 This isn't a reason to oppose the freedom to modify, but one incentive that arises once you're able to replace it with new nonfree firmware is pressure to do so (e.g. software only works with the replacement now). This means you now have whatever malicious behaviors were in the original firmware plus whatever somebody decided to add once the hardware was in strategic positions. Even if I had this freedom I almost surely wouldn't use it. It feels like going from bad to worse.
@dalias @mjg59 The best protection would be to stop having laws that forbid affordable (non-cleanroom) reverse-engineering and other anti-interoperability laws.
@mjg59 In nearly four decades of computer-touching, I'm pretty sure I've only flashed a BIOS once: when the motherboard for my K6-III failed to support caching with more than 128 MB of RAM out of the box, but had a fix to allow more.
@dalias @mjg59 I also only did it once, and it was for a shitpost. I dumped my laptop's UEFI firmware using flashrom, did s/Intel Rapid Start™ Technology/Intel Rapid Fart™ Technology /g and flashed it back. It worked great!
@mjg59 I will never stop being angry that a company that sells root-of-trust (the most essential hardware) equipment is allowed to sell them as anything other than whitebox.
@mjg59 I wonder how they cope with USB-C cables with their embedded Cortex M0s...