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

David Brown <david.brown@linaro.org> Fri, 22 March 2019 17:39 UTC

Return-Path: <david.brown@linaro.org>
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 9A0F0131376 for <suit@ietfa.amsl.com>; Fri, 22 Mar 2019 10:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=linaro.org
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 EIBLSReyBM-n for <suit@ietfa.amsl.com>; Fri, 22 Mar 2019 10:39:13 -0700 (PDT)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333F4131381 for <suit@ietf.org>; Fri, 22 Mar 2019 10:39:13 -0700 (PDT)
Received: by mail-qt1-x830.google.com with SMTP id t28so3435503qte.6 for <suit@ietf.org>; Fri, 22 Mar 2019 10:39:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=NCy4tMod9JyH3GbLZCxAAB8s6ESIQyU2eVPTo0JVc1o=; b=M3onU8MZF2wE09nFCYZM2TLrdk8DvQ+S3u2BKEHKk2rJeoFBhl0oYpMC/d3SxVn+mo vjo3cinnsmiExnnuJrnwqko4QWAHmAZIv19f+0v+bcwBJfN8Qz+OXmKu+KG25i28kljA U/TnPCzshnBYLx2e3OM3cs4Qg5f1zoFYzBWNsFZeGQs+xbPs+at/5dB+jCnCtGZOcSXP EYH344hw+NoNAwGvdpujFDL4KuNOmZMNrMO3un8wM83GftW0YjKqCpvPYi70/3+XSrmp GYps4OCfhVUXHIC8nIwD6uhyMqn21FKzJOB4YF1r5cT5L/Mmpgvy5lBu49krXS/KuNOC 8ZZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=NCy4tMod9JyH3GbLZCxAAB8s6ESIQyU2eVPTo0JVc1o=; b=JkV2o8iWjTkHPm9g/n7zKobpDE8byadLywXwgi7BZoXVHBwyWmONDNy//kWQ8kD3cx k581A/2NQMhEdJcWj5HGALifPdT8mAApa/VPlmST9IIlHYOfXreDfgK8+lIgG8O6BT6U pGny8JPwO0KCeLWknqq6wr2eq8B9mhsoKJ6JU/kH8caN5DDGpU+EG0Ag+4heTgV4Jzf0 ovgKAzRcFhwCgYP2NPD4FtlmurAgw4fec51X2L93pLl7RTz2C0l+2jLHsIRTk2EcsHyL /11WCHbJoz6K3I1AiRdf5biREnLy/wJUdPeQ9OSQfJCv4lIij0PRTlm5uT594oF8Y5Bt PkAw==
X-Gm-Message-State: APjAAAXQJrCoiNntkC8ezmxW3/BXJZrmJHpVPy3giaLHFar9Vj2dm6er wVJyWSGDarD1bmmeBhCzlUGGuQ==
X-Google-Smtp-Source: APXvYqy2bfeGfIuQN+bH0y+zNoOBlzoulc9RHNHNGCps1dnhI3gOrvAyYAv8uoyyutIfz+7/NrGF8A==
X-Received: by 2002:ac8:24f2:: with SMTP id t47mr9122125qtt.192.1553276351995; Fri, 22 Mar 2019 10:39:11 -0700 (PDT)
Received: from davidb.org (cn-co-b07400e8c3-142422-1.tingfiber.com. [64.98.48.55]) by smtp.gmail.com with ESMTPSA id u16sm8732002qtc.84.2019.03.22.10.39.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Mar 2019 10:39:11 -0700 (PDT)
Date: Fri, 22 Mar 2019 11:39:08 -0600
From: David Brown <david.brown@linaro.org>
To: Brendan Moran <Brendan.Moran@arm.com>
Cc: "suit@ietf.org" <suit@ietf.org>
Message-ID: <20190322173908.GA17361@davidb.org>
References: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com> <20190315163402.GA25574@davidb.org> <59F62162-578C-4975-A25B-EC261A7F4F7D@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <59F62162-578C-4975-A25B-EC261A7F4F7D@arm.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/omoqnqAutb-iWyVj24RVqEWIAYE>
Subject: Re: [Suit] 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: Fri, 22 Mar 2019 17:39:16 -0000

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