From nobody Wed Apr 5 06:19:39 2017 Return-Path: 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 851C61250B8 for ; Wed, 5 Apr 2017 06:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 (2048-bit key) header.d=gmail.com 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 G-wIJ9yqeRHk for ; Wed, 5 Apr 2017 06:19:35 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 32E63127B57 for ; Wed, 5 Apr 2017 06:19:35 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id z204so6739387vkd.1 for ; Wed, 05 Apr 2017 06:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=Zf5tlh1qkVSWDVcBkSzER4hia1ArI5B/ZOOo0pBkM0Q=; b=aOEDjARKf8fKZWQrEQe4MHAq2EqJtetqWttgioLTzQeBwQdPTETBjbZ/glXXEEfTB3 uttNEN23b33bop1q48ieeUUmtBOoAxSQf0kx8KiND5zR6otTtnWK0zD9XmVDdY/P4XYB 5Xr9eJGs6RTdSi0sInkuVhe/DHp/3BzmXwYxMPpNDrFPiYcILfqytmJmZWLK0ed3xoOR eAjL5k1xzu2Didm1F8nD+Hz536R8xtYU1LtgnAYBa/7yvB9bXITCbFqKWkk9Y+cN/pjI gi3/Gj9UbQY/zytjo2HO9mQdzmCms6eIlB5cn7o9GTmeuBn/bROg5sDzovs6M+cIvfLN r7HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=Zf5tlh1qkVSWDVcBkSzER4hia1ArI5B/ZOOo0pBkM0Q=; b=LV7q3Fp8sYKRBsNDjsf4nDvjMTFYtYvem+PlwB3NKLa7VId083gLwYENmnQWg0KzYZ SiPkyaZ1Ju5mAyITPomOhbK4G6jdT83o6oUK/uFblpWIeFChP+MEu8rrTZGEOZHveRiP RMhEEF/C01Yr403Hg7I+WMPbVIxnJIXpQWxedwneN5r9fC/x1WG0JiZVnr/bqxFnV8T5 YYROW/+LE9fWJv3QkkToXomjpEoEeFoi6ezCosHPO/rQc+YQh2lerhiUlgeUe1efb2dE +T00l8RBlfRVnN3mvzfmybLw2vaSgVf0tqV9cqX3hJLEkPayBHUoHW2X5S/rkAYW8kqj irBA== X-Gm-Message-State: AFeK/H0onmSnFTrnFmuqy4NEUaWgr3v86AlxjRP3TJ53nv/WgKfIcXvAEoEicgOu47QPujra1hoi+m2/jEJ+OQ== X-Received: by 10.31.15.82 with SMTP id 79mr12545279vkp.156.1491398374022; Wed, 05 Apr 2017 06:19:34 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.159.55.173 with HTTP; Wed, 5 Apr 2017 06:19:13 -0700 (PDT) In-Reply-To: <72189668-4154-c0f5-92a9-5fdf7c184939@gmx.net> References: <32221986-c3cd-60a5-0b72-5576303af3b3@gmx.net> <72189668-4154-c0f5-92a9-5fdf7c184939@gmx.net> From: Emmanuel Baccelli Date: Wed, 5 Apr 2017 15:19:13 +0200 X-Google-Sender-Auth: OMBdmKKtH_UUg-cNgYwEmLiTuAE Message-ID: To: fud@ietf.org Content-Type: multipart/alternative; boundary=001a114361884d679c054c6b3ec1 Archived-At: Subject: Re: [Fud] FUD BarBOF Location X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 13:19:37 -0000 --001a114361884d679c054c6b3ec1 Content-Type: text/plain; charset=UTF-8 Hi Hannes, are some memo/meeting notes planned to be sent on the list, for those who could not attend? Thanks! Best, Emmanuel On Thu, Mar 30, 2017 at 12:25 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Btw, as mentioned before, we meet tomorrow evening at 7pm. > > On 03/30/2017 12:23 AM, Hannes Tschofenig wrote: > > Hi all, > > > > based on a suggestion from Paul Hoffmann I am suggesting to meet folks > > at the hotel bar of the "Fairmont Hotel", which is just around the > > corner of the IETF meeting venue. > > > > To make a reservation it would be great if those who are interested to > > discuss the firmware update topic please add their name to this Doodle > > poll: > > http://doodle.com/poll/bg3asdf28ruzsacq > > > > Ciao > > Hannes > > > > > > > _______________________________________________ > Fud mailing list > Fud@ietf.org > https://www.ietf.org/mailman/listinfo/fud > > --001a114361884d679c054c6b3ec1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Hannes,=C2=A0
are some memo/meeting notes planned t= o be sent on the list, for those who could not attend?
Thanks!
Best,
Emmanuel

=
On Thu, Mar 30, 2017 at 12:25 AM, Hannes Tschofe= nig <hannes.tschofenig@gmx.net> wrote:
Btw, as mentioned before, we meet tomorrow evening at = 7pm.

On 03/30/2017 12:23 AM, Hannes Tschofenig wrote:
> Hi all,
>
> based on a suggestion from Paul Hoffmann I am suggesting to meet folks=
> at the hotel bar of the "Fairmont Hotel", which is just arou= nd the
> corner of the IETF meeting venue.
>
> To make a reservation it would be great if those who are interested to=
> discuss the firmware update topic please add their name to this Doodle=
> poll:
> http://doodle.com/poll/bg3asdf28ruzsacq
>
> Ciao
> Hannes
>
>


_______________________________________________
Fud mailing list
Fud@ietf.org
https://www.ietf.org/mailman/listinfo/fud


--001a114361884d679c054c6b3ec1-- From nobody Wed Apr 5 06:31:40 2017 Return-Path: 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 9DB8012947A for ; Wed, 5 Apr 2017 06:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 VKbH-ja2_G9Q for ; Wed, 5 Apr 2017 06:31:35 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5511912947F for ; Wed, 5 Apr 2017 06:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v35DVTic007237; Wed, 5 Apr 2017 15:31:29 +0200 (CEST) Received: from client-0192.vpn.uni-bremen.de (client-0192.vpn.uni-bremen.de [134.102.107.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vymvj1kxBzDHlb; Wed, 5 Apr 2017 15:31:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Wed, 5 Apr 2017 15:31:27 +0200 Cc: fud@ietf.org X-Mao-Original-Outgoing-Id: 513091887.764489-83695cacbe3a3584831dbaf36ae6b4ad Content-Transfer-Encoding: quoted-printable Message-Id: <85D18E4E-0859-4DB0-BAE2-8D258C219893@tzi.org> References: <32221986-c3cd-60a5-0b72-5576303af3b3@gmx.net> <72189668-4154-c0f5-92a9-5fdf7c184939@gmx.net> To: Emmanuel Baccelli X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Fud] FUD BarBOF Location X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 13:31:38 -0000 I=E2=80=99m not sure that anyone kept detailed notes, but the gist of = the meeting was approximately: =E2=80=94 firmware updates for general purpose class computers (Linux = etc., =E2=80=9CA-class=E2=80=9D, OpenWRT routers, ...) are rather = different from those for microcontrollers (=E2=80=9CM-class=E2=80=9D) =E2=80=94 we should probably look specifically at the latter =E2=80=94 initial focus on complete firmware replacement (we did talk = about bootloaders vs. primary/recovery loaders etc.) =E2=80=94 the next step could be defining what set of metadata should be = provided for a such a firmware image =E2=80=94 RFC 4108 is out there but may not exactly be what is needed = for M-class today =E2=80=94 coswid (no, not the Trojan horse) might be one format to look = at Gr=C3=BC=C3=9Fe, Carsten > On Apr 5, 2017, at 15:19, Emmanuel Baccelli = wrote: >=20 > Hi Hannes,=20 > are some memo/meeting notes planned to be sent on the list, for those = who could not attend? > Thanks! > Best, > Emmanuel >=20 > On Thu, Mar 30, 2017 at 12:25 AM, Hannes Tschofenig = wrote: > Btw, as mentioned before, we meet tomorrow evening at 7pm. >=20 > On 03/30/2017 12:23 AM, Hannes Tschofenig wrote: > > Hi all, > > > > based on a suggestion from Paul Hoffmann I am suggesting to meet = folks > > at the hotel bar of the "Fairmont Hotel", which is just around the > > corner of the IETF meeting venue. > > > > To make a reservation it would be great if those who are interested = to > > discuss the firmware update topic please add their name to this = Doodle > > poll: > > http://doodle.com/poll/bg3asdf28ruzsacq > > > > Ciao > > Hannes > > > > >=20 >=20 > _______________________________________________ > Fud mailing list > Fud@ietf.org > https://www.ietf.org/mailman/listinfo/fud >=20 >=20 > _______________________________________________ > Fud mailing list > Fud@ietf.org > https://www.ietf.org/mailman/listinfo/fud From nobody Thu Apr 6 08:47:15 2017 Return-Path: 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 3D6E2126BF7 for ; Thu, 6 Apr 2017 08:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ksik5HBmE1NW for ; Thu, 6 Apr 2017 08:47:11 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE361129538 for ; Thu, 6 Apr 2017 08:46:58 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [75.98.19.134]) by relay.sandelman.ca (Postfix) with ESMTPS id 45CDF1F8F5 for ; Thu, 6 Apr 2017 15:46:57 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id CCF362918; Thu, 6 Apr 2017 10:46:54 -0500 (CDT) From: Michael Richardson To: fud@ietf.org In-reply-to: <85D18E4E-0859-4DB0-BAE2-8D258C219893@tzi.org> References: <32221986-c3cd-60a5-0b72-5576303af3b3@gmx.net> <72189668-4154-c0f5-92a9-5fdf7c184939@gmx.net> <85D18E4E-0859-4DB0-BAE2-8D258C219893@tzi.org> Comments: In-reply-to Carsten Bormann message dated "Wed, 05 Apr 2017 15:31:27 +0200." 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-sha1; protocol="application/pgp-signature" Date: Thu, 06 Apr 2017 11:46:54 -0400 Message-ID: <23163.1491493614@dooku.sandelman.ca> Archived-At: Subject: Re: [Fud] FUD BarBOF Location X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 15:47:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > =E2=80=94 firmware updates for general purpose class computers (Linux= etc., > =E2=80=9CA-class=E2=80=9D, OpenWRT routers, ...) are rather different= from those for > microcontrollers (=E2=80=9CM-class=E2=80=9D) well, Hannes kept saying that, and a number of us kept saying that in fact it wasn't true. Writing a 1GB image onto a 1.1GB NAND boot partition could be as difficult to get right as writing a 31K image into a 32K NAND partition. The only difference being what you can fit in the "extra" space. (100M of bootloader space vs 1K of bootloader space...) OpenWRT routers and Smartphone updates are very much closer to M-class than they are to "Linux" desktops. It's a signed blob, and often there isn't spa= ce to double buffer it at all. If it is useful for me to write up my minimal (D)TLS receiver concept for firmware updates, I will do that. > =E2=80=94 we should probably look specifically at the latter Agreed. > =E2=80=94 initial focus on complete firmware replacement (we did talk= about > bootloaders vs. primary/recovery loaders etc.) > =E2=80=94 the next step could be defining what set of metadata should= be > provided for a such a firmware image > =E2=80=94 RFC 4108 is out there but may not exactly be what is needed= for M-class today > =E2=80=94 coswid (no, not the Trojan horse) might be one format to lo= ok at I think that we should consider updates to 4108. If we don't like 4108, then we should consider a non-ASN1, non-PKIX format format (JOSE for instance). =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJY5mLuAAoJEJVM4Vb9/EKQCJgH/A6wNAMfZL+BjYuJtFfEN5iE Vm7/Zz0rFM9X7yg1EOtS3kNfr8px1r5bBh1dUm3NNQ84IRuybXjgK+AjhROqTNoE PN47lonzXxwh8I3mafGz3ep8ipumNJ/SZ6c/rS0RTjC8BNsFluZY/8n2dse+eNx+ 8f+1NlysFXijZWFuQs7Kxcgba+wkm/Avm2xqSrpcatVPdcul0IgCcEGan1WqLi8i JJbO74eTSI4yuN9F/Dp4J1BMLXoYz+1BlcNPl4lhGx6k0SYATV40+hckZeUUFDa0 4TPjg7Ywck403mMPy2AlcXlVeybMPCuDFE/UNYpAFDzXuHSDuYkmFNPeQ5F89G0= =zpKn -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 6 13:30:19 2017 Return-Path: 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 4F4311294A4 for ; Thu, 6 Apr 2017 13:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 AvomZNGK9-JI for ; Thu, 6 Apr 2017 13:30:16 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F08A128954 for ; Thu, 6 Apr 2017 13:30:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 78BBC300445 for ; Thu, 6 Apr 2017 16:30:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 63k5j1dNMRVv for ; Thu, 6 Apr 2017 16:30:14 -0400 (EDT) Received: from new-host-4.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id AF22A300261 for ; Thu, 6 Apr 2017 16:30:14 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 6 Apr 2017 16:30:14 -0400 References: <32221986-c3cd-60a5-0b72-5576303af3b3@gmx.net> <72189668-4154-c0f5-92a9-5fdf7c184939@gmx.net> <85D18E4E-0859-4DB0-BAE2-8D258C219893@tzi.org> <23163.1491493614@dooku.sandelman.ca> To: fud@ietf.org In-Reply-To: <23163.1491493614@dooku.sandelman.ca> Message-Id: <5354D811-DCA2-489D-AFF4-027C5EB999A5@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Fud] FUD BarBOF Location X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 20:30:18 -0000 >> =E2=80=94 the next step could be defining what set of metadata should = be >> provided for a such a firmware image >> =E2=80=94 RFC 4108 is out there but may not exactly be what is needed = for M-class today >> =E2=80=94 coswid (no, not the Trojan horse) might be one format to = look at >=20 > I think that we should consider updates to 4108. > If we don't like 4108, then we should consider a non-ASN1, non-PKIX = format > format (JOSE for instance). If people want to update RFC 4108, I=E2=80=99m willing to help. I have = worked with some people to decode the necessary parts with very simple = code. It does not require a compiler. The vital thing is that the = signature gets checked! Russ From nobody Sun Apr 16 10:07:23 2017 Return-Path: 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 55883127775 for ; Sun, 16 Apr 2017 10:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 pofQzn6lDyTg for ; Sun, 16 Apr 2017 10:07:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84303126C22 for ; Sun, 16 Apr 2017 10:07:20 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A26702009E for ; Sun, 16 Apr 2017 13:32:15 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3DCBF636BB for ; Sun, 16 Apr 2017 13:07:18 -0400 (EDT) From: Michael Richardson To: fud@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Fud] documents and minutes X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 17:07:22 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 1) I don't think this list got the initial welcome message with pointers to the various drafts from Hannes that form some of the basis for his probl= em statement. Could the links be posted for the benefit of the archives? I searched the ID repo using: 'fud' and also 'tschofenig', but didn't fi= nd anything. I thought that were some documents. 2) Carsten wrote these minutes: > =E2=80=94 firmware updates for general purpose class computers (Linux etc= ., > =E2=80=9CA-class=E2=80=9D, OpenWRT routers, ...) are rather different fro= m those for > microcontrollers (=E2=80=9CM-class=E2=80=9D) .. > =E2=80=94 initial focus on complete firmware replacement (we did talk abo= ut > bootloaders vs. primary/recovery loaders etc.) I wanted to take issue with the way this distinction is being presented. While there are plenty of Linux based systems that do updates via packages, and systems like OpenWRT/LEDE and Android that can load some optional components via packages (opkg and apk), many of these systems do their primary upgrades via complete firmware replacements. It's not about "M-class" vs "A-class" (some very ARM specific terminology),= at all. The only difference between an RPI-IoT device running Android and an ATmega running Ardiuno or Freescale or OpenMote device running Contiki is the numb= er of megabytes the image is. The large image devices actually have more of a challenge because they usually can not double-buffer the image, so they have more in common with the very small devices, with the "M-class" device actually being richer than then the smaller devices. The saving grace is that usually have a generous amount of space for a recover/bootloader image so that failure to apply an image does not result = in a bricked device. {I will note that most of the baby-monitor/video cameras which were involved in the DDoS, while they might use a Linux kernel, usually have only one or two core processes that do all the work. They are upgraded by complete firmware replacement, and usually do not support packages in any form.} =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljzpMUACgkQgItw+93Q 3WVcVQgAgvzYjDZHU21FQmP+VEHwgfa0EXyaHxpnWATGwO8quG70kCzAQ+eTxOTM wIEE6spET4IVYs0oa+ScJPXQVcr9yYIN+vKyVlh1tw79gB++4VOhIaK9JHCwhcX+ QdsiHvJRb16YHThlwDSvYrqEAsCTnFKrC+qv1IMXCU/eM9/+/8McUfZxPQpyPjta sxLs9PdBy+y80rhdUsz24maicCTyXKkTJnKbrbokZZBFBMtI+h10kzhXQK3agRwl O/t+fUEc6nTtTUsh1Izc2D7y1rxsaThFNb5f0Q6Fh++gwt5mRZ6V82byFHwHgE9n lqNltjEmEqzWMLLql3AqJnvm2fJk8Q== =Quum -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Apr 16 13:34:32 2017 Return-Path: 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 771D01292AE for ; Sun, 16 Apr 2017 13:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 lHZ2QrzM383I for ; Sun, 16 Apr 2017 13:34:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E896128DF6 for ; Sun, 16 Apr 2017 13:34:29 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DA80C20569 for ; Sun, 16 Apr 2017 16:59:25 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0CE99636BB for ; Sun, 16 Apr 2017 16:34:28 -0400 (EDT) From: Michael Richardson to: fud@ietf.org X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Fud] Constrained Firmware update challenge X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 20:34:31 -0000 --=-=-= Content-Type: text/plain In the BarBOF I tried to explain my belief that there is a place for in-place (not double/triple buffered) firmware update, via some kind of setup-process followed by a very constrained CoAP/DTLS/OSCOAP Block Transfer mechanism that a recovery bootloader could run. I imagine pretty much *all* the protocol mechanism being cached.. (ND, IPv6 addresses, DTLS setup, etc.) So I wrote up my challenge, and my straw-man concept of a solution. Please disagree with me... preferably by sending text (or pull requests): https://datatracker.ietf.org/doc/draft-richardson-fud-constrained-update/ https://github.com/mcr/fud-constrained-update Ignore my strawman, or perhaps, provide your own. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljz1VMACgkQgItw+93Q 3WWOJQf/ei37gBLMKQiFw+JGeTulPUBNNMRR4+RBSj6kefFWxUJgWYpHbflc1/FW gE3OKKK6OJ5qQl6+FeP6a86/cxZnXn3YFeTqCGHOjgi6B2H/ku08FKX3kXsq0Mzf /FmzzaKyRcLyYCr0euT0pKVxSlP5UqQ/0h412tOC7LFA1rPCO4Ra+FT5lfEyupIv fW0ll0Pg0e+KfXgrLOLGxR0Z/mhgjZXe4XuGLZD/OPPYhaxaHiPK2ALBJ2x+YnMZ ZCnlrSooOjyaZBk6+/tI2l455gEKUnAvb5RrJerGMDaklQNI7tn9t53PRYvTr+MC 8bFZsC7dIaDBKiFt9sJImLzmoJTNFQ== =YM/5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 17 00:36:12 2017 Return-Path: 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 73E7C128B44 for ; Mon, 17 Apr 2017 00:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Vh6tGysR-0ZW for ; Mon, 17 Apr 2017 00:36:08 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC96124C27 for ; Mon, 17 Apr 2017 00:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3H7a3RE000564; Mon, 17 Apr 2017 09:36:03 +0200 (CEST) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w60S31DFxzDHQw; Mon, 17 Apr 2017 09:36:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <1980.1492374868@obiwan.sandelman.ca> Date: Mon, 17 Apr 2017 09:36:02 +0200 Cc: fud@ietf.org X-Mao-Original-Outgoing-Id: 514107362.440925-6f6e54d81b2ef9f2a0f5f9f3ded8785c Content-Transfer-Encoding: quoted-printable Message-Id: References: <1980.1492374868@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Fud] Constrained Firmware update challenge X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 07:36:10 -0000 How do you update that bootloader (which now contains the majority of = the code on the device, by the way)? Gr=C3=BC=C3=9Fe, Carsten > On Apr 16, 2017, at 22:34, Michael Richardson = wrote: >=20 >=20 > In the BarBOF I tried to explain my belief that there is a place for = in-place > (not double/triple buffered) firmware update, via some kind of = setup-process > followed by a very constrained CoAP/DTLS/OSCOAP Block Transfer = mechanism that > a recovery bootloader could run. I imagine pretty much *all* the = protocol > mechanism being cached.. (ND, IPv6 addresses, DTLS setup, etc.) >=20 > So I wrote up my challenge, and my straw-man concept of a solution. >=20 > Please disagree with me... preferably by sending text (or pull = requests): > = https://datatracker.ietf.org/doc/draft-richardson-fud-constrained-update/ > https://github.com/mcr/fud-constrained-update >=20 > Ignore my strawman, or perhaps, provide your own. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Fud mailing list > Fud@ietf.org > https://www.ietf.org/mailman/listinfo/fud From nobody Mon Apr 17 08:26:26 2017 Return-Path: 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 364CA131443 for ; Mon, 17 Apr 2017 08:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 dSKDg7xvysDe for ; Mon, 17 Apr 2017 08:26:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93BA2130140 for ; Mon, 17 Apr 2017 08:26:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C77252009E; Mon, 17 Apr 2017 11:51:21 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3CE00636BB; Mon, 17 Apr 2017 11:26:21 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: fud@ietf.org In-Reply-To: References: <1980.1492374868@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Fud] Constrained Firmware update challenge X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 15:26:24 -0000 --=-=-= Content-Type: text/plain Carsten Bormann wrote: > How do you update that bootloader (which now contains the majority of > the code on the device, by the way)? I think that it may be possible to significantly simply that code path such that it does not have so much code. Updates may be impossible (burnt into ROM), or it might just be a special part of the flash that is seperate from the main code. Things I would expect to leave out would include: - L2 neighbour cache and L3 routing - fragment creation (just re-assembly) - neighbor discovery - RPL - DTLS and/or OSCOAP setup. - authorization: public key handling, certs if used, ACE tokens, DH - interrupts (everything polled I/O) This is part of my postulate, and perhaps you will reasonably disagree with the assumption that this can be done. I believe that the code would be seperate from the normal code. Done wrong it could contain the majority of the code, but done well, I think it would be perhaps 20%. Effectively, we no longer double buffer the entire system, just the totally minimal code required to load new code. It could alternatively be that the bootloader code is used as a kind of "BIOS" via subroutines. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlj03pwACgkQgItw+93Q 3WVnpQf/VhCNM/M04RbRoA6ffE9mxn7qQDlL0fPNAdYnq700nXBUZJDcBoRTIocI dQfFkVMx0MdQ6mfTkn9aVKBzFS76vYxMYZB/7YsT8rOevplffo6SUlxuF5Rd/WnA ALmRAI3i5itj6s72ufaeiHsNfSapapxt7hR7+FqKbi0beW+x41srkUrQyYQoUZai q9TADhpwdPrXHDxn+9WnudbL1y6RJ3wD+/oCLqnmThG+3g4FUpkyA5PT3JWqxcB/ dovpMAQ3pSRcPh1iddEUCxR6eil5G+D4qZU6wRShfQXku4tcRenL3WskSRFDIKBB 4xmQRao60CXKHJb0TsCZwY0abYxLHg== =WxvW -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 17 10:01:55 2017 Return-Path: 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 15CDA126C2F for ; Mon, 17 Apr 2017 10:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 NyXQhhAs-jU7 for ; Mon, 17 Apr 2017 10:01:52 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78F213169E for ; Mon, 17 Apr 2017 10:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3HH1g0C022983; Mon, 17 Apr 2017 19:01:42 +0200 (CEST) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w6F0k0TXqzDHWV; Mon, 17 Apr 2017 19:01:42 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <3324.1492442781@obiwan.sandelman.ca> Date: Mon, 17 Apr 2017 19:01:41 +0200 Cc: fud@ietf.org X-Mao-Original-Outgoing-Id: 514141300.931397-7845dd6e1d9743e681bfd8a5ebd8c900 Content-Transfer-Encoding: quoted-printable Message-Id: <8F5AB023-888C-49E2-B857-5CB65EACA261@tzi.org> References: <1980.1492374868@obiwan.sandelman.ca> <3324.1492442781@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Fud] Constrained Firmware update challenge X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 17:01:54 -0000 > On Apr 17, 2017, at 17:26, Michael Richardson = wrote: >=20 > Updates may be impossible > (burnt into ROM), Too much code for my taste (and much of this is security relevant, so it = probably needs updates at some point). > or it might just be a special part of the flash that > is seperate from the main code. More likely, and more likely that you=E2=80=99d keep two copies of that, = so you can upgrade the bootloader itself. (Needs jump tables if that massive amount of code also needs to be = reused by the application.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 18 10:36:29 2017 Return-Path: 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 8F1A312EBE2 for ; Tue, 18 Apr 2017 10:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 7x4hGK5oni9o for ; Tue, 18 Apr 2017 10:36:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52CD1293DB for ; Tue, 18 Apr 2017 10:36:25 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 08E8EE1A3; Tue, 18 Apr 2017 14:01:29 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BA6FC636BB; Tue, 18 Apr 2017 13:36:24 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: fud@ietf.org In-Reply-To: <8F5AB023-888C-49E2-B857-5CB65EACA261@tzi.org> References: <1980.1492374868@obiwan.sandelman.ca> <3324.1492442781@obiwan.sandelman.ca> <8F5AB023-888C-49E2-B857-5CB65EACA261@tzi.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Fud] Constrained Firmware update challenge X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 17:36:28 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >> Updates may be impossible (burnt into ROM), > Too much code for my taste (and much of this is security relevant, so > it probably needs updates at some point). I agree it's better if we can update it. I'm just looking at what resources might be under-exploited. >> or it might just be a special part of the flash that is seperate from >> the main code. > More likely, and more likely that you=E2=80=99d keep two copies of th= at, so you > can upgrade the bootloader itself. (Needs jump tables if that massive > amount of code also needs to be reused by the application.) Yes, agreed. The question is: do you agree with the postulates 1) that product managers will paint themselves into corners where they can not double-buffer. 2) that there is any role for the IETF. [I come to this problem first hand... having to drag my laptop out to JTAG a Redwire econotag. No space for double buffering, but at least 30K of code space still free... No I didn't solve the problem, I have no proof of conce= pt yet. Or to make the point differently: not having space for double buffering, I can not even consider any kind of online firmware update] =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlj2TpgACgkQgItw+93Q 3WVsKAf6AuiXHHu+v135sX1uOC3rPbSw6S7vsImp4AaZ6M8MRqCvuCLXnld7Ryx1 4Zzqbgm2JH7vo5/pqxnFbmlIJJNto5N7JIGIJR1HJ6oS2xx6bdihXJrKJp0ECOee F3rKm9lqURrRkGRJm+Iun84zICNYQ1X+EmkpVn9h9Ou3QFYR5cEMinZrgp0XHgtb FpoTgIrZj+09axF1IN4owpyva5jSAc437too3NVWrv+pqzVNj1FPK1KvsBOIjV0m LI9LqZcnrKThRM3pkovD6r9/UTZwVqcTNATW7dIKdHodNumNSt3mZ2i5+Tcyw11s lHXu+CEe3AfaINXsxggHr2pP4OUH9A== =5M7/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 19 14:24:54 2017 Return-Path: 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 745DA12E852 for ; Wed, 19 Apr 2017 14:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 6J3Pd1XLdSWL for ; Wed, 19 Apr 2017 14:24:51 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 2EC28129C6B for ; Wed, 19 Apr 2017 14:24:51 -0700 (PDT) Received: from [192.168.254.146] (72-172-185-194.bayarea.net [72.172.185.194]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v3JLOj2Y014129 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Apr 2017 14:24:48 -0700 To: Michael Richardson , fud@ietf.org References: <18203.1492362438@obiwan.sandelman.ca> From: Erik Nordmark Message-ID: <81f70fb8-1ed7-6e86-4c7b-d4ab20ae8d47@sonic.net> Date: Wed, 19 Apr 2017 14:24:45 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <18203.1492362438@obiwan.sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZaM7MwsO+47R7xCwT6KZ1hte2vErU9UJ9811y9CjqwR1GvtA1mS32SOUO+7QSsQicU45jBxNqQDQVcLWKG1L/18wenFCtStF8= X-Sonic-ID: C;duxRnEYl5xG2GyzL7bdh1w== M;VjLVnUYl5xG2GyzL7bdh1w== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Subject: Re: [Fud] documents and minutes X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 21:24:52 -0000 On 04/16/2017 10:07 AM, Michael Richardson wrote: > > I wanted to take issue with the way this distinction is being presented. > While there are plenty of Linux based systems that do updates via packages, > and systems like OpenWRT/LEDE and Android that can load some optional > components via packages (opkg and apk), many of these systems do their > primary upgrades via complete firmware replacements. > > It's not about "M-class" vs "A-class" (some very ARM specific terminology), at all. Agreed. > > The only difference between an RPI-IoT device running Android and an ATmega > running Ardiuno or Freescale or OpenMote device running Contiki is the number > of megabytes the image is. The large image devices actually have more of a > challenge because they usually can not double-buffer the image, so they have > more in common with the very small devices, with the "M-class" device > actually being richer than then the smaller devices. I think there is a distinction between devices which have an MMU (memory management unit) vs. not which can have some impact on software update. A device with an MMU can more easily put together different pieces of software using virtual memory. A device without an MMU either has to replace the whole firmware, or do additional work should one upgraded piece grow in size. (I the bar the observation was that one can use position independent code and move some code around to make room, or leave dead space in the image to allow for some growth.) It would be nice to have an image format which could allow for those differences when allowing for updating only the pieces which change from one version to another. Erik