If we wanted secure products, we wouldn't ban devices. We'd mandate they open their firmware to audits.
The OpenWRT One [1] sponsored by the Software Conservancy [2] and manufactured by Banana Pi [3] works lovely.
[1] https://openwrt.org/toh/openwrt/one
[2] https://sfconservancy.org/activities/openwrt-one.html
[3] https://docs.banana-pi.org/en/OpenWRT-One/BananaPi_OpenWRT-O...
The difficulty of installing OpenWRT or Linux in general on hardware comes from that hardware not being documented, or not having straightforward APIs like BIOS/EFI.
Or for some devices, community distributions that dubiously remix manufacturer-supplied binaries are available. But we generally see that as soon as the manufacturer stops their updates, the community versions start lagging behind as well.
Oh, no, not this again!
> But we generally see that as soon as the manufacturer stops their updates, the community versions start lagging behind as well.
Care to demonstrate that?
The reason OpenWrt abandoned most routers was
1) insufficient flash space in the kernel partition, or insufficient total flash space in no-USB, no-SPI routers,
2) unwillingness to repartition flash because it breaks compatibility with official firmware (as if anyone installing OpenWrt would care),
3) insufficient RAM to run newer kernels
and, most importantly,
4) unwillingness to support older kernels like DD-WRT does.
What are you referring to? Would you not say there is a difference between OpenWRT having to make a list of supported whole systems, whereas an amd64 Linux distribution making a list of chipsets? I can go buy an off the shelf laptop, stick a generic "Linux install" USB in it, and be reasonably certain most things are going to work. Whereas OpenWrt I have to look at their list of supported machines, and buy exactly that one, even down to the hardware rev. Some of this is due to embedded constraints, but a good chunk is also due to the lack of hardware discoverability.
>> community distributions that dubiously remix manufacturer-supplied binaries are available
> The reason OpenWrt abandoned most routers was
I didn't mean things like OpenWrt, which I'd say is a general Linux distribution that does contortions to fit on specific devices. Rather I was talking about things like Valetudo which are closer to rooting the stock distribution with some tweaks, or the countless "custom ROMs" you see (saw?) in the phone world which are effectively remixing the manufacturer images. I thought DD-WRT was in that camp, especially for many devices (eg where do these "older kernels" come from?), but I'm hazy on that.
(personally I gave on up OpenWrt some 10 years back, and just use generic Linux (NixOS) on amd64. A VM on my server for the router, and lower-power amd64 boards for the additional APs (most of which double as Kodi terminals))
Oh, God, I have to repeat it again.
That's because of x86 standards for APICs, keyboard controllers, USB controllers, framebuffer addresses, PnP buses, storage controllers, etc. It has nothing to do with the BIOS, and has even less to do with UEFI, since it removed standard BIOS real mode interrupts (UEFI CSM).
ARM's only standard is CPU instructions. Each chip has different peripherals and each one needs a different driver. ARMv7 didn't even have a standardized timer! How can you expect to run anything without knowing where's the timer? UEFI and ACPI tries to patch it up with software, but the device tree is a better alternative because it can be updated, bug fixed and extended by the end users.
Let me give you a real example, something I did last week:
I have a Radxa Rock 5 ITX. The M.2 E-key slot has PCIe lines but no separate line for eSATA (the E-key doesn't have those). But the CPU has a mux that can switch those PCIe lines into SATA lines. It's in the device tree. Radxa makes a passive SATA adapter for the E-key slot (I bought it), but it doesn't switch the mux by itself.
Rockchip uses device tree. The mux is in there. Radxa didn't write an overlay for the device tree to switch the mux into SATA mode. I wrote that myself. It's a simple PCIe status="disabled" / SATA status="okay".
If Rockchip used UEFI instead of device tree, there would be absolutely nothing I could do if Radxa didn't explicitly add a setting for this mode change. And if they didn't write an overlay as simple as that, I very much doubt they would implement in UEFI.
I couldn't make sense of the second portion of your reply. What are you saying? That is preferable to be able to update a crap OEM distro instead of completely replacing it with something that is derived from mainline Linux kernel and ordinary Linux userspace?
OpenWrt only does "contortions" because routers have various ethernet and wifi configurations. Some have an oboard switch, some don't, some have WAN / LAN ethernet ports, some only have WAN and wifi. They're going very much towards standardization, not "contortions".
DD-WRT doesn't take anything from the original firmware, well... maybe some blobs. AFAIK (I didn't use it much), the old kernels are official Linux kernels. They're just older versions that still work with drivers and blobs that were abandoned and no longer updated by the OEM.
Why? You'd need to get someone electorally useful involved. That, unfortunately, elimiates a lot of the nihilistic, holier-than-thou tech types. But that's pretty doable nowadays. You just need an electorally-relevant group of people on your side.
In its defense, there's some practicality to it; we wouldn't say that a "get out of debt" plan that involved spending all available money on lottery tickets is worthwhile because "its not gonna happen". But defeatism is just a shortcut to say "I don't want to talk/think about it" in many cases.
And in this one, if the US Gov't required that all routers purchased by any agency they could influence had the ability to run open source code it would certainly shake up the market.
Even if this wasn't done, at the very least they must publish their software testing procedures, the way UL, ETL, and CSA require to certify devices for the US power grid. (https://www.komaspec.com/about-us/blog/ul-etl-csa-certificat...) They can also do black box testing.
But ideally they would actually inspect the software to ensure its design is correct. Otherwise vibe-coded apps with swiss cheese code will be running critical infrastructure and nobody will know until it's too late.
If the software is an important differentiator (arguably, it is for things like Ubiquiti, but clearly it is not for most consumer routers), then release the patches under the Business Source License with a 3-5 year sunset back to BSD / Apache / GPL.
If it was required they would do it.
Self ownership and full 'right to repair' has carve-outs in the FCC's regulations in the name of limiting unintentional broadcasting/radiation. Maybe a challenge to those would survive in the post-Chevron environment. I wouldn't expect any Congress in the last 25 years to pass a law which would go against the incumbent telecom lobbyist interests though, and I'd expect such a hole if it did hit case law, to get 'patched' fairly quickly.
About the only way to really solve that would be to embarrass vendors enough to open their moats.
(To be clear, I don't think that's good enough; at a minimum I think there should be a wifi card that does refuse modifications and a main application processor that is 100% user controlled so that they can actually fix problems without needing the vendor to help, but I think it's useful to point out that auditing code doesn't require being able to install it)
This is already the case today with many embedded devices. They have secure boot enabled so even if the vendor releases the GPL source code (big if), you can't do anything because the device will only boot the vendor's signed firmware.
> at a minimum I think there should be a wifi card that does refuse modifications and a main application processor that is 100% user controlled so that they can actually fix problems without needing the vendor to help
This is already possible. The RF components frequently have a signed firmware blob that is verified on load. There is no reason but planned obsolescence and greed keeping the application processor locked to running the vendor's signed code.
That sounds like what Software Freedom Conservancy would call a GPL violation:
https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017...
Sure, it is. So what? Have you got 200k for lawyers and years of your life to spend in court fighting over it?
I have personally contacted the SFC with ample evidence of deliberate and wilful GPL violations, such as providing a written offer for source code and then ignoring or flat out refusing requests for the source code. The SFC has acknowledged the vendors are violating the spirit and letter of the GPL.
Nothing happens. The SFC is one organisation with limited resources, FOSS developers don't want to spend their time in court, they'd rather develop software. Vendors know 9 times out of 10 they will get away with the GPL violation scot-free.
It's fine to put on your rose colored glasses and pretend GPL forces companies to release source code. Reality is, the vendors have a larger marketing budget than the entire SFC endowment and the vendor's legal team is happy to tar-pit requests ad infinitum.
If the SFC lawsuit against Vizio succeeds, then there will be another option; since yourself and others are third-party beneficiaries of the contract embodied in the GPL between Linux kernel developers and hardware vendors that ship Linux; start a class action with other users of the hardware where GPL violations are present, and sue for GPL compliance instead of money. The lawyers will get their legal costs presumably and the users should get source code. Probably some law firms would take this on just for the legal costs, especially if the Vizio precedent makes it easy to win future cases.
https://sfconservancy.org/copyleft-compliance/vizio.html
PS: I don't think SFC have an endowment, they are just directly funded by people who support their goals.
It's very difficult to inspect a laid out chip for nefarious elements - there's too much of it to do manually. Having a secure supply chain is probably the best way to prevent that happening.
Which is not to say that I support this rule - it sounds like another import weapon trump can swing against people who aren't his friends.
Very few companies make the chips too. It'd be very easy for the government to force them to add backdoors.
Trusted, qualified independent experts: Ala Underwriters Laboratories.
Some trust has to be created through testing standards and the law, but generally we do believe what the label says in day to day life.
Detection of the car being on a rolling road, special button combos that trigger the emissions testing map, etc
I get the desire to not have to trust a third party, but realistically, there isn't a way to function without doing so, outside of going out and living in the forest in a cabin you've built yourself, either doing without electricity, or with solar panels you've built yourself from raw materials.
Human processes aren't like computers. They're messy. They fail sometimes. They need checks and balances. Sometimes those checks and balances don't work. Sometimes the checks only work well after the fact, and the people who were harmed aren't all made whole.
That's life. We probably can't do much better.
Maybe trusted community of people could do it for everyone, but there's currently all kinds of potential legal trouble brewing in that approach. Complete and public reverse engineering of every aspect of any device would have to be made completely legal, so that people could freely publish all artifacts extracted from a device and produced during reverse engineering and collaborate on them without any fear of repercussions. Also HW manufacturers would have to be prohibited from NDAing documentation for SoCs, etc.
Side benefit would be that this would also serve as a documentation for freeing the device and developing alternative firmwares with modernized sw/reduced attack surface.