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

David Brown <david.brown@linaro.org> Fri, 15 March 2019 16:34 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 E8AF612788F for <suit@ietfa.amsl.com>; Fri, 15 Mar 2019 09:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: 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 rPQZRbuz2aHw for <suit@ietfa.amsl.com>; Fri, 15 Mar 2019 09:34:07 -0700 (PDT)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 9C885129284 for <suit@ietf.org>; Fri, 15 Mar 2019 09:34:07 -0700 (PDT)
Received: by mail-qk1-x72e.google.com with SMTP id z76so5856705qkb.12 for <suit@ietf.org>; Fri, 15 Mar 2019 09:34:07 -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:in-reply-to:user-agent; bh=p/tAkprrogKC1o3ouMfKPU3ZwISSyhhxLgzAUi4kgNE=; b=z6StOYzwZP0kAyYC+OU6FRg1pWlcdvHs/h9DG5iXs+N5x2eCS1CfMWM6k+CPv1mn66 xo1Y1edgKUUNqcd5hJ8ccYyPooYZ8a/0TBND05v3M5PYTxy+lpJ2p3TsELzR3wOM4uN1 jWqDoirupmHboqwK9D1NA7zyDhnric/WgkC7jH1bH4RFcIN5JGM7L/5CTx7tpZ2U0Lq6 t8119jWmWzjn00Ldqfr7EDjleDEOfvSm6GGSWGiKOStaUS9wjLEpux2bRuvzwTrncwEH 90nUeqKXOAVC8PLrsFIWtlB6r4KO5n2C87ZkhihcQg5ZOMAorQU4cqtUpt7qUuzAHWUk +ujg==
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:in-reply-to:user-agent; bh=p/tAkprrogKC1o3ouMfKPU3ZwISSyhhxLgzAUi4kgNE=; b=dnyPitwrLD9t6ylmpCswEn9kb5/B2x3PKtsGkvZ52jA41uyv93jSfw4vIEpRR/lvqx +WYoMa7uS4yP76KVKOn3B+89QZk7p6GKK3IxLP/3zFShfpk6zdC/xXS5LqiaTBErAUh7 csPoVfkhCmR2DxsYWbiKJqNHbjgCoePJo3PmXsqcdo/mifUSjNjmMefKLFTepH3GDlsi H2Obt7/LJm2c3rsKQHYr5zr4nnsHkRU7FB2EaZxrLNQdfjFsb4s4V6qnV8ywmOaVAugC 01MTX88P3kqQlhLvixO5ukxU22JLX3NszwqbBN/qzWwwq8rCmhBmpEiUlXtRgZKTP0SB Ggmg==
X-Gm-Message-State: APjAAAWR4K3Dm5I8AIFiE86jbwKTqR48WFM58Yq4j+oK/YTKisAs9DuN tf0dYx9UsEcS+yAWh+lIZnUgty4fojcFVg==
X-Google-Smtp-Source: APXvYqwuVgk7iCtkzAquEinIyIjvxZPBtJFUDcqW7DHaQ7Bb8d9y8zD3nWdct+MEYU98CuIUyeVYWw==
X-Received: by 2002:a05:620a:123b:: with SMTP id v27mr3321711qkj.29.1552667646396; Fri, 15 Mar 2019 09:34:06 -0700 (PDT)
Received: from davidb.org (cn-co-b07400e8c3-142422-1.tingfiber.com. [64.98.48.55]) by smtp.gmail.com with ESMTPSA id a73sm1391318qkb.66.2019.03.15.09.34.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Mar 2019 09:34:05 -0700 (PDT)
Date: Fri, 15 Mar 2019 10:34:02 -0600
From: David Brown <david.brown@linaro.org>
To: Brendan Moran <Brendan.Moran@arm.com>
Cc: "suit@ietf.org" <suit@ietf.org>
Message-ID: <20190315163402.GA25574@davidb.org>
References: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/3mRtgmtASykNBiWJTyEc0uqMPgI>
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, 15 Mar 2019 16:34:10 -0000

On Tue, Mar 12, 2019 at 10:34:44AM +0000, Brendan Moran wrote:
>draft-moran-suit-manifest-04 has now been published.
>
>https://tools.ietf.org/html/draft-moran-suit-manifest-04

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.

Thanks,
David