Re: [Suit] MCUboot/Zephyr involvement

David Brown <david.brown@linaro.org> Fri, 15 June 2018 09:35 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 7AAE012F1A2 for <suit@ietfa.amsl.com>; Fri, 15 Jun 2018 02:35:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, 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 r6rLKufhcBSg for <suit@ietfa.amsl.com>; Fri, 15 Jun 2018 02:35:34 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 30D77126DBF for <suit@ietf.org>; Fri, 15 Jun 2018 02:35:34 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id o13-v6so2466615wmf.4 for <suit@ietf.org>; Fri, 15 Jun 2018 02:35:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=b8DUgN9jwD/2fXvNZLkWyCP1I32AoFjPfwP5i6sQugU=; b=eqAdqqXkcx05vJkkYW498XW6vNag9KTGKXTO7jGsgdRYoPWlShjcwyH32kYBmARFmG WofF4exhY44bUJRznKg9q2cv8ZZ+gy2H4h83zXKbIZIQ0XySNm5vb4FITIZmwnzpetL1 ahtwLOmrAHg6dPJlCgPBr4Damo4uSlLRrh/vw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=b8DUgN9jwD/2fXvNZLkWyCP1I32AoFjPfwP5i6sQugU=; b=ICv8ITtn7JReaTsFEatyqAkX5ViBrcwqFDSdRNan+GKY6GpZTZFT0UWrdiWW+ehFi9 HMSEqqzET/Y/8Nku7eYE7/9mo+XlyHNO57+zA9hngpLqQCM0fVBfCdfaGiqXzN4O+ror eNbiVPOEHDRshe5z62DrVMVoZ7FpdkusNpKwT4UGM+lO2n54Kt/nDvj6M0wD0g3N+3mx XyR6OYu+FuvB/4Ruh/GfvxZxPlhzOlGDu1yTEBkx+vfiDxX3ssHUKI25b2xXGgoORDbJ CPXhW5qtY4T8ksHo5ghY9t1DIpRPWtAYwY069NXVLWAChZBG+vqgFCB4XpVKhkj01XzA NynA==
X-Gm-Message-State: APt69E10l39Nh+80g4gC43XzyhyabV6Q4varAR5t8i+5IUBFsQxGORwL o2+PBDnFiXcg8xSeM9Z8mDG3YvZeTX0=
X-Google-Smtp-Source: ADUXVKKg/aZ2EcSztkVAeUXuXY5tFiW2XFIct61o1oG/JI4UOvi3PkYn6URgb9DgYyZSBaG50tOCcg==
X-Received: by 2002:a1c:1588:: with SMTP id 130-v6mr598888wmv.35.1529055332600; Fri, 15 Jun 2018 02:35:32 -0700 (PDT)
Received: from [192.168.0.181] (LPuteaux-656-1-48-212.w82-127.abo.wanadoo.fr. [82.127.83.212]) by smtp.gmail.com with ESMTPSA id t14-v6sm9261689wrm.79.2018.06.15.02.35.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jun 2018 02:35:32 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/10.e.1.180613
Date: Fri, 15 Jun 2018 11:35:26 +0200
From: David Brown <david.brown@linaro.org>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "suit@ietf.org" <suit@ietf.org>
Message-ID: <35BD193C-BA4B-426A-BCE0-DFB124DBA5AF@linaro.org>
Thread-Topic: [Suit] MCUboot/Zephyr involvement
References: <2E29EC1C-FAE7-47BE-B48C-F3797C1EC224@linaro.org> <4aaef410-fe5d-f883-d777-5d8bcb20dbd6@sit.fraunhofer.de>
In-Reply-To: <4aaef410-fe5d-f883-d777-5d8bcb20dbd6@sit.fraunhofer.de>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/7m-NWVXLmOoAkN9JPLZEV21Z1uA>
Subject: Re: [Suit] MCUboot/Zephyr involvement
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.26
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 Jun 2018 09:35:37 -0000

Would it be helpful for me to write up my "user stories" a bit more formally?

Thanks,
David

On 6/15/18, 11:18 AM, "Henk Birkholz" <henk.birkholz@sit.fraunhofer.de> wrote:

    Hello David,
    
    thank you for brining that up! Actually, at the last SUIT Hackathon, 
    follow-up Virtual Interim and then Design-Team meeting, there was a 
    strong tendency to allow for more than one "payload" (and corresponding 
    metadata) in one "manifest" (with its own corresponding metadata). The 
    drafts do not reflect that yet, but I am under the impression that on 
    one hand, this will be incorporated soon, and on the other hand, every 
    "user story" that a set of corresponding requirements can be derived 
    from is welcomed in the context of the SUIT information model.
    
    Dear WG, please bash my answer, if I am writing anything misleading here :)
    
    Viele Grüße,
    
    Henk
    
    On 06/15/2018 11:10 AM, David Brown wrote:
    > This week, Linaro held a SPRINT where among other things, we discussed 
    > our future direction for firmware upgrade, especially in regards to two 
    > configurations: a Secure/Non-secure dual image system on a single CPU, 
    > and a similar dual image running on two separate CPUs.
    > 
    > At this point, management of multiple images is not deeply discussed by 
    > the proposed documents, and I’m wondering if this kind of support would 
    > best be left to additional documentation.
    > 
    > One thing I’d like to consider is how multiple images could be supported 
    > by a single manifest. There are possibilities, such as concatenating the 
    > manifests, or just having to track the multiple manifests separately. 
    > Most of the fields in the manifest allow multiple instances of that 
    > field, except for the payload, where the manifest only describes a 
    > single payload. What would be the ramifications of allowing 1 or more 
    > payload blocks in the manifest?
    > 
    > Thanks,
    > 
    > David__
    > 
    > 
    > 
    > _______________________________________________
    > Suit mailing list
    > Suit@ietf.org
    > https://www.ietf.org/mailman/listinfo/suit
    >