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

Cody Addison <c-addison@ti.com> Tue, 26 March 2019 02:07 UTC

Return-Path: <c-addison@ti.com>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE7A1201DB for <suit@ietfa.amsl.com>; Mon, 25 Mar 2019 19:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ti.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEycEwFktGqy for <suit@ietfa.amsl.com>; Mon, 25 Mar 2019 19:07:03 -0700 (PDT)
Received: from fllv0015.ext.ti.com (fllv0015.ext.ti.com [198.47.19.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAAF81201D0 for <suit@ietf.org>; Mon, 25 Mar 2019 19:07:02 -0700 (PDT)
Received: from fllv0035.itg.ti.com ([10.64.41.0]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id x2Q26xfU000979; Mon, 25 Mar 2019 21:06:59 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1553566019; bh=x+UvhoyUgz8Fvb/xTYIj18IP3oFSZDbiKo8somv+f8U=; h=References:From:To:CC:Subject:In-Reply-To:Date; b=nbd16ajIJjpeb6xFk/23GwpDsEiha0s4aV/PDTWGaW5afDeQxbyXUNsdbNdsL8bor clAt1qhJBTSIlToQI9i7uxTpw6aXMsl+TRxwMH+0jPIuJq76EgExSubjb3lgBERXht 8bs3+pK0d6cA9GjBM7YVdnsdy8qvWvvSwo/qAzTo=
Received: from DFLE103.ent.ti.com (dfle103.ent.ti.com [10.64.6.24]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id x2Q26xxm063036 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 25 Mar 2019 21:06:59 -0500
Received: from DFLE109.ent.ti.com (10.64.6.30) by DFLE103.ent.ti.com (10.64.6.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 25 Mar 2019 21:06:59 -0500
Received: from lelv0327.itg.ti.com (10.180.67.183) by DFLE109.ent.ti.com (10.64.6.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Mon, 25 Mar 2019 21:06:59 -0500
Received: from LC02T30BGGTFM (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTPS id x2Q26qaQ063689 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Mar 2019 21:06:59 -0500
References: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com> <20190315163402.GA25574@davidb.org> <59F62162-578C-4975-A25B-EC261A7F4F7D@arm.com> <20190322173908.GA17361@davidb.org>
User-agent: mu4e 1.1.0; emacs 26.1
From: Cody Addison <c-addison@ti.com>
To: <suit@ietf.org>
CC: Brendan Moran <Brendan.Moran@arm.com>
Message-ID: <m1o95yie6z.fsf@ti.com>
In-Reply-To: <20190322173908.GA17361@davidb.org>
Date: Mon, 25 Mar 2019 21:06:52 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/Vu_oqIFE1QsWx3bZ7c3tsCFjNPY>
Subject: Re: [Suit] [EXTERNAL] Re: Introducing draft-moran-suit-manifest-04
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2019 02:07:05 -0000

David, Brendan,

> Any thoughts on what is appropriate to even represent in the manifest?
> The two instructions that the bootloader would follow would be "swap"
> or "apply" (depending on configuration), and "run".  Right now, we
> distinguish swap vs copy by whether the new image contains the "image
> ok" marker, but having two instructions could distinguish this as
> well.

Was there ever a consensus on how to represent this operation in the manifest? The copy instruction seems like the appropriate instruction to use in the install phase, but I'm not sure what component identifier to use for the source. My working assumption has been that a tool will create a single file which contains the manifest and payload data. Take a simple example of a dual core MCU:

+--------------+
+ Manifest +
+--------------+
+ FW1        +
+--------------+
+ FW2        +
+--------------+

That file would then be streamed to the device and installed either on the fly or in separate download and install stages where the download includes the manifest and payloads. In more complicated scenarios there may be multiple payloads that are optionally fetched. I see how to use the SUIT_Condition element to control which payloads get installed, but not how to reference payloads within the file. Maybe my working model is incorrect and this is not how the manifest is intended to be used?

David Brown writes:

> On Thu, Mar 21, 2019 at 04:30:53PM +0000, Brendan Moran wrote:
>
>>Reboot resilience for “swap” is probably outside the scope of this draft.
>>Adding a condition to check the success marker might be useful.
>
> I'm not sure it really even makes sense to describe the reboot
> resilience in the manifest.  At least for swap, it is a large number
> of steps that have to be done carefully, along with a lot of extra
> state that is written every step.  I would think this intermediate
> state is beyond the scape of the manifest.
>
> For those interested, I've thrown together a bit of an amination
> describing how the swap operation works in MCUboot, including at least
> part of its state.
>
>   https://www.youtube.com/watch?v=TvXjw2l0Cd0
>
> I'm not actually sure it is even going to make very much sense for
> MCUboot to follow steps in the manifest, rather than just verifying
> that they are present.  The steps make sense for the download
> application.
>
> Some of the modes I envision ultimately supporting in MCUboot:
>
>  - swap: The current mode.  This is initiated by a "trailer" being
>    written to the secondary image, and the bootloader verifying that
>    the manifest is correct.  It might make sense for it to follow the
>    "swap" instruction, but it would only look at this secondary
>    manifest after being instructed to, out of band.
>
>  - overwrite: The other current possible mode.  Also initialized by
>    the "trailer" being written at the end of the second image, and
>    the bootloader verifying that the manifest is correct.  The second
>    image is copied to the primary image slot.  This is easier to make
>    resilient, since the entire operation can be restarted.
>
>  - Boot best: not implemented.  The upgrade would download an image
>    in the slot that is not being used.  There would be two images
>    built, one linked to each slot.
>
> Right now, upon boot, MCUboot checks the manifest of the primary slot,
> and will boot that image if it is valid.  Before this, it will check
> the trailer of the second slot to see if an upgrade is requested, and
> if so, check that manifest, and possibly swap/overwrite depending on
> how it is built.
>
> One difficulty I see following steps in the manifest is that the code
> currently maintains state out-of-band from the manifest.  The current
> state is:
>
>  - copy done: indicates that a copy/swap has finished and the primary
>    image can be checked (avoids having to check the secondary
>    partition manifest on every boot).
>
>  - image ok: after a new image boots, and decides it is functional,
>    it writes this marker.  Without this marker being written, a
>    subsequent reboot will cause the swap operation to be repeated to
>    revert the image.
>
>  - swap state: a series of markers to track the state of a swap, so
>    that it can be resumed if necessary.
>
> Any thoughts on what is appropriate to even represent in the manifest?
> The two instructions that the bootloader would follow would be "swap"
> or "apply" (depending on configuration), and "run".  Right now, we
> distinguish swap vs copy by whether the new image contains the "image
> ok" marker, but having two instructions could distinguish this as
> well.
>
> There is some concern within the MCUboot community about semantic
> differences between how the existing manifest is processed and how
> SUIT will be processed.
>
> Thanks,
> David
>
> _______________________________________________
> Suit mailing list
> Suit@ietf.org
> https://www.ietf.org/mailman/listinfo/suit