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

David Brown <david.brown@linaro.org> Wed, 04 October 2017 17:38 UTC

Return-Path: <david.brown@linaro.org>
X-Original-To: fud@ietfa.amsl.com
Delivered-To: fud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DC7132076 for <fud@ietfa.amsl.com>; Wed, 4 Oct 2017 10:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 KTN0QHGsCBa5 for <fud@ietfa.amsl.com>; Wed, 4 Oct 2017 10:38:25 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 9180513304A for <fud@ietf.org>; Wed, 4 Oct 2017 10:38:25 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id l15so11219670iol.8 for <fud@ietf.org>; Wed, 04 Oct 2017 10:38:25 -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=m/8vgNigvjGiVDXSK6B3WEzC8Ez+CKIg2mbNH834I64=; b=Cd5w/lg+FXATEyJsbhPfzfv1gB43VozDYVcs4CLxAUAYWcPWcPgAr3Gill+AAWNOhV 5GIyv8cXmcgwyse3GikqObMGl0O22OloT4XvYaWRxwGIzMI9JJ43pK2vObfMs7C48ubU ZS58uIqpOirlq6OsoBV4Hhls2cxroF/Rp2MIw=
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=m/8vgNigvjGiVDXSK6B3WEzC8Ez+CKIg2mbNH834I64=; b=RUHaiK8ivwHAsFDs4+te0FCXQ5tQkKoF6m1glrafMDptFGu0+PdbN99GraW42iR7Qj dEal61BGLVEDoOUkY/+ZqoCwSmDUP9/lzGTWpjB6HjQaWnqfBBhe/Ngyi2QB6c+AEYiy ibT/s8om6mTfO9cL7SPyNthzDO/40BewmLEItncjZTl4jVNAdbRvrC3+GWSe86Q2p3kz q0A9vzbmx4KTF0nGviTXxlWitA5aS0g4gkitkziMlGzeIx5mVuGF7VzY68Zuy2m0B4Rx XLCjxHEsmOFAfjBsSY5PEHaE8oJ8jgz+S5rf3XFgQzb5X1BQunM6MnMyEbFxrJpYvO89 GV6A==
X-Gm-Message-State: AMCzsaX3ufzT6rtB9tQ16d4s1LFujvQo0Ig3XfZkzBUF33IRnuZ4KxSO NUbTUZ4KPur9gkpZI4fcc4yCXtBY1Tk=
X-Google-Smtp-Source: AOwi7QAkagT0D/gnnBx0wJXEA3Hok3f83XyTquVg8WwzXSInsvCWNyvn1xK00193IBWffmjQhERW6Q==
X-Received: by 10.107.164.31 with SMTP id n31mr438192ioe.46.1507138704553; Wed, 04 Oct 2017 10:38:24 -0700 (PDT)
Received: from davidb.org ([2601:283:4300:dae1:31f7:2a2a:78a4:32be]) by smtp.gmail.com with ESMTPSA id e34sm7433612ioj.23.2017.10.04.10.38.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 04 Oct 2017 10:38:23 -0700 (PDT)
Date: Wed, 4 Oct 2017 11:38:22 -0600
From: David Brown <david.brown@linaro.org>
To: fud@ietf.org
Cc: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>, dev-mcuboot@lists.runtime.co, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, housley@vigilsec.com, david.waltermire@nist.gov
Message-ID: <20171004173822.hqin7lrbjyhuwvc3@davidb.org>
References: <CANK0pbaZuh1kHc6CA=B_3Mr3i9vxeqf+UGtD9wGpZs9=OFAxaw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <CANK0pbaZuh1kHc6CA=B_3Mr3i9vxeqf+UGtD9wGpZs9=OFAxaw@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/fud/8hadK-loYTaLuiOwPSaiIZ7Sj7o>
Subject: Re: [Fud] [dev-mcuboot] IoT firmware update standardization efforts @ IETF
X-BeenThere: fud@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: FUD - Firmware Updating Description <fud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fud>, <mailto:fud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/fud/>
List-Post: <mailto:fud@ietf.org>
List-Help: <mailto:fud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fud>, <mailto:fud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Oct 2017 17:38:27 -0000

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.

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.

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.

  - 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.

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