Re: [Suit] [SUIT] [dev-mcuboot] IoT firmware update standardization efforts @ IETF

[Brendan Moran <[e-mail]>]

Thank you for your comments. I think there are a few things that I can clear up. I don’t expect that much change is necessary to MCUboot in order to support the SUIT manifest & architecture. It looks like it’s already pretty much compatible.

See below for more comments.

Thanks,
Brendan Moran

> On 4 Oct 2017, at 18:38, David Brown <[e-mail]> wrote:
>
> On Fri, Sep 22, 2017 at 10:01:18AM +0200, Emmanuel Baccelli wrote:
>> Dear MCUbooters
>>
>> I wanted to bring your attention to an effort starting at IETF to standardize
>> some aspects fo firmware updates.
>>
>> I think it would be useful if some MCUboot/Zephyr/MyNewt could participate.
>>
>> The working group about to be created is called FUD [1].
>> There are a couple of initial drafts [2] and a mailing list [3] through which
>> discussion happens, as usual for such efforts.
>>
>> FYI the next f2f meeting will be at IETF 100 [4].
>
> Thanks for the information.  I have joined the fud mailing list, and
> intend to become involved.
>
> I work on MCUboot as well as on the Zephyr project.  MCUboot address a
> small part of the firmware update process, namely performing the
> atomic operation of the actual final firmware upgrade.  It also
> supports additional features such as revert when an image is
> determined to be nonfunctional.
>
> MCUboot original came from the Mynewt project, and is a part of their
> update solution.  The Zephyr project has not defined firmware update
> beyond porting MCUboot to Zephyr.  As such, what is being discussed at
> FUD is very applicable.
>
> I'd also like to give a very short overview of MCUboot, since its
> existing image formats may need to change to accomodate a CMS
> formatted firmware package.

I should clarify one element of the SUIT draft:
SUIT comes in two parts: 1) a firmware update architecture, 2) a manifest format.

The manifest format is for security in transport and at rest, and it provides the metadata that a target device needs in order to determine applicability and installation instructions. This does NOT mean that the manifest is necessarily what the boot loader should understand. We have been using HMAC to authenticate a much simpler metadata block for the boot loader to consume. This does not support a trusted boot story, since the boot loader must trust the update client.

So, there are certain benefits to having the boot loader understand the manifest format, however it is not strictly necessary.

> The primary design constraint behind MCUboot's image format is the
> support for execute in place (XIP) MCU devices.  Typically, these
> devices begin executing from an address at a vector near the beginning
> of flash.  MCUboot is itself installed at the beginning of flash, and
> expects both the runnable image and the upgrade image to occupy
> partitions following this.
>
> The runnable application is modified from a standalone MCU application
> in several ways:
>
> - It is linked at an address for the runnable partition (referred to
>   as Slot 0 in the MCUboot design documentation).
>
> - There is a small header at the beginning, with flags, a header
>   size field, and an image size field.  This can be used to compute
>   the address of the end of the image.
>
> - After the image is a simple TLV-formatted encoding of a signature
>   over the header and the image.

This is almost the same as the format that we have been using. The exception is the signature. We place the signature at the end of the metadata header, and include a hash of the firmware in the metadata header. This allows the boot loader to verify authenticity prior to validating integrity. In practice, I doubt there is significant behavioural difference between these two solutions.

> In order to support a CMS formatted firmware image, MCUboot will need
> to take one of several approaches.
>
> - The firmware package will be unwrapped outside of the context of
>   the bootloader.  The content of the CMS payload would have the
>   header and TLV signature already on it.  This would require no
>   modification to MCUboot, but may be difficult to implement in a
>   RAM-constrained device that does not have sufficient RAM to hold
>   the entire firmware package.
>
> - MCUboot could be modified to unpack the firmware package from the
>   upgrade partition when copying it to the runnable partition.  This
>   would add complexity, as well as make MCUboot's current rollback
>   mechanisms more complex.

Where encrypted images are used, we typically decrypt the image straight into the upgrade partition on the fly, so that the boot loader can be as simple as possible. That might make MCUboot’s rollback mechanism manageable in this scheme.

> - The content inside of the firmware package could be designed to be
>   executable directly out of the firmware package.  With DER
>   encoding, this will be somewhat complicated, as the length of the
>   preceding data in the firmware package contains encoded values
>   that depend on the length of the firmware package itself.  There
>   are possible implementations, such as repeating the link and
>   package operation until a fixed point is reached.

This last option is much less complex than it looks. Firmware is contained in the manifest by reference (hash and URI). This means that there is no requirement for the firmware to be related to the manifest in memory, so you can place the firmware wherever you want. We typically reserve a block at the beginning of an erase sector for metadata, followed by the firmware image, starting at the next vector-table aligned address.

> I hope to be able to bring useful feedback based on our experience
> with MCUboot and performing updates of this class of devices.
>
> Thanks,
> David Brown
>
> _______________________________________________
> Fud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/fud

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.