Re: [Suit] [suit]: draft-moran-suit-manifest-02

[David Brown <[e-mail]>]

On Tue, Jul 03, 2018 at 09:08:02PM +0000, Brendan Moran wrote:

>This draft is a significant departure from previous drafts, so I think it is
>important to highlight the changes. The draft requires a lot of text that
>hasn’t been written yet, so I will try to put some of that here for discussion.
>
>[1]https://datatracker.ietf.org/doc/draft-moran-suit-manifest/

Yesterday, I spent some time going through this draft to try and
create an example manifest based on how MCUboot currently behaves.  I
found many things that I wasn't clear on the meaning of, and wasn't
quite certain how to structure the manifest for my, what I believe, is
a fairly simple case.

In addition, I feel there is an assumption in the manifest that the
processing will be done in two parts:

   1. Parse the CBOR into some kind of in-memory data structure.
   2. Traverse this structure in various ways, making decisions and
      performing processing.

This is a lot to ask of code on a resource-constrained device, where
we likely are going to only have tens of kB of code space available.
I would like to consider making the manifest in such a manner that it
is possible to construct at least a simple version that can be
processed linearly (in CBOR order).

## What MCUboot does

Targets using MCUboot currently use a manifest format that is combined
directly with the image.  It is formatted something like:

         -----------------------
         | Header
         |   ...
         |   Image length
         |   ...
         -----------------------
         | Padding
         -----------------------
         | Execute in place
         |   firmware image
         | ...
         -----------------------
         | Manifest header
         -----------------------
         | TLV encoded manifest
         +----------------------

The flash memory is divided as follows:

         +-------------------------
         | Bootloader
         +-------------------------
         | Slot 0
         |    XIP Application Code
         +-------------------------
         | Slot 1
         |    Update image
         +-------------------------
         | Scratch
         +-------------------------

The two actors involve that are running on the MCU are: 1. The update
application, and 2. MCUboot itself.

The update application is code combined with the normal application
running on the target.  It is responsible for downloading this image,
possibly verifying it, and writing it into flash in Slot 1.  This code
is part of the image running in slot 0.  Once this is written, it
reboots.

MCUboot, upon boot, checks slot 1 for a manifest, and if there is a
valid update present, performs either a "swap", exchanging the data in
slot 0 and slot 1 (using scratch to be robust against power loss), or
overwrites slot 1 onto slot 0 (depends on how it is configured).  It
then verifies the image in slot 0, and if valid transfers control into
the XIP image in slot 0.

The TLV manifest is currently quite simple, an essentialy consists of
a series of steps that MCUboot walks through.  These steps can consist
of:

    - Compute a hash of the image and compare with XXXXX
    - Verify a signature of the hash using a built-in public key.

There can be multiple signatures, generally to support either multiple
algorithms, or to support multiple signers.  When it completes the
processing, it checks that it did indeed verify a hash, and at least
one signature, at which point it will boot.

## Encoding this in a SUIT manifest.

My initial assumption was that we could place the SUIT manifest in the
above images where the current Manifest header and TLV manifest live.
It would not be difficult to distinguish between a COSE_Sign block and
the existing header, although it is unlikely that the code could be
compiled to include processing for both formats.

I envision the processing something along the lines of:

   1.  MCUboot decodes the COSE_Sign data.  Although COSE seems to
   also assume that it will be decoded into RAM and processed there,
   it isn't too difficult to simply record decoded offsets, and
   construct the Sig_structure virtually, invoking the hash algorithm
   incrementally.  My initial guess is that the code to process this
   would take perhaps 2-3 times as much code to process as the current
   TLV processing.  The result will be a pointer and length to the
   payload, which is the SUIT manifest.

   2.  MCUboot then decodes the SUIT manifest.  The goal is for it to
   determine: 1. Does this manifest describe the attached image, 2. Is
   the manifest applicable, and 3.  Should it do an image swap (for
   example if the newer image is in slot 1).

In light of this, I tried to come up with a sample manifest, but it
wasn't clear to me where and what things should be conveyed in it.
Keep in mind that ideally, the manifest could be processed in a single
pass, possibly with a small amount of RAM used to point back to key
information gained.  I came up with the following:

   - The preconditions would be one or more IdConditions to associated
     the image with a particular device.  This adds functionality to
     what MCUboot currently does.

   - Possibly a 'dependency' resource (functionality needed for future
     multiple image work).

   - A payload resource that describes the payload this manifest is
     attached to.

Perhaps this is sufficient for this use case.  Given that I don't
understand what the 'inode' and 'onode' fields represent, I'm not sure
how processors and targets would be configured to describe this.
Maybe they are intended for a more complex use case.  I will send
another email about my confusion in this regard.

Given the above, in the manifest, the 'digestInfo', 'textReference',
'nonce', and 'sequence' would have meaningful values.  There would
probably be some 'preConditions', and 'resources', but the rest of the
arrays would be blank.  Does my interpretation seem reasonable? Or
would it also be expected that the processing and/or directives be
involved in this case.

For our use case, the two actors perform different steps, and it may
not even be meaningful to encode that information in the manifest.  If
we do want to encode the steps to perform, something would need to be
added to indicate which actor is supposed to perform which steps.

David