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

David Brown <> Sun, 17 March 2019 06:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05E7313115A for <>; Sat, 16 Mar 2019 23:27:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OoWbeX2uINgN for <>; Sat, 16 Mar 2019 23:27:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CFC8E131159 for <>; Sat, 16 Mar 2019 23:27:40 -0700 (PDT)
Received: by with SMTP id z25so14555701qti.13 for <>; Sat, 16 Mar 2019 23:27:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=VRM43PWG6BHBqgWQSzTs4qV+KEvGEkva8Bp+AFHnvCM=; b=LmZSP7dnQKUiT4dwf1IEx3WrOQ+dO6nRAtm266UGZDrk+uvcDqDz0AiGxuiOjX4miw J2M1RF9UpNcOagNoSVmUpwcKkyvtU2B+lVD76ZWno0xotVqrt5lF218HvxSZslouM489 xRYxnmvoljkz3Ip6aOzlqI6EMj+wPtEiEOZpNCGetr6gVZw3bBGv1YaNqDrxnlNseEHV a0Jf41jEz2SDpXlQ1m+kERJjoPp3kyTpGFrZrJWctFq1pJvlw3eKOMb55VnFZmldrG00 wXSvPL+SnoHHoR/WmYHHHNuka66AkYnzcWf/0cfYEwqEd4qsh16EcGwOqlnuPtFklCYY 44EA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=VRM43PWG6BHBqgWQSzTs4qV+KEvGEkva8Bp+AFHnvCM=; b=Q8eZA8kzVLMtV3j3R6JJjfoR0eoopAth5z3Ys93VQ4jyOajAd2MmnE1EmHQ6RToKUd qo1omjOwWNF+gfOU6IUWWrXXaMqzbfslH7ggXs/FWdFRv5hMuSzhbTIy9TE8iMwammww h+McL7dse3tdf95ppBl1FZgqBgeu+zlhHMuDDkApZuEtJyzkn6D/s2dOPSlHL6zTpTFb pIKGEuWCnPgHDsl/TjGolhCBBiXs/NHLGoImx6hKetfXE+jb5E5+pe0GvMqWyga6zTw+ Dm0JgCcn//ef7VNo7kvNDLsDTrOW/OXa2or79uOmULWuPhIn8wlfrxzBrGT59NCSC4As m8fg==
X-Gm-Message-State: APjAAAVEE3+M53yzNzzVoSXLhv7oAJRDThpKb5a2MOVeKsvKRouZBvfO uoiYxgngsV/zChoL4bZ3YGee2A==
X-Google-Smtp-Source: APXvYqz3PqZdmmQn2AfbBC7XVtsUfapU22KR2504tk6P6NJvPfiyqO/08y80ZUpZshllwGpYtgcX8A==
X-Received: by 2002:aed:2062:: with SMTP id 89mr9374046qta.273.1552804059715; Sat, 16 Mar 2019 23:27:39 -0700 (PDT)
Received: from ( []) by with ESMTPSA id a43sm5106541qta.54.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Mar 2019 23:27:38 -0700 (PDT)
Date: Sun, 17 Mar 2019 00:27:35 -0600
From: David Brown <>
To: Martin Pagel <>
Cc: Brendan Moran <>, "" <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [Suit] Introducing draft-moran-suit-manifest-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 17 Mar 2019 06:27:43 -0000

On Fri, Mar 15, 2019 at 11:24:19PM +0000, Martin Pagel wrote:

>I don't think that copying to RAM is mandatory or even recommended.
>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.


>-----Original Message-----
>From: Suit <> On Behalf Of David Brown
>Sent: Friday, March 15, 2019 9:34 AM
>To: Brendan Moran <>
>Subject: Re: [Suit] Introducing draft-moran-suit-manifest-04
>On Tue, Mar 12, 2019 at 10:34:44AM +0000, Brendan Moran wrote:
>>draft-moran-suit-manifest-04 has now been published.
>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.
>Suit mailing list