On Tue, Oct 14, 2014 at 4:44 PM, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote:
On Tue, Oct 14, 2014 at 3:57 PM, Jim Gettys <jg@xxxxxxxxxxxxxxx> wrote:
>
> There is a serious issue lurking here: it is *not* safe for devices to be
> without software updates. And it isn't safe to presume the upstream
> manufacturer is being diligent in providing those updates. And nagging end
> users to do something that they don't understand is also not a solution.
I think we need to divide divide devices into 'simple enough to not
need updates' and 'make use of a standard update process'.
There are few network connected devices "simple enough to not need updates", IMHO. Distinguishing those that do from those that don't is just about impossible.
Courtesy of Moore's law, even "simple" devices are often/usually based on millions of lines of code.
My car has 30 computers in it (and a newer model would likely have
60). There is one on every wheel counting the rotations for the ABS
system. Do I really want them all to be updatable?
I think those devices just emit signals, and we don't "talk" to them. I can see sensors just being "output only" devices (though that creates a different problem: network pollution.
In general I only want devices to have an update capability if they 1)
have sufficient CPU power to authenticate the replacement code and 2)
have enough memory to hold the old and new code in memory while the
new code is being verified.
Yup; there are some minimum hardware requirements. One of the key enablers sadly missing
at today is write protection on the flash. What we did at OLPC is quite cheap (one D flop + separate serial ROM for boot, cost of < $.30); potential cost is zero, if we can get flash vendors to put the right hooks into the flash (and if we can trust that flash to work properly, which given recent experiences seems possibly questionable).
Jim