Re: [Suit] Call for adoption on manifest draft

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 18 June 2019 20:46 UTC

Return-Path: <mcr@sandelman.ca>
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 54DDC1200F6 for <suit@ietfa.amsl.com>; Tue, 18 Jun 2019 13:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 DM1B6XIN9Kfn for <suit@ietfa.amsl.com>; Tue, 18 Jun 2019 13:46:17 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7B8120052 for <suit@ietf.org>; Tue, 18 Jun 2019 13:46:16 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [208.113.60.115]) by relay.sandelman.ca (Postfix) with ESMTPS id 814BB1F450 for <suit@ietf.org>; Tue, 18 Jun 2019 20:46:14 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 27FE11328; Tue, 18 Jun 2019 16:46:25 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "suit\@ietf.org" <suit@ietf.org>
In-reply-to: <9314229C-01E8-4CCC-8EFD-4F5715072C30@arm.com>
References: <SN6PR09MB32643D17285ACEEED3D23FC4F0EB0@SN6PR09MB3264.namprd09.prod.outlook.com> <12354.1560790046@dooku.sandelman.ca> <9314229C-01E8-4CCC-8EFD-4F5715072C30@arm.com>
Comments: In-reply-to Brendan Moran <Brendan.Moran@arm.com> message dated "Tue, 18 Jun 2019 08:05:41 -0000."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Tue, 18 Jun 2019 16:46:25 -0400
Message-ID: <30900.1560890785@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/xsDui2-Ltjtv4MoVyUDJ0vVlRPE>
Subject: Re: [Suit] Call for adoption on manifest draft
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, 18 Jun 2019 20:46:20 -0000

Brendan Moran <Brendan.Moran@arm.com> wrote:
    > Hi Michael, I think it should be pointed out that
    > draft-morean-suit-manifest-04 incorporates the concepts of
    > draft-moran-suit-behavioural-manifest. Can you explain what it is that
    > makes you uncomfortable about the procedural approach?

okay, so I wasn't really sure as I re-read things quickly.
In my quick re-reading, I though that the definition of the proceedures was
still to come.  I guess I read too quickly!!!

Bluntly, it's the stopping problem :-)

But, before we worry about programs that do not terminate due to loops,
(because that issue can be solved... I maintain libpcap afterall!), the
problem that I have is the inability to reason about what the manifest does
by just looking at it.  I'm coming back to this paragraph after the ones
below: I think you've invented a proceedural machine that is trying really
hard not to be proceedural, but as a result it is even less understandable!

Are the problems we are trying to solve so complex, varied and unknown that
we need this?   Assuming that the answer really is yes, then who/what is
going to write these proceedures that we need?  It seems like a highly
technical job, if it's really a proceedure.

Looking at SUIT_Condition, (8.12) again, let me say that maybe the
description of this as a proceedure is really incorrect.  It looks
totally declarative to me.

Where I think it gets less declarative, as I understand it that
SUIT_Directive_RUN_Sequence can take a list of SUIT_Condition, evaluate them,
and then do stuff?   Basically, this is how we do if/then, I think.
The Coerce condition explanation could be better.

SUIT_Directive_Process_Dependancy seems like a way to invoke matching methods
on dependant manifests.    SUIT_Directive_Run, could just be called, "and
now, download stuff, and magic happens".  Yes, okay, it's all signed and the
like, but it seems rather hard to reason about.

I kept reading in detail, to section 9, and I wonder if I understand option 2
correctly.  A device with multiple images to load (and that needs to do in a
specific order, and there might be multiple levels), might have a proceedure
that looks like:

programA:
   if component-one-version < 4
   then
      load manifest for component-one-version=4; process.
   else if component-two-version < 5
   ...

where "load manifest" could effectively overwrite "programA" with the "component-one-program".
After that, the firmware finds it needs to upgrade, and starts programA
again, but this time, component-one is okay, so it proceeds?

I think that section 11, pseudo-code has "SHA256 A", when it should say
"SHA256 B", btw.

I didn't understand if "condition-component-offset" was a test or a action.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-