Coffee Space


Linux for IoT

Preview Image

Here is the project page for looking at creating Linux suitable for the task of IoT tasks. The sections have been broken down to represent the various areas needed to reach a solution, or at least a conclusion. This will take time and this page may change over time.



There were two articles that have motivated this work, the first is an article explaining that the DDoS on OVH at an incredible 1Tb/s was the result of more than 150,000 IoT devices working together to deliver an effective attack [1].

The next article is one that shows that the Linux security community is in complete disarray as to how to protect these devices from being hacked [2]. It’s all good and well creating the largest connected network in all of human history, but not protecting said network will inevitably lead to bad things - as already shown.

Problem Description

The following is a discussion on the various aspects that make the problem difficult and therefore set the goals in which we need to achieve.


The following are considered to be the assumptions we have of an IoT device:

  1. The hardware will be the minimum of what is required in order to achieve the advertised task of the device.
  2. All devices eventually reach a point where it is no longer financially viable (or viable in general) to continue updating firmware. For some devices this may be instantaneous from product release for a multitude of reasons.
  3. The use of the devices may be unpredictable and producers of IoT devices will not want to reduce their customer base.
  4. A majority of IoT devices are owned by non-technical users.
  5. IoT devices could in theory be in use until their eventual demise or lack of relevance.
  6. All IoT devices of the same type are hackable in the same way.
  7. Devices use Linux or some variant of.


1. Minimum Hardware

So far there has been a trend that the minimum hardware is used for each IoT device, as reducing hardware ultimately reduces costs, therefore increasing profits. This is a trend that we can not expect to change where the profit margin is already extremely low. That said, each company with more expensive internet connected devices have a vested interest to stop updates after a period of time, forcing customers to buy newer products. Of course, this is not always the case, with customers using hardware many years after any security support is offered for it.

2. Software Updates

Updating software past the point of profitability is generally not good for business as software engineering time is spent updating a product that no longer generates profit. Even using a standard Linux setup, there’s no guarantees that can be made to make sure that a security patch doesn’t break the current product - therefore meaning that automating the updates cannot be done without at least testing and potentially fixing breaks.

All IoT devices eventually end up no longer being supported and updated for security, regardless of the representation of the company that produces it. There’s currently no legal reason to offer any support beyond what is sold to the customer for any software project and such a legal concept would have to span several disagreeing Countries.

3. Undefined Use

Another complexity to a generic solution to this problem is products may be rightfully used outside of their designed parameters - in fact there may even be a considerable market for this kind of use. If you create an “smart light” for example, somebody could harmlessly set this device up so the lights turn on or off at certain times in a house for example. These are not the sorts of customers that should be punished for the sake of those who choose to exploit these devices.

4. Boundary for Maintenance

Asking a user to SSH into their IoT device and run an update will be well beyond the capability of many “plug and play” users who may not even be aware that such a problem exists. Besides, customers may even purchasing these devices for the lack of what they have to do in order to make them operational. For a company designing these devices, for them to ask their users to do extra steps may be a make or break deal for them. If technical depth can change what libraries programmers use, you bet their customers will be put off by a harder to use device.

5. Device Lifetime

We have to assume at least some of these devices will be used well in exception of their expected use date. Some of IoT devices may sit in some warehouse for a considerable amount of time before being shipped to it’s end customer, so having an end date on these devices is not practical. There are stories of some of these early IoT devices running unprotected for many years past what could be considered safe.

6. Regularity of Devices

If you many similar devices and somebody finds an exploit for one, chances are this exploit will be usable for many more. It’s a fair assumption that all IoT devices of the same model will be exploitable in exactly the same way. You only need one weak link in a long chain of weak links to cause large trouble.

7. Linux on Devices

Many of these devices use some variant of Linux, from some ultra-small embedded kernel with just enough drivers to operate - all the way to a fully fledged Linux operating system. In an attempt to reduce cost, producers of IoT devices will use both free software/libraries and will look to keep their programming effort to a minimum, meaning less programming hours paid for.

Overall Problem

The overall problem is that despite best (or sometimes sub-best) human efforts, IoT devices are released into the wild that are later found to be susceptible to attacks, both leaving the users of those devices unprotected and sometimes those not involved in any capacity, vulnerable in a multitude of ways.


Directions of Research

This list is a description of interesting routes for further research:

  1. Will the reduction of cost of hardware lead to IoT devices with surplus computation power?
  2. Why is it not financially viable to keep producing updates for IoT devices? Is there some way to work with this problem?
  3. Is there an easy way in which to have a normal user mode and an advanced user mode, where the latter is less secure but more adaptable without locking out customers?
  4. Why is there such a large requirement of knowledge to perform administration on IoT devices?
  5. Could a solution be to purposefully expire IoT devices based on some variable?
  6. How can uniqueness be introduced into the software in order to increase device security?
  7. Is a variant of Linux the most secure device for the purpose of IoT?


[1] Paganini, P. “150,000 IoT Devices behind the 1Tbps DDoS attack on OVH”, Security Affairs, website, 2016.

[2] Porup, J. “Unsafe at any clock speed: Linux kernel security needs a rethink”, Ars Technica, website, 2016.