Subject: Re: [Suit] Devices with multiple updatable elements

From: Brendan Moran <[email-masked]>
Date: Wed, 7 Nov 2018 14:33:01 +0000

Hi Amyas,
Please see my responses inline.

Best Regards,
Brendan

> On 31 Oct 2018, at 09:20, Amyas Phillips <[email-masked]> wrote:
>
> Hi All
>
> I want to suggest modifications to draft-ietf-suit-information-model-01, sections:
>
> 3.3.1.  Security Requirement MFSR1: Monotonic Sequence Numbers
> 4.10.  Manifest Element: Storage Location , and
> 4.11. Manifest Element: Component Identifier
>
> Here are the current texts, to save you looking them up:
>
>
>
> Several examples are given in the documents of scenarios in which a single device has multiple updatable elements.  draft-moran-suit-architecture discusses devices with multiple processors, and a device with an external updatable radio. draft-ietf-suit-information-model-01 in section 3.5.3.  Usability Requirement MFUR3 discusses scenarios where peripheral devices need updating, and firmware modules are independently updatable.  In section 4.10.1.  Example 1: Two Storage Locations, the specific scenario of separately-maintained OS and APP is introduced.  Other scenarios spring to mind, such as bootloaders and recovery images.
>
> Section 3.3.1 in draft-ietf-suit-information-model-01 introduces the idea that multiple uncoordinated actors may be creating manifests for the same device. This might happen if they are maintainers of firmware for different parts of the device's system.
>
> To prevent one actor's update of element A invalidating another's update of element B, unnecessarily and quite likely unpredictably, I propose that the requirement in section 3.3.1 for the manifest sequence number to increase monotonically be scoped to each updatable element.
>

This was always the intent, but I don’t think it’s detailed explicitly. That is a good clarification to include in the next draft. There is more to this, however. There is rarely a component dependency graph that has a completely disconnected sub-graph. This means that there must be some method to ensure compatibility between separately-maintained components. Clearly, this cannot be a manifest dependency, since the components must be independently updatable. Perhaps a precondition that uses version numbers is the right answer, but that could introduce a requirement for coordinated changes between those separately-maintained components. This begins to stray into the domain of package managers.

>
> This is where I ought to sign off and request your consideration of my proposal.  However, I have to request that you bear with me a little further, because draft-ietf-suit-information-model-01 is not completely clear about how to identify updatable elements.
>
> A device with multiple updatable elements will need to know what element is targeted by a manifest, so that it can invoke an appropriate handler.   Section 4.10.  Manifest Element: Storage Location says plainly "This element tells the device which component is being updated.  The device can use this to establish which permissions are necessary and the physical location to use."  This descends from security threat MFT5: The target device installs the payload to the wrong location..  This parameter (aka storageIdentifier elsewhere in the document) would also serve very well in the three example scenarios in usability requirement MFUR3: multiple MCUs, separate code and configuration, and modular firmware.  Instead of doing that the document in section 4.11 introduces a new parameter, Component Identifier.
>
> For the use cases and threats given, I suggest that Storage Location is sufficient.  It can both identify a handler (e.g. file:) and if necessary provide a parameter to it (e.g. bin/fw/wifi). Component Identifier is redundant and should be removed.  If Component Identifier is removed, then the concepts of HeSA and HoSA are also unnecessary to the specification and can also be removed.

Component identifier has implications that are a bit subtle. A device with more than one filesystem would need to implement an artificial “component identifier” in the form of mount-points in order to use a file:// URI. There are no standard URIs for representing a flash offset address. There are no URIs I have seen for identifying a key in a key/value database.

Component Identifier is (in draft-moran-suit-manifest-03) an array of binary strings. If you were to regard that as text strings instead of binary strings, then, it’s functionally identical to a URI; the field separator is just implied by string length rather than by a character in the string.

I don’t believe that URIs are the right answer here. I think you’re right that either Component Identifier or Storage Location need to be retired, but I think that it’s Storage Location that needs to be retired.

Here’s the excerpt from draft-moran-suit-manifest-03

> The payloadComponent element contains a ComponentIdentifier. This specifies the module/component/location in which the payload should be installed. The meaning of ComponentIdentifier is application-specific. In general, the last bstr in the ComponentIdentifier defines where to store a payload within a given storage subsystem in a Heterogeneous Storage Architecture device, the remainder of the elements in the ComponentIdentifier define which storage subsystem to use to store the payload. payloadComponent is MANDATORY. When used on a single-image device payloadComponent MAY contain 0 elements. On multi-image devices, payloadComponent MUST contain at least one element.

I hope this clarifies things.

> To recap then, I want to suggest two changes:
>
> 1. Scope the requirement in section 3.3.1 (for the manifest sequence number to increase monotonically) to each updatable element (i.e. to each Storage Location, if item 2 is also acceptable).  This is to better support use cases involving multiple independent firmware maintainers.

I fully agree

> 2. Remove Component Identifier (4.11) from draft-ietf-suit-information-model-01.  State instead that MFUR3 (3.5.3) is satisfied by manifest element Storage Location (4.10).   Remove references to HeSA and HoSA from both documents.  Generalise language and expand examples around use of Storage Location to clarify usage in use cases involving devices with multiple separately updatable components.

I think we should remove storage location instead.

>
>
> Many thanks
>
> Amyas Phillips
> _______________________________________________
> Suit mailing list
> [email-masked]
> 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.