Re: [Suit] Introducing draft-moran-suit-manifest-04

[David Brown <[e-mail]>]

On Thu, Mar 21, 2019 at 04:30:53PM +0000, Brendan Moran wrote:

>Reboot resilience for “swap” is probably outside the scope of this draft.
>Adding a condition to check the success marker might be useful.

I'm not sure it really even makes sense to describe the reboot
resilience in the manifest.  At least for swap, it is a large number
of steps that have to be done carefully, along with a lot of extra
state that is written every step.  I would think this intermediate
state is beyond the scape of the manifest.

For those interested, I've thrown together a bit of an amination
describing how the swap operation works in MCUboot, including at least
part of its state.

   https://www.youtube.com/watch?v=TvXjw2l0Cd0

I'm not actually sure it is even going to make very much sense for
MCUboot to follow steps in the manifest, rather than just verifying
that they are present.  The steps make sense for the download
application.

Some of the modes I envision ultimately supporting in MCUboot:

  - swap: The current mode.  This is initiated by a "trailer" being
    written to the secondary image, and the bootloader verifying that
    the manifest is correct.  It might make sense for it to follow the
    "swap" instruction, but it would only look at this secondary
    manifest after being instructed to, out of band.

  - overwrite: The other current possible mode.  Also initialized by
    the "trailer" being written at the end of the second image, and
    the bootloader verifying that the manifest is correct.  The second
    image is copied to the primary image slot.  This is easier to make
    resilient, since the entire operation can be restarted.

  - Boot best: not implemented.  The upgrade would download an image
    in the slot that is not being used.  There would be two images
    built, one linked to each slot.

Right now, upon boot, MCUboot checks the manifest of the primary slot,
and will boot that image if it is valid.  Before this, it will check
the trailer of the second slot to see if an upgrade is requested, and
if so, check that manifest, and possibly swap/overwrite depending on
how it is built.

One difficulty I see following steps in the manifest is that the code
currently maintains state out-of-band from the manifest.  The current
state is:

  - copy done: indicates that a copy/swap has finished and the primary
    image can be checked (avoids having to check the secondary
    partition manifest on every boot).

  - image ok: after a new image boots, and decides it is functional,
    it writes this marker.  Without this marker being written, a
    subsequent reboot will cause the swap operation to be repeated to
    revert the image.

  - swap state: a series of markers to track the state of a swap, so
    that it can be resumed if necessary.

Any thoughts on what is appropriate to even represent in the manifest?
The two instructions that the bootloader would follow would be "swap"
or "apply" (depending on configuration), and "run".  Right now, we
distinguish swap vs copy by whether the new image contains the "image
ok" marker, but having two instructions could distinguish this as
well.

There is some concern within the MCUboot community about semantic
differences between how the existing manifest is processed and how
SUIT will be processed.

Thanks,
David