Re: [Suit] Call for adoption on manifest draft

[Brendan Moran <[e-mail]>]

Hi Michael,

Thank you for all your feedback. I agree that some of the wording could be much clearer. I think I also should lay out the motivations for this change from declarative to procedural much better.

I believe that the behavioural (or procedural) approach has many benefits, but I want to stress that this is not about solving some arbitrarily complex problem; it’s about compact encoding, meeting the requirements we have, and enabling precisely defined device behaviour.


First, I have three observations about firmware update:

1. To eliminate a source of user error, simplify management, etc., we can’t have many similar formats, there needs to be just one.
2. Making a parser small and easy to validate requires a simple format, with few unique structures and low nesting depth.
3. Almost all user stories and security requirements are implemented with a small number of fundamental operations.

This makes behavioural manifests interesting. Because they are naturally shallow, repetitive encodings, they are simple to parse. Because the information contained in the manifest is very closely related to the operation the device must perform, they are simple to process. This should mean that we are able to achieve parser simplicity goals for a constrained device without sacrificing capabilities needed only on larger devices.


However, this simply makes behavioural manifests interesting, it doesn’t justify them for use in suit. For that, we need to look at the whole picture. A rough set of requirements for a manifest format in suit are:

1. Meets the information model requirements for usability and security
2. Simple to parse on a constrained node
3. Simple to process on a constrained node
4. Expressive enough to enable advanced use-cases on unconstrained(?) nodes, e.g. Linux.
5. Compact encoding
6. Extensible
7. Comprehensible by an intermediate system
8. Constructible by a moderately skilled user

I suspect that 1-6 are not up for debate and that 7, 8 are the contentious points. For 7, I think it’s important to look at the different systems we have in the constrained node use-case.

There are two classes of metadata used in firmware update, with two very different sets of constraints.
A. The metadata consumed by a constrained node in order to consume the firmware update.
B. The metadata used by an intermediate system to make decisions about the update

A) has to be small and easy to parse and process and B) has to be easy to reason about. In previous drafts, these have been the same. I now think this is detrimental to the constrained node. However, there are challenges posed by dividing metadata into consumer and intermediate metadata. I think we can resolve these issues in one of two ways: either by using tooling to extract relevant data from the “byte code” of the behavioural manifest, or by encoding two sets of metadata using severable sections, as previously discussed—this will be the default with encrypted or partially encrypted manifests anyway.

If the suit-wg chooses to pursue the behavioural manifest approach, I think we should focus on tooling to extract information. I don’t believe it’s complex to implement, and I’ll endeavour to prove that. However, there is certainly some value in being able to encode data for an intermediate system in a severable section. Since this has costs in manifest size, I think the best way to do this is to add a JSON blob as one possible element in the already severable text section.

To resolve 8, what we need is tooling that can construct a manifest to deliver one or more images, based on whatever capabilities are reported. We probably need to discuss what this looks like. A simple version would work by using templates for a set of standard use cases, but allow users to produce more advanced operations if needed.


However, I think there is one more consideration: implied behaviour. When a manifest is sent to a device, it is an instruction to do something. I think this makes procedural information a much better match. If the content of that manifest is purely declarative, then the behaviour of the device is implied. This means that the specification must make explicit what each information element implies a device should do. As long as each information element is isolated, this is achievable, but if information elements interact, this quickly leads to a combinatorial explosion in the specification. If the behaviour of the device for any arbitrary combination of information elements is not explicit in the specification, then the specification will be open to interpretation, which will inevitably yield surprising results. For a security-critical system, like firmware update, the last thing we want is surprising results.


I believe that the behavioural manifests are the best match for constrained nodes because they simplify the parser and the processor. They make the behaviour of the device explicit, rather than implicit. They are extensible without undue complexity on the target. They do present two challenges: interpretation on intermediate systems and construction by an unskilled (in behavioural manifests) user. I think that we can solve these challenges and I think that the interpretation challenge, at least, is less complex than it appears. I’m willing to trade complexity on intermediate/authoring systems for simplicity on a constrained node. What remains to be seen is whether the suit-wg agrees with my approach or not.

Best Regards,
Brendan

> On 19 Jun 2019, at 01:26, Michael Richardson <[e-mail]> wrote:
>
>
> Michael Richardson <[e-mail]> wrote:
>> Are the problems we are trying to solve so complex, varied and unknown
>> that we need this?
>
> The most complicated situation that I see is one where there are multiple
> firmwares images and they need to be upgraded in a particular order, or
> things stop working.  The Android case of KERNEL image vs RADIO/BASEBAND
> image is perhaps the simplest example of this.  (On some phones, you'll
> not just lose LTE if they are mis-matched, but maybe WIFI too, and often
> you'll get a kernel panic.)
>
> {At this point, I wandered through the document and then into the
> architecture document looking for the terminology for where a firmware image
> goes into.  The best I came up was that it was a component.  Above, in my
> android case, there were RADIO and KERNEL as slots for firmware}
>
> I can readily imagine Industrial applications where it could even take
> multiple passes:
>    1) upgrade component A to version 1.99 (which tolerates B being at 2.00)
>    2) upgrade component B to version 2.00
>    3) upgrade component A to version 2.00
>
> It should, I think be possible to express this process in a single master
> manifest (with dependancies, I think) rather than staging it somehow via an operator
> action.  It might be that each step takes mulitple hours to days to transfer
> the image, and the device needs to be operational the rest of the time
> (double-buffering).
>
> I think that the current document can accomplish the above rather simply, but
> it seems to go a lot further.  (To infinity... and beyond!... so good work!)
>
> I think that the directives tries to assume some kind of universal firmware
> updating system that is identical everywhere, rather than assuming a
> universal firmware package format, with firmware updaters in specific to each
> device.  Perhaps this comes from being a SoC vendor that is trying to support
> customers with a large variability in uses, but wanting to provide them all
> with an identical baked-in-internal-flash firmware system.
>
> I would be interested in David Brown's view on this.
>
> ps: I think it's only the directives which are the problem. I think the
> SUIT_Conditions are perfect, btw.
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> Suit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/suit

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.