Subject: [Fud] documents and minutes

From: Michael Richardson <[email-masked]>
Date: Sun, 16 Apr 2017 13:07:18 -0400

1) I don't think this list got the initial welcome message with pointers to
   the various drafts from Hannes that form some of the basis for his problem
   statement.
   Could the links be posted for the benefit of the archives?
   I searched the ID repo using: 'fud' and also 'tschofenig', but didn't find
   anything. I thought that were some documents.

2) Carsten wrote these minutes:

> — firmware updates for general purpose class computers (Linux etc.,
> “A-class”, OpenWRT routers, ...) are rather different from those for
> microcontrollers (“M-class”)
..
> — initial focus on complete firmware replacement (we did talk about
> bootloaders vs. primary/recovery loaders etc.)

I wanted to take issue with the way this distinction is being presented.
While there are plenty of Linux based systems that do updates via packages,
and systems like OpenWRT/LEDE and Android that can load some optional
components via packages (opkg and apk), many of these systems do their
primary upgrades via complete firmware replacements.

It's not about "M-class" vs "A-class" (some very ARM specific terminology), at all.

The only difference between an RPI-IoT device running Android and an ATmega
running Ardiuno or Freescale or OpenMote device running Contiki is the number
of megabytes the image is.  The large image devices actually have more of a
challenge because they usually can not double-buffer the image, so they have
more in common with the very small devices, with the "M-class" device
actually being richer than then the smaller devices.

The saving grace is that usually have a generous amount of space for a
recover/bootloader image so that failure to apply an image does not result in
a bricked device.

{I will note that most of the baby-monitor/video cameras which were involved
in the DDoS, while they might use a Linux kernel, usually have only one or
two core processes that do all the work.  They are upgraded by complete
firmware replacement, and usually do not support packages in any form.}

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Apr 2017 14:24:45 -0700

> It's not about "M-class" vs "A-class" (some very ARM specific terminology), at all.

Agreed.

> actually being richer than then the smaller devices.

I think there is a distinction between devices which have an MMU (memory 
management unit) vs. not which can have some impact on software update.
A device with an MMU can more easily put together different pieces of 
software using virtual memory.
A device without an MMU either has to replace the whole firmware, or do 
additional work should one upgraded piece grow in size. (I the bar the 
observation was that one can use position independent code and move some 
code around to make room, or leave dead space in the image to allow for 
some growth.)

It would be nice to have an image format which could allow for those 
differences when allowing for updating only the pieces which change from 
one version to another.

    Erik