Re: [Fud] [dev-mcuboot] IoT firmware update standardization efforts @ IETF

[David Brown <[e-mail]>]

On Fri, Sep 22, 2017 at 10:01:18AM +0200, Emmanuel Baccelli wrote:
>Dear MCUbooters
>
>I wanted to bring your attention to an effort starting at IETF to standardize
>some aspects fo firmware updates.
>
>I think it would be useful if some MCUboot/Zephyr/MyNewt could participate.
>
>The working group about to be created is called FUD [1].
>There are a couple of initial drafts [2] and a mailing list [3] through which
>discussion happens, as usual for such efforts.
>
>FYI the next f2f meeting will be at IETF 100 [4].

Thanks for the information.  I have joined the fud mailing list, and
intend to become involved.

I work on MCUboot as well as on the Zephyr project.  MCUboot address a
small part of the firmware update process, namely performing the
atomic operation of the actual final firmware upgrade.  It also
supports additional features such as revert when an image is
determined to be nonfunctional.

MCUboot original came from the Mynewt project, and is a part of their
update solution.  The Zephyr project has not defined firmware update
beyond porting MCUboot to Zephyr.  As such, what is being discussed at
FUD is very applicable.

I'd also like to give a very short overview of MCUboot, since its
existing image formats may need to change to accomodate a CMS
formatted firmware package.

The primary design constraint behind MCUboot's image format is the
support for execute in place (XIP) MCU devices.  Typically, these
devices begin executing from an address at a vector near the beginning
of flash.  MCUboot is itself installed at the beginning of flash, and
expects both the runnable image and the upgrade image to occupy
partitions following this.

The runnable application is modified from a standalone MCU application
in several ways:

  - It is linked at an address for the runnable partition (referred to
    as Slot 0 in the MCUboot design documentation).

  - There is a small header at the beginning, with flags, a header
    size field, and an image size field.  This can be used to compute
    the address of the end of the image.

  - After the image is a simple TLV-formatted encoding of a signature
    over the header and the image.

In order to support a CMS formatted firmware image, MCUboot will need
to take one of several approaches.

  - The firmware package will be unwrapped outside of the context of
    the bootloader.  The content of the CMS payload would have the
    header and TLV signature already on it.  This would require no
    modification to MCUboot, but may be difficult to implement in a
    RAM-constrained device that does not have sufficient RAM to hold
    the entire firmware package.

  - MCUboot could be modified to unpack the firmware package from the
    upgrade partition when copying it to the runnable partition.  This
    would add complexity, as well as make MCUboot's current rollback
    mechanisms more complex.

  - The content inside of the firmware package could be designed to be
    executable directly out of the firmware package.  With DER
    encoding, this will be somewhat complicated, as the length of the
    preceding data in the firmware package contains encoded values
    that depend on the length of the firmware package itself.  There
    are possible implementations, such as repeating the link and
    package operation until a fixed point is reached.

I hope to be able to bring useful feedback based on our experience
with MCUboot and performing updates of this class of devices.

Thanks,
David Brown