Subject: [Fud] Constrained Firmware update challenge

From: Michael Richardson <[email-masked]>
Date: Sun, 16 Apr 2017 16:34:28 -0400

In the BarBOF I tried to explain my belief that there is a place for in-place
(not double/triple buffered) firmware update, via some kind of setup-process
followed by a very constrained CoAP/DTLS/OSCOAP Block Transfer mechanism that
a recovery bootloader could run.  I imagine pretty much *all* the protocol
mechanism being cached.. (ND, IPv6 addresses, DTLS setup, etc.)

So I wrote up my challenge, and my straw-man concept of a solution.

Please disagree with me... preferably by sending text (or pull requests):
     https://datatracker.ietf.org/doc/draft-richardson-fud-constrained-update/
     https://github.com/mcr/fud-constrained-update

Ignore my strawman, or perhaps, provide your own.

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 17 Apr 2017 09:36:02 +0200

How do you update that bootloader (which now contains the majority of the code on the device, by the way)?

Grüße, Carsten

> On Apr 16, 2017, at 22:34, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> Fud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fud

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Apr 2017 11:26:21 -0400

> the code on the device, by the way)?

I think that it may be possible to significantly simply that code path
such that it does not have so much code.  Updates may be impossible
(burnt into ROM), or it might just be a special part of the flash that
is seperate from the main code.

Things I would expect to leave out would include:
       - L2 neighbour cache and L3 routing
       - fragment creation (just re-assembly)
       - neighbor discovery
       - RPL
       - DTLS and/or OSCOAP setup.
       - authorization: public key handling, certs if used, ACE tokens, DH
       - interrupts (everything polled I/O)

This is part of my postulate, and perhaps you will reasonably disagree with
the assumption that this can be done.  I believe that the code would be
seperate from the normal code.   Done wrong it could contain the majority
of the code, but done well, I think it would be perhaps 20%.

Effectively, we no longer double buffer the entire system, just the totally
minimal code required to load new code.  It could alternatively be that the
bootloader code is used as a kind of "BIOS" via subroutines.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 17 Apr 2017 19:01:41 +0200

> On Apr 17, 2017, at 17:26, Michael Richardson <[email-masked]> wrote:
> 
> Updates may be impossible
> (burnt into ROM),

Too much code for my taste (and much of this is security relevant, so it probably needs updates at some point).

> or it might just be a special part of the flash that

More likely, and more likely that you’d keep two copies of that, so you can upgrade the bootloader itself.
(Needs jump tables if that massive amount of code also needs to be reused by the application.)

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Apr 2017 13:36:24 -0400

Carsten Bormann <[email-masked]> wrote:
    >> Updates may be impossible (burnt into ROM),

    > Too much code for my taste (and much of this is security relevant, so
    > it probably needs updates at some point).

I agree it's better if we can update it.
I'm just looking at what resources might be under-exploited.

    >> or it might just be a special part of the flash that is seperate from
    >> the main code.

    > More likely, and more likely that you’d keep two copies of that, so you
    > can upgrade the bootloader itself.  (Needs jump tables if that massive
    > amount of code also needs to be reused by the application.)

Yes, agreed.

The question is: do you agree with the postulates
  1) that product managers will paint themselves into corners where they can
     not double-buffer.
  2) that there is any role for the IETF.

[I come to this problem first hand... having to drag my laptop out to JTAG
a Redwire econotag.  No space for double buffering, but at least 30K of code
space still free... No I didn't solve the problem, I have no proof of concept
yet.

Or to make the point differently: not having space for double buffering, I
can not even consider any kind of online firmware update]