Live data from Hacker News

Software Updates for IoT Devices and the Hidden Costs of Homegrown Updaters [pdf]

mender.io

1–10 of 41 posts

Re: Software Updates for IoT Devices and the Hidden Costs of Homegrown Updaters [pdf]

#3
post #2

This is wonderfully timed, I’m currently looking for options when it comes to doing firmware updates on Linux based IoT devices. Does anyone have any recommendations?

The source of this article is Mender.io, which is an open source embedded linux distro that includes built-in OTA updates:

http://mender.io/

I can't speak to their quality as I haven't tried it yet. I have used Resin.io quite a bit and it's great if it fits your use case (and the pricing model makes sense for you).

Re: Software Updates for IoT Devices and the Hidden Costs of Homegrown Updaters [pdf]

#4
post #2

This is wonderfully timed, I’m currently looking for options when it comes to doing firmware updates on Linux based IoT devices. Does anyone have any recommendations?

A friend who is building an Linux appliance is using Yocto: https://www.yoctoproject.org/. He also talked about Mender, mentioned in the other comment. I don't know how much overlap there is between these projects.

Re: Software Updates for IoT Devices and the Hidden Costs of Homegrown Updaters [pdf]

#5
post #2

This is wonderfully timed, I’m currently looking for options when it comes to doing firmware updates on Linux based IoT devices. Does anyone have any recommendations?

Since Mender and Yocto have already been mentioned, I have to bring up Buildroot with SWupdate. Batteries aren't included like with Mender, but you also don't have to assemble layers from the far reaches of the internet like Yocto.

Re: Software Updates for IoT Devices and the Hidden Costs of Homegrown Updaters [pdf]

#6
This is FUD.

Partition twice the amount of space you need on IOT's fixed media, and trickle-download your update to the empty partition. Once that's finished, verify the download then switch your bootloader. I have to update 500+ field installations with a new OS and this is the approach I'd take if we had the space and bandwidth

(Instead we're sending out an army of techs and account reps armed with USB sticks)

Re: Software Updates for IoT Devices and the Hidden Costs of Homegrown Updaters [pdf]

#7
post #2

This is wonderfully timed, I’m currently looking for options when it comes to doing firmware updates on Linux based IoT devices. Does anyone have any recommendations?

I occasionally contribute to a fairly large home automation project named Home Assistant (https://home-assistant.io/)

They have an all in one operating system perconfigured for a raspberry pi or intel nuc dubbed "hass.io" that uses ResinOS under the covers:

https://home-assistant.io/hassio/

https://resinos.io/

Under the covers, ResinOS is a minimal Yocto embedded linux + docker + some ota stuff. Consider looking into that before building your own.

Re: Software Updates for IoT Devices and the Hidden Costs of Homegrown Updaters [pdf]

#8
It's not a full OTA solution, but fwup (https://github.com/fhunleth/fwup) handles the packaging and application of Linux firmware update images quite well. Apache licensed, supports A/B updates (see tomc1985's comment), Ed25519 digital signature verification, and u-boot support.

Re: Software Updates for IoT Devices and the Hidden Costs of Homegrown Updaters [pdf]

#9
post #6

This is FUD. Partition twice the amount of space you need on IOT's fixed media, and trickle-download your update to the empty partition. Once that's finished, verify the download then switch your bootloader. I have to update 500+ field installations with a new OS and this is the approach I'd take if we had the space and bandwidth (Instead we're sending out an army of techs and account reps armed with USB sticks)

I'm not sure what part you're referring to as FUD - the cost?

I definitely agree with the rest of the comment. It's a good solution. I inherited a software product that worked like this at a past job, and it was great. (And now I'm trying to convince my current job that we want to move to this model for normal servers in datacenters, very much not IoT.)

A couple of complications:

- You should think about the fact that this means your root partition changes. Either you want to structure your system with separate read and write partitions and bind-mount the relevant directories from the write partition, or you want to make it completely read-only / stateless. Remember that /var/log is traditionally on your local disk, so if you don't do anything special, you'll even get two /var/logs on each device, which may or may not be what you want.

- You do want a management server, as this document suggests, to track which devices have actually updated and which haven't, so you can manually send people after devices that are just behind a terrible internet connection.

- You want some mechanism for detecting if the new version doesn't work and rolling back; this is basically as simple as setting a "I just tried partition X, if it doesn't work don't try it again" flag in the bootloader on boot, and clearing it once userspace is up (and when the partition gets rewritten with a new version).

- The updates should be signed etc. as described in the document. Depending on your threat model, you might want to prevent replay attacks that cause an attacker-controlled downgrade by giving it a higher-versioned filename; either use HTTPS to an update server you control, or use signed metadata files with timestamps.

The fact that you get image-based deployments instead of dealing with apt upgrades from arbitrarily-old versions (and thus inevitably slightly drifting configs on devices installed at different times) is fantastic.

Re: Software Updates for IoT Devices and the Hidden Costs of Homegrown Updaters [pdf]

#10
post #9
post #6

This is FUD. Partition twice the amount of space you need on IOT's fixed media, and trickle-download your update to the empty partition. Once that's finished, verify the download then switch your bootloader. I have to update 500+ field installations with a new OS and this is the approach I'd take if we had the space and bandwidth (Instead we're sending out an army of techs and account reps armed with USB sticks)

I'm not sure what part you're referring to as FUD - the cost? I definitely agree with the rest of the comment. It's a good solution. I inherited a software product that worked like this at a past job, and it was great. (And now I'm trying to convince my current job that we want to move to this model for normal servers in datacenters, very much not IoT.) A couple of complications: - You should think about the fact tha…

How do you handle key and/or certificate storage at the client side? Depending on the threat model, the update verification step can be subverted.
Post reply on HN