Coffee Space 
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
This list is a description of interesting routes for further research:
[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.