undefined | Better HN

0 pointsmindslight2mo ago0 comments

I'm no fan of imaginary property, but you're going to have to lay out your reasoning here. Firmware security is such crap precisely because most hardware manufacturers see it as nothing but a cost center they wish they could avoid.

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.

0 comments

M95D2mo ago

> not having straightforward APIs like BIOS/EFI.

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.

mindslightOP2mo ago

> Oh, no, not this again!

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

M95D1mo ago

> 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

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.

j / k navigate · click thread line to collapse