Hi,
yesterday in the IAB technical plenary, Hannes Tschofening stressed the need for system software maintenance. This raises the question: Have we spent enough thoughts on automated secure software updates for RIOT, are we approaching this subject?
It might be some thing worth while considering??
Cheers, Thomas
Hi Thomas,
there are some initial efforts on-going in the community, such as [1] [2] [3], and upcoming GSOC projects on implementing LWM2M amd dynamic linking.
However, this is not sufficient to get the whole nine yards. To have the full picture, there lacks security/crypto aspects, software updates (rrlated but different from firmware updates) and the automatic aspect, which also include a network/transport/distribution aspect.
So in a nutshell: I think this aspect is of utmost importance indeed. Having a really good way to do that could be a decisive advantage of RIOT over other OS. In any case: the IoT will only become the IoT the day such evolutive mechanisms are in place and usable.
I was thinking that this could/should be the main focus of RIOT in upcoming H2020 project proposals for instance.
best,
Emmanuel
[1] https://lists.riot-os.org/pipermail/devel/attachments/20150211/7e2772a3/attachment-0001.pdf [2] https://github.com/RIOT-OS/RIOT/wiki/minutes-OTA-meetup-13.2.2015 [3] https://lists.stillroot.org/pipermail/devel/2015-January/001738.html
Hello,
Indeed, that presentation was rather interesting. and secure updates indeed as part of security;
Looking at the OTA, the discussions are "excluding network protocol", so maybe one step in that direction would be to have some secure protocol for sending them ?
Is there something already envisionned ?
best regards, -- Cedric
Hi,
I see the upgrade distribution process as mostly independent from the software infrastructure needed to activate new images. Also, there are probably several ways to do this right (depending on the requirements, environment, ...), so there will be no single best distribution model. In this sense: Knock yourselves out and create working groups for your respective favorite protocols!
Cheers, Ludwig
Cédric Adjih schrieb:
Hi!
I see the upgrade distribution process as mostly independent from the software infrastructure needed to activate new images.
Do I get this right, that the OTA task force is excluding the OTA part of the software update from their work? Or are you just considering the single hop case?
Cheers, Oleg
Hi,
yes, we agreed that in order to get software updates we need a foundation for activating new firmware images first. The working assumption for the first incarnation/iteration of this is that an image has been saved to some memory of the device already.
Cheers, Ludwig
Oleg Hahm schrieb:
Hi Ludwig!
yes, we agreed that in order to get software updates we need a foundation for activating new firmware images first. The working assumption for the first incarnation/iteration of this is that an image has been saved to some memory of the device already.
Okay, basically my question was: do the OTA task force wants to work on the actual update distribution mechanisms (including security) in a second step or would it make more sense trying to charter a task force that works on this in parallel? (If the latter, I would recommend to rename it.)
Cheers, Oleg
Hi,
Yes, I think (and wrote in a separate mail in this thread already): working groups for different distribution implementations should be created by people who are interested in those. If it helps preventing confusion I'm happy with renaming the first iteration to whatever you suggest, or "OTA/FAF" (firmware activation framework).
Cheers, Ludwig