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

David, Brendan,

> 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.

Was there ever a consensus on how to represent this operation in the manifest? The copy instruction seems like the appropriate instruction to use in the install phase, but I'm not sure what component identifier to use for the source. My working assumption has been that a tool will create a single file which contains the manifest and payload data. Take a simple example of a dual core MCU:

+--------------+
+ Manifest +
+--------------+
+ FW1        +
+--------------+
+ FW2        +
+--------------+

That file would then be streamed to the device and installed either on the fly or in separate download and install stages where the download includes the manifest and payloads. In more complicated scenarios there may be multiple payloads that are optionally fetched. I see how to use the SUIT_Condition element to control which payloads get installed, but not how to reference payloads within the file. Maybe my working model is incorrect and this is not how the manifest is intended to be used?

David Brown writes:

> 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
>
> _______________________________________________
> Suit mailing list
> Suit@ietf.org
> https://www.ietf.org/mailman/listinfo/suit