Subject: Re: [Suit] self-describing format vs fixed/binary manifest structure - pull parser

From: Martin Pagel <[email-masked]>
Date: Thu, 20 Dec 2018 02:05:14 +0000

Thanks, David, 
Yes, I am familiar with pull parsers, thanks to Brendan's example, but I'm not sure what the advantage of CBOR encoding provides if you build a custom parser for a particular fixed CBOR encoding/schema. Seems more complicated (and therefore error-prone) to me than using a packed binary structure which apparently MCUboot uses. If I understand correctly, you believe that such encoding wouldn't be appropriate as a manifest. I proposed to use such binary encoding in https://tools.ietf.org/html/draft-pagel-suit-manifest-00. 

I agree that there will be powerful and flexible MCUs which have capabilities where a CBOR  based flexibility would provide benefits, but for simple constrained devices, I think there is a benefit to use the same simple lean packed encoding for both the boot and update process, or am I missing some important aspect? If so, can you provide an example?
Best
Martin

-----Original Message-----
From: David Brown <[email-masked]> 
Sent: Wednesday, December 19, 2018 9:07 AM
To: Martin Pagel <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Suit] self-describing format vs fixed/binary manifest structure

On Thu, Dec 13, 2018 at 11:22:07PM +0000, Martin Pagel wrote:

>In general I actually agree with your assessment. If you have many 
>options, a well defined format like CBOR is much better than custom C 
>structures as you can use a standard, already vetted parsing library.
>The standard parser library turns the CBOR data into a data structure, 
>in IoT usually a pretty complex C structure. As the generic parser does 
>not understand the semantics of the fields (only the syntax as defined 
>by the CDDL), the developer still has to write code to verify a complex 
>data structure and enforce semantics and you still have to test/verify 
>such code.

There has been some good discussion on list about pull vs push parsing.  What you are describing is known as a push parser.  The parser parses the CBOR and converts it into a fairly rich data structure that describes the contents of the CBOR.  This is a common approach, and is quite useful on "powerful" computers, such as host-side tooling to process the data.

However, in a highly-resource-constrained device, this is not typically how it is done.  Usually a "pull" parser is used, which will have entry points to effectively expect a specific (and likely
limited) variant of the manifest, and simply abort if it see what is unexpected.  The data is not converted to another structure, but directly parsed/used in place.  For this kind of use, CBOR works very well.  Draft 3 of the manifest document has an accompanied example parser that works this way.

As a comparitive example, MCUboot uses a custom encoding format for the data in its manifest.  It consists of a small amount of data in a fixed structure (with defined byte ordering and packing), and a set of tag-length-value items (effectively a single CBOR map, with integer keys and all values as bstrs).  This is parsed with a similar custom parser for the data expected.  I expect the parser for the SUIT manifest to be somewhat larger than this, but within a similar magnitude.  Even this simple case of a single map, there is enough variation that a plain struct would not be appropriate to represent this information.

David

---

From: Derek Atkins <[email-masked]>
Date: Fri, 21 Dec 2018 13:05:35 -0500

Martin Pagel <Martin.Pagel=[email-masked]> writes:

> Thanks, David, 
> Yes, I am familiar with pull parsers, thanks to Brendan's example, but
> I'm not sure what the advantage of CBOR encoding provides if you build
> a custom parser for a particular fixed CBOR encoding/schema. Seems

The benefit is that you can create standardized server software that can
read the manifest to any particular MCU client without requiring special
per-MCU software.

The cost to the MCU to process a CBOR-pull is relatively low.  But the
cost to a server to deal with dozens (or more!) of uniquely-defined MCU
static manifest structures would be extremely high.

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Dec 2018 13:25:47 -0500

Derek Atkins <[email-masked]> wrote:
    >> Thanks, David, Yes, I am familiar with pull parsers, thanks to
    >> Brendan's example, but I'm not sure what the advantage of CBOR
    >> encoding provides if you build a custom parser for a particular fixed
    >> CBOR encoding/schema. Seems

    > The benefit is that you can create standardized server software that
    > can read the manifest to any particular MCU client without requiring
    > special per-MCU software.

    > static manifest structures would be extremely high.

Since I think it's unlikely to happen, there would be a many servers, with
the result that at least one or more systems would not have a server
available, and would never get upgraded.

That's an incredibly high cost: if that results in a compromised
network/building/airport/etc.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Martin Pagel <[email-masked]>
Date: Fri, 21 Dec 2018 20:20:27 +0000

Yes, Derek, 
CBOR may make it a bit easier to encode the manifest for various MCUs, but I believe the data encoding is only a small part of the server's responsibility. The server still needs to understand what file types, crypto algorithms, keys, image formats etc a particular MCU supports as the current manifest draft allows for a lot of options. If you use a pull parser on the MCU, then the server  also needs to understand the particular CBOR schema that a particular MCU expects as otherwise the pull parser will reject it. For that to happen, the server will need to maintain some type of capabilities/schema database for each MCU it can update. Once you define the SUIT fields (as defined in https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/ and https://tools.ietf.org/html/draft-pagel-suit-manifest-00 ), I would argue that it would be fairly simple for such capabilities database to also keep track of where/how these fields go into a packed binary structure. 
Best
Martin

-----Original Message-----
From: Derek Atkins <[email-masked]> 
Sent: Friday, December 21, 2018 10:06 AM
To: Martin Pagel <[email-masked]>
Cc: David Brown <[email-masked]>; Michael Richardson <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Suit] self-describing format vs fixed/binary manifest structure - pull parser

> a custom parser for a particular fixed CBOR encoding/schema. Seems

The benefit is that you can create standardized server software that can read the manifest to any particular MCU client without requiring special per-MCU software.

The cost to the MCU to process a CBOR-pull is relatively low.  But the cost to a server to deal with dozens (or more!) of uniquely-defined MCU static manifest structures would be extremely high.

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             https://nam06.safelinks.protection.outlook.com/?url=www.ihtfp.com&amp;data=02%7C01%7CMartin.Pagel%40microsoft.com%7C966abe35aed74cd400fe08d6676efc22%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636810123718776125&amp;sdata=5EyurzEMysogbmeae1gDT1hbD4A%2FARs%2Bxv%2B%2B5w%2Fu9XI%3D&amp;reserved=0
       Computer and Internet Security Consultant