Some of my thoughs on OpenWRT: Optional Automated security patcher

So I realize that there is not a proper way to automatically update OpenWRT which makes sense as there are a lot of breaking changes. However, it might make sense for some devices to automatically apply a new image that only includes security fixes and does not have drastic breaking changes. I was looking at the OpenWRT page on endoflife.date and it shows that there is only one support version. That makes sense but I think it would be fairly feasible to backport security fixes to the previous release since many devices tend to be set and forget which is fairly bad as it could lead to a botnet in the case of a very serious CVE.

From a auto updater perspective there would need to be several things in place. First off there should be an A and a B partition which is the case for most devices. Secondly, there would need to be a series of checks. The first check would be a successful boot but ideally there should be a connectivity check and functionality check. This would be tricky to do as there are tons of different configurations.

This post is mostly just a dumping ground for some thoughts I had.

See - https://openwrt.org/docs/guide-user/installation/attended.sysupgrade

Fixes are backported for supported versions.

Some devices have an A and B partition.

1 Like

Can you cite the "breaking changes" ?

1 Like

This Reddit comment. It could totally be wrong.

I wonder if you could do live patching on boot? That would keep you from having to flash a new image. It wouldn't work for large changes but if a small tweak is needed it might work assuming the live patch doesn't go wrong which is definitely not a guarantee. I am just fiddling around for the most part so this is not something to be taken to seriously.

Thanks for the info. I did not know that service existed. I guess that is what I get for overthinking it.

Can you describe what you mean by this?

OpenWrt will flash an entire image during the upgrade process - the system is rebooted during this time.

Kernel patching for for kernel CVEs.

For other userspace components you could create a filesystem overlay that applies on boot from the config partition. This would help prevent flash wear on devices with limited writes. It also might work to patch devices without a full reboot.

The entire image must be built/flashed on OpenWrt to replace the kernel.

  • But you'd loose space since it's not actually "erased" but marked as deleted in the filesystem
  • Not sure how that'll work for the kernel in this case

Are you sure? The Linux kernel has live patching support although I am not sure about its reliability. If you are talking about the OpenWRT kernel config specifically I do not know much as I am fairly new at this.

Keep in mind - OpenWrt is not a normal distro with a normal filesystem.

No worries.

I am aware of that. It would be fine with devices that have plenty of disk space but wouldn't work on small limited devices. Also the changes would need to be very small such as swapping out a single binary. It wouldn't be a long term solution but it could work.

You can't swap a "single binary" [safely] from a complied image containing it.

Just sysupgrade or AUC, then you're ensured to have compatible - kernel, kmods, packages, etc.

That's the kicker isn't it. Embedded systems are hard to work on.

If OpenWRT was that critical it would make sense to have a redundant system to fall back on. (i.e. 2 internet connections)

Not really. It just seems you're embracing the paradigm of a "disk-based OS" and not one with a complied image that's flashed.

Live kernel patching is not as trivial as to enable kernel build option. It needs the systemtap or kmod loaded that replaces in-memory functions, and all of them need more and more storage and memory space.

2 Likes

Your assumption is wrong, doing that is hard work - increasingly so the further you want to go back. But no one would stop you, if you tried (try it just once, for a single issue - with a targeted minimally invasive patch, and see for yourself).

Indeed, that's bad, but the availability of minor release updates for obsolete branches wouldn't change that either. The users needs to keep track of their systems, there is no magic wand keeping them updated on their behalf and without their explicit knowledge (that would be scary and very much unwanted).

While that may often be the case for newer NAND based devices, it's certainly not the case for the majority of devices (many of which are being older and very short on flash/ RAM and often plagued with weird bootloader constraints).

Cool, will you buy the 700+ devices needed for constant checks? Provide the data centre, power and remote power/ serial/ management and the developers actually keeping track of the regressions? Sounds easy, until you realize that it isn't - and be it 'just' because none of the developers has the device(s) you care about (support for many devices is provided by its users, often as drive-by submissions) - and even those may have moved on to different hardware after a year or two.

Try to put them at least to a casual test before posting them, just because they sound cool and enterprise'ish doesn't mean they're remotely realistic. And no, some random reddit comments or chatgpt output doesn't count.

Apologies if this sounds a tad negative, but ideas are a dime a dozen - actual implementations take serious work, unless you have an actual plan to realize them (and are at least 60% there, proof of concept stage for at least two different targets), they're just pipe dreams and will remain wishful thinking. Embedded devices are different, you can't ignore their intrinsic limitations - nor can you wish away the silent majority of legacy devices and even most high-end modern devices won't bow to your wishes here.

2 Likes

yeah, especially when there is almost no free memory

I think you misunderstood. This is purely a brain dump. I have no intention of pleasing anyone and I figured it would be a fun exercise to think about.

Thanks for your thoughts though

1 Like