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

From: Brendan Moran <[email-masked]>
Date: Tue, 12 Mar 2019 10:34:44 +0000

draft-moran-suit-manifest-04 has now been published.

https://tools.ietf.org/html/draft-moran-suit-manifest-04

This draft is the result of combining the information model in draft-moran-suit-behavioural-manifests-00 (the 01 version fixes example formatting only) with that in draft-ietf-suit-information-model, then serialising the result in CBOR. This is a significant departure from previous drafts. It attempts to preserve flexibility, fully define the behaviour of recipient, simplify the manifest structure, reduce code-size of the recipient, and reduce the size of the manifest. This ambitious set of goals required a significant change in approach as compared to draft-moran-suit-manifest-03 and before. In order to outline the approach clearly, we have separately published draft-moran-suit-behavioural-manifests-00. draft-moran-suit-manifest-04 focuses more on the serialisation of the manifest.

I look forward to discussing this draft in more detail.

Best Regards,
Brendan
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: David Brown <[email-masked]>
Date: Tue, 12 Mar 2019 17:38:34 -0600

>I look forward to discussing this draft in more detail.

So far, my initial impression is that this is a significant
improvement.  I will be spending some time changing my prototype
implementation to work as a manifest "executor" instead of something
that tries to extract data from the manifest to something that
evaluates the manifest.  In the process, I hope to produce some sample
manifests that show the current, as well as in-development multi-image
operations that happen within MCUboot.

One of the push-backs I got to SUIT on the MCUboot project was a
desire to maintain the same semantics between a SUIT manifest and the
existing simplistic manifests.  Unfortunately, that isn't really a
meaningful thing to do with this new manifest format.  However, I
think this new approach is enough of an improvement, that I may argue
to just move to the new SUIT semantics.

I'm sure I'll have more feedback as I work on an implementation.

David

---

From: David Brown <[email-masked]>
Date: Fri, 15 Mar 2019 10:34:02 -0600

>https://tools.ietf.org/html/draft-moran-suit-manifest-04

One point I wanted to bring up on-list was that this draft seems to
have a bit of a bias toward devices that execute programs by copying
them from flash to RAM and executing them out of RAM.

Given the class of devices that we are targeting, I would suggest that
this is actually fairly uncommon, and most of these types of devices
will generally be set up to execute directly out of flash, so called
XIP or eXecute In Place.  For these kinds of devices, the directives
in the draft are a little bit of a mismatch with how upgrades happen
on these kinds of devices.

To clarify, I will explain how upgrades currently work for devices
targeted by MCUboot (and by extension TF-M):

  - The flash is divided into a series of slots.  For a device with a
    single process and image, it will be something like:

    +------------+
    | bootloader |
    +------------+
    | Primary    |
    +------------+
    | Secondary  |
    +------------+
    | Scratch    |
    +------------+
    | Storage    |
    +------------+

    For a multi-CPU/image device, there will be a pair of primary and
    secondary slots.  To simplify, I will make this example just for a
    single-image device.

  - For normal execution, the bootloader validates the image in the
    "primary" slot, and if it is valid, jumps directly to its start
    address within flash.

  - The download part of an upgrade happens while the application is
    running, and this code is contained within the code currently
    running in the primary image.  It downloads the upgrade into the
    "secondary" slot.  This new code cannot execute at this address,
    but is placed here as the image is downloaded.  The assumption is
    that their isn't sufficient RAM to hold the entire image, and that
    a download may be interrupted.

  - Once the application has finished downloading the new image, it
    writes a special marker to the end of the "secondary" slot and
    causes a reboot.

  - The bootloader detects this upgrade request in the secondary slot
    and begins a series of steps:

    - Verify the image in the secondary slot.

    - Using the scratch area exchange the images in the primary and
      secondary slot

    - Verify the new primary slot.

    - Jump to the new primary image

    This is designed in such a way that it can resume after any
    untimely interruption.

  - If the new image boots successfully, it writes a marker at the end
    of the "primary" slot to indicate that the image is correct.
    Otherwise, if the bootloader boots without seeing this marker, it
    will exchange the primary and secondary images again to undo the
    upgrade.

Within either the primary or secondary slot, the image has a format
similar to:

    +------------+
    | Header     |
    +------------+
    | Executable |
    +------------+
    | Manifest   |
    +------------+

there is no real separate place to store the manifest.  This does mean
that during an upgrade the manifest for both the old and the new image
are present in flash.

I'm curious what thoughts people have on how to apply the draft 4
manifest to the above scenario.  Operations such as "load" aren't
really meaningful, but apply-image would certainly make sense.
However, the installation of a new image is partially initiated by a
different piece of code than the bootloader which is responsible for
actually installing the image.  This state has to be managed carefully
in a way that works with NOR flash, and therefore will probably live
outside of the manifest.

Thanks,
David

---

From: Martin Pagel <[email-masked]>
Date: Fri, 15 Mar 2019 23:24:19 +0000

David, 
I don't think that copying to RAM is mandatory or even recommended.
Example 1 should be all you need.
Martin

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of David Brown
Sent: Friday, March 15, 2019 9:34 AM
To: Brendan Moran <[email-masked]>
Cc: [email-masked]
Subject: Re: [Suit] Introducing draft-moran-suit-manifest-04

On Tue, Mar 12, 2019 at 10:34:44AM +0000, Brendan Moran wrote:
>https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools
>.ietf.org%2Fhtml%2Fdraft-moran-suit-manifest-04&amp;data=02%7C01%7Cmart
>in.pagel%40microsoft.com%7Ccfe120c246fd48faecff08d6a9641143%7C72f988bf8
>6f141af91ab2d7cd011db47%7C1%7C0%7C636882644594352532&amp;sdata=eWHvkKwY
>sXddzBMjbNpDlT9%2FQwshteFLmbU3bIiKwk4%3D&amp;reserved=0

One point I wanted to bring up on-list was that this draft seems to have a bit of a bias toward devices that execute programs by copying them from flash to RAM and executing them out of RAM.

Given the class of devices that we are targeting, I would suggest that this is actually fairly uncommon, and most of these types of devices will generally be set up to execute directly out of flash, so called XIP or eXecute In Place.  For these kinds of devices, the directives in the draft are a little bit of a mismatch with how upgrades happen on these kinds of devices.

To clarify, I will explain how upgrades currently work for devices targeted by MCUboot (and by extension TF-M):

    +------------+
    | bootloader |
    +------------+
    | Primary    |
    +------------+
    | Secondary  |
    +------------+
    | Scratch    |
    +------------+
    | Storage    |
    +------------+

Within either the primary or secondary slot, the image has a format similar to:

    +------------+
    | Header     |
    +------------+
    | Executable |
    +------------+
    | Manifest   |
    +------------+

there is no real separate place to store the manifest.  This does mean that during an upgrade the manifest for both the old and the new image are present in flash.

I'm curious what thoughts people have on how to apply the draft 4 manifest to the above scenario.  Operations such as "load" aren't really meaningful, but apply-image would certainly make sense.
However, the installation of a new image is partially initiated by a different piece of code than the bootloader which is responsible for actually installing the image.  This state has to be managed carefully in a way that works with NOR flash, and therefore will probably live outside of the manifest.

Thanks,
David

_______________________________________________
Suit mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ccfe120c246fd48faecff08d6a9641143%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636882644594352532&amp;sdata=271MhUpRnQbktJs5CgZfjLBYPbVkMXnPE80wSZL%2BrDY%3D&amp;reserved=0

---

From: David Brown <[email-masked]>
Date: Sun, 17 Mar 2019 00:27:35 -0600

>Example 1 should be all you need.

As far as booting, yes.  But, the "install image" instructions don't
seem to cover how images are typically installed on these systems.

David

---

From: Brendan Moran <[email-masked]>
Date: Thu, 21 Mar 2019 16:30:53 +0000

Hi David,
I believe that the current draft should be able to accommodate this use-case. A similar use-case was called out in the behavioural manifests draft that is referenced in draft-moran-suit-manifest-04: https://tools.ietf.org/html/draft-moran-suit-behavioural-manifest-01#page-20

The syntax is not identical to draft-moran-suit-manifest-04, since it was intended to describe the techniques, not the explicit encoding, but it should give an idea of how this would work. It may be that we are missing one command: swap. I’d be interested to hear if there is more desire to add “swap” as a solution to this problem.

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

Best Regards,
Brendan

> On 15 Mar 2019, at 16:34, David Brown <[email-masked]> wrote:
>

---

From: David Brown <[email-masked]>
Date: Fri, 22 Mar 2019 11:39:08 -0600

>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

---

From: David Brown <[email-masked]>
Date: Fri, 22 Mar 2019 11:44:39 -0600

In regards to encrypting images.  I wanted to explain a little how
this works in MCUboot.

The basic process is similar to the swap described in:
https://www.youtube.com/watch?v=TvXjw2l0Cd0

However, the image in the secondary slot is always encrypted, and the
image in the primary slot is always unencrypted.  This makes an
assumption that the primary slot is more difficult to access (usually
an internal device), and that the secondary slot lives in an external
device.

The manifest is not changed when the image is moved between the slots
(and decrypted/encrypted).  Right now this logic is hard-coded into
MCUboot.  It would certainly be possible to keep it hard-coded, and
have the manifest describe both the encrypted and unencrypted payload
that MCUboot would then just know which one to use.

Note also that the primary image is re-encrypted when the swap
happens.  It uses the same IV for the encryption, which bothers me,
since it makes it slightly vulnerable to the plaintext being modified
(although if the plain text can be modified, many other attacks are
possible).

Any other thoughts on how to handle this?  BTW, this is not really
talking about encrypted payloads that are downloaded and decrypted
before being written to flash.  This is where there are two images in
flash, the executable one being unencrypted.

---

From: Cody Addison <[email-masked]>
Date: Mon, 25 Mar 2019 21:06:52 -0500

David, Brendan,

> ok" marker, but having two instructions could distinguish this as

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:

> https://www.ietf.org/mailman/listinfo/suit