A recent thread started by Brian Smith on the OpenWrt-Devel mailing list caught my attention. Along with a corresponding wiki entry, it highlighted some important security topics related to OpenWrt. I don’t know if I’ve ever seen such a succinct and clear organization of security topics for OpenWrt development. While each of these topics is valuable and deserves exploration, one area of particular interest is automatically updating OpenWrt devices.
Before we getting into why this is difficult, let’s discuss why autoupdating would be desirable. All network connected software of some complexity will have occasional security bugs. Therefore maintaining a high level of security requires regular security updates. In order to make the lives of users easier, most modern operating system distributions, both proprietary and open source, provide a mechanism for automatically updating the operating system. Every so often, a piece of software on the device will check a trusted server to see if updates are available and, if they are, will download and install the update with minimal input from the user. While the update mechanism should be under the under the full control of the user, a default of auto updating is appropriate for many users.
As the most used Linux distribution for routers, one would expect OpenWrt to have its own autoupdate mechanism. After all, all major Linux distributions have an autoupdate functionality. Yet, OpenWrt does not have one built-in. Why is that the case?
The major hindrance for an autoupdating OpenWrt is the sheer number of platforms that OpenWrt runs on. In the case of a primarily desktop platform like Ubuntu, there’s only a few platforms to support (x86, x64). A quick count reveals there are thirty-eight targets in a recent OpenWrt version. Each of these targets does not necessarily correspond to a single output image and package set. Instead, most targets have unique profiles and subtargets. Each combination of profile and subtarget potentially corresponds to a unique output image and package set (some of the packages may be reusable across subtargets and profiles). Total number of combinations at this point is in the hundreds. The OpenWrt project does not build all of those combinations nightly or even for every major release. Even for packages and images which are built, testing is rather limited since testing requires access to a physical piece of hardware. While prpl is prototyping a system for remotely accessible testing hardware (which I’ll cover in another post soon), this is a limited workaround for testing a small number of routers. Given all of the difficulties, OpenWrt does a superb job at creating a stable secure distribution. It’s simply the case though that autoupdating the community version of OpenWrt would only be feasible on a few high-profile devices while the vast majority of devices would be left out in the cold.
Does this mean we should scrap the idea of automatic updates on OpenWrt? Well, not exactly. Remember that the OpenWrt images provided by the project, which we’ll call upstream OpenWrt, are not the only versions OpenWrt of used on devices. Many manufacturers and service providers use OpenWrt as the base of their embedded device firmware. These groups often have a limited set of models to support. By shrinking the list of devices, groups can feasibly create and manage OpenWrt autoupdates. In fact, some manufacturers and firmware distributors for OpenWrt have their own autoupdate tools:
- Freifunk has a remote-update tool in the LuCI repository. While not technically set up for automatic updates, it could be with a cron job.
- The Turris project from CZ.NIC has their own autoupdate tool.
Given the growth of OpenWrt and the explosion of embedded devices, more companies and firmware manufacturers will need autoupdate tools for OpenWrt. This begs the question: Is there common ground between all these needs? I would argue that there is and, to that end, OpenWrt and prpl communities should collaborate in the creation of a community developed and maintained autoupdate mechanism. In keeping with the spirit of OpenWrt, this tool should be flexible enough to meet a broad range of needs while being simple enough to maintain and understand.
We’ve begun initial discussions about this project on the prplwrt mailing list. As part of this effort, we need help understanding the needs (and wants) of manufacturers, service providers, community firmware creators, users, really anyone with an interest in the topic of automatically updating OpenWrt devices. Also, if you have, or know of, open source tools for automatically updating OpenWrt device, please share them!
How to participate
As always, we welcome everyone’s participation in this effort. You can get involved in a few ways:
- Comment on this blog post
- Participate on the prplwrt email list
- Tell others about this effort