Subject: Re: [Suit] Which type of devices? C Struct

From: Martin Pagel <[email-masked]>
Date: Thu, 8 Nov 2018 06:11:58 +0000

Alex,
Yes, in my mind the primary focus of the SUIT WG ought to be the architecture and information model which defines the schema. The manifest format has lots of optional fields, the question is whether a CBOR encoding can cover all usage scenarios or whether very constrained devices would benefit from a format which doesn't require a parser.

The binary format I proposed can be represented in C or any other language, it's just that C is quite common for MCUs.
Its no different than the fixed fields Hannes presented when talking about how the addresses the MCU uses to start the boot loader;
He presented C code, but other programming languages can be used, too.
Martin

From: Alexander Pelov <[email-masked]>
Sent: Wednesday, November 7, 2018 9:40 PM
To: Martin Pagel <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Matthias Waehlisch <[email-masked]>; [email-masked]
Subject: Re: [Suit] Which type of devices?

Hi Martin, all,

Thanks for doing the hard work of looking into how to minimise to extreme the footprint of SUIT and the whole firmware update process!

Several points
- Only ONE schema for all potential encodings (otherwise, the chaos would be just too much)
- Do we need ONE or TWO encodings (no more)?
  - I'd have a tendency to start with we do ONE, unless there are cases that cannot be covered (with real-world scenarios) - and then and only then a second one is added

So, for me, this reads as:
- CBOR + CDDL
- If anything else is to be considered, what are the use-cases and how is this evaluated ?

Using a mapped binary structure does seem like a seducing opportunity, if you only use C. How about all the tooling that could use other programming languages?
How about portability? (e.g. a C structure compiled on a big machine may not render the same memory layout as the one on a MCU.. so how are you going to even write the Metadata?)
One thing I am always very hesitant about is bugs and having correct code. And cost. And premature optimisation.

And finally - what is the benefit? I haven't seen any numbers on the C-Struct VS CBOR and use-cases that cannot be addressed by using CBOR. Until then, we can always have meta-discussions on how this or that could be made smaller.

This being said, I am more and more convinced that we need to split the process in two:
- Focus on CBOR + CDDL, with enough flexibility via Optional fields to address even very tiny devices (Class 1, Class 0 is nice to have)
- Later on (once all the CBOR+CDDL work is stable), IF there are use-cases that would require fighting for several tens of bytes (or even hundreds of bytes), write a spec how to translate a specific Manifest Profile to a specific binary serialization.
  - Ideally, that could stat with some "magic" number, that corresponds to a CBOR-encoded header that would make a generic CBOR parser understand it's not the intended public.
  - We may very well find that CBOR+C-struct Manifest can coexist.. (e.g. a CBOR structure that contains a binary BLOB, that is the effective binary-mapped C-Struct) ...

All these things sound awfully complex to me. So I'd really love to see ONE efficient, extensible and interoperable way to do it right.

That being said, the discussion today was really useful to me to solidify my opinion on the topic, so thanks for the great arguments and for the great work! I do think it has great value - and I'll be happy see it get standardized on a second step (after we get the first Manifest format out).

My 2c
Alex

On 8 Nov 2018, at 12:05, Martin Pagel <Martin.Pagel=[email-masked]<mailto:Martin.Pagel=[email-masked]>> wrote:

Hannes and Matthias,
I think there is an increasingly large spectrum of MCUs with different capabilities, some now include crypto accelerators, then the crypto code overhead is quite small.

We currently use the proposed format in a quite constrained MCU implementation, for both software update and secure boot. Crypto operations are done via crypto accelerator. We use a simple C Struct to access the manifest elements, no need for schema validation. With the proper Struct definition this is compiler safe, Brendan.

Brendan talked about a life cycle on how to drop data elements once they are not needed anymore. This is complexity we would like to avoid on constrained MCUs with a simple memory mapped binary structure.
Martin

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Hannes Tschofenig
Sent: Wednesday, November 7, 2018 8:35 PM
To: Matthias Waehlisch <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Suit] Which type of devices?

Hi Matthias,

The contribution by Martin with his custom binary format (as an alternative binary format to the CBOR/COSE standardized format) is based on his impression that
* a custom binary format allows to reduce the size of the manifest by some (yet unknown) number of bytes, and
* CBOR and COSE libraries are not used in industrial IoT deployments.

I personally think that this discussion is unrelated to the device classes since the overhead really comes from the crypto, as several speakers on the microphone noted.

Ciao
Hannes

-----Original Message-----
From: Matthias Waehlisch <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, November 8, 2018 11:02 AM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Suit] Which type of devices?

Hi Hannes,

 after Brendan's presentation there were some remarks on this. The discussion made slightly the impression that the group needs to argue why the SUIT solution should also fit into Class 1 devices.

 Based on the charter, the SUIT solution needs to suit Class 1, which has implications on design decisions and on which topic the WG invests time mostly.

 Supporting Class 1 devices is the default, anything else is nice to have.

Cheers
 matthias

On Thu, 8 Nov 2018, Hannes Tschofenig wrote:

Hi Matthias,

Which discussion during the meeting today did you give you the
impression that we are not aiming for this goal?

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Matthias Waehlisch
Sent: Thursday, November 8, 2018 10:10 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Suit] Which type of devices?

Hi,

 I didn't get the discussion today. Just as a reminder, the SUIT WG Charter says explicitly: "This group will focus on defining a firmware update solution (taking into account past learnings from RFC 4108 and other firmware update solutions) that will be usable on Class 1 (as defined in RFC 7228) devices, i.e., devices with ~10 KiB RAM and ~100 KiB flash. "

Cheers
 matthias

--
Matthias Waehlisch
..  Freie Universitaet Berlin, Computer Science ...
https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.f
u-berlin.de<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fu-berlin.de%2F&data=02%7C01%7CMartin.Pagel%40microsoft.com%7Ca67aa918d96d49682d8a08d6453ca605%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772524134363374&sdata=%2BhMXOdL4IY7KBSg1DysD8NONRXq8mf3B9ih5l5hwfdU%3D&reserved=0>%2F~waehl&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7CMartin.Pagel%40microsoft.com%7Ca67aa918d96d49682d8a08d6453ca605%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772524134373382&sdata=Ym0xGzfbyin2vagoOEVp%2Bz9r0SChdWq25%2FbuXJ6Ro0I%3D&reserved=0>%7
Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7
C1%7C0%7C636772485305445335&amp;sdata=ct5txfAAcRM%2BgHw1GoOImrr3bhU8ou
ByV2kMW%2BjGbHw%3D&amp;reserved=0

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
etf.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.org%2F&data=02%7C01%7CMartin.Pagel%40microsoft.com%7Ca67aa918d96d49682d8a08d6453ca605%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772524134383390&sdata=E0Nw%2BWJgmKPdXpHU8rHMHs0S1t8qzGj5u8Nvs%2FK08L8%3D&reserved=0>%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40
microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmicrosoft.com%2F&data=02%7C01%7CMartin.Pagel%40microsoft.com%7Ca67aa918d96d49682d8a08d6453ca605%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772524134383390&sdata=2oNqLo5jjLcdFbxjwRTUMDZuLASm%2BLl2v3kpTRz0efo%3D&reserved=0>%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91a
b2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=%2FjHzLtzk04XkWqc
uOAAsYjD9Wz%2FK7xxvsqILxP6Rr%2Fc%3D&amp;reserved=0
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
Matthias Waehlisch
...  Freie Universitaet Berlin, Computer Science ... https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.fu-berlin.de%2F~waehl&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=ct5txfAAcRM%2BgHw1GoOImrr3bhU8ouByV2kMW%2BjGbHw%3D&amp;reserved=0<https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.fu-berlin.de%2F~waehl&data=02%7C01%7CMartin.Pagel%40microsoft.com%7Ca67aa918d96d49682d8a08d6453ca605%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772524134393394&sdata=wizlj7xiXVdxl2H9X5k9pSn1eODUo0qsv92BvItsUQE%3D&reserved=0>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=%2FjHzLtzk04XkWqcuOAAsYjD9Wz%2FK7xxvsqILxP6Rr%2Fc%3D&amp;reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7CMartin.Pagel%40microsoft.com%7Ca67aa918d96d49682d8a08d6453ca605%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772524134403406&sdata=aQDd3yU9n%2BYTnyvPOv8P4gPU5VPJ9KDaIGcIXuns7QA%3D&reserved=0>

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7CMartin.Pagel%40microsoft.com%7Ca67aa918d96d49682d8a08d6453ca605%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772524134414542&sdata=VGrdGyWvLaklmzeTAVo64lyfodNAjtn7%2BR2zV9XHhq0%3D&reserved=0>

---

From: "Puzdrowski, Andrzej" <[email-masked]>
Date: Thu, 8 Nov 2018 10:42:29 +0000

>From perspective of that what mcuboot project is supporting now actually we see the point for having more constraint manifest as well. We have in parallel some project discussion related to provide a manifest format for multiple image / multiple MCU solutions (so fare decided to extend own manifest format called TLV, and awaiting for SUIT results).

We are aware that CBOR and COSE parser will increase footprint in comparable big amount (informative: mcuboot can fit into 16 - 48 KB depend from configuration when target is a nR52 SoC).

Recap
I see the point in having the minimized solutions for manifest format. I'm agree with Martin comments.

BR
Andrzej

From: Suit [mailto:[email-masked]] On Behalf Of Martin Pagel
Sent: Thursday, November 08, 2018 7:12 AM
To: Alexander Pelov <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; [email-masked]; Matthias Waehlisch <[email-masked]>
Subject: Re: [Suit] Which type of devices? C Struct

Alex,

From: Alexander Pelov <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 7, 2018 9:40 PM
To: Martin Pagel <[email-masked]<mailto:[email-masked]>>
Cc: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Matthias Waehlisch <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Suit] Which type of devices?

Hi Martin, all,

Several points

Using a mapped binary structure does seem like a seducing opportunity, if you only use C. How about all the tooling that could use other programming languages?
How about portability? (e.g. a C structure compiled on a big machine may not render the same memory layout as the one on a MCU... so how are you going to even write the Metadata?)
One thing I am always very hesitant about is bugs and having correct code. And cost. And premature optimisation.

My 2c
Alex

Hannes and Matthias,

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Hannes Tschofenig
Sent: Wednesday, November 7, 2018 8:35 PM
To: Matthias Waehlisch <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Suit] Which type of devices?

Hi Matthias,

Ciao
Hannes

-----Original Message-----
From: Matthias Waehlisch <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, November 8, 2018 11:02 AM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Suit] Which type of devices?

Hi Hannes,

Cheers
 matthias

Hi Matthias,

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Matthias Waehlisch
Sent: Thursday, November 8, 2018 10:10 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Suit] Which type of devices?

Hi,

Cheers
 matthias

--
Matthias Waehlisch
...  Freie Universitaet Berlin, Computer Science ...

--
Matthias Waehlisch
....  Freie Universitaet Berlin, Computer Science ... https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.fu-berlin.de%2F~waehl&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=ct5txfAAcRM%2BgHw1GoOImrr3bhU8ouByV2kMW%2BjGbHw%3D&amp;reserved=0<https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.fu-berlin.de%2F~waehl&data=02%7C01%7CMartin.Pagel%40microsoft.com%7Ca67aa918d96d49682d8a08d6453ca605%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772524134393394&sdata=wizlj7xiXVdxl2H9X5k9pSn1eODUo0qsv92BvItsUQE%3D&reserved=0>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 8 Nov 2018 19:46:50 +0700

On Nov 8, 2018, at 13:11, Martin Pagel <Martin.Pagel=[email-masked]> wrote:
> 
> a format which doesn’t require a parser

CBOR does not require a “parser” (this is not a text format).

It does use variable length encoding, so that requires something like

  uint64_t val = ai;
  switch (ai) {
  case AI_1: val = ntoh8p(pos); pos += 1; break;
  case AI_2: val = ntoh16p(pos); pos += 2 ; break;
  case AI_4: val = ntoh32p(pos); pos += 4 ; break;
  case AI_8: val = ntoh64p(pos); pos += 8 ; break; /* Well, if you need that… */
  }

(Pasted and macro-expanded out of cn_cbor.)
That is all.

What CBOR does NOT give you is 4-byte alignment, so you may want to use it within something that provides that if you want to include the actual firmware on the side.

Grüße, Carsten