Embedded developers need an open source OTA software updater without the lock-in

Frankly I'm not sure one can link the Cherokee hack to lack of a secure remote update mechanism. Of course signed images and secure updates are key elements of a secure embedded system. But the fatal flaw was IMHO a very unfortunate decision to route their IPC (DBUS) over IP with no authentication. A system is only as strong as the weakest link!

[1] Excellent white paper link from authors of the Cherokee Hack: http://illmatics.com/Remote%20Car%20Hacking.pdf#page=20

Tried resin.io and while it had good ideas, it was difficult to integrate. It is also completely dependent on their hosted management system. Which can be good, but is another hurdle to get past. Mostly because we would have started at greater than 25 devices and would have rapidly hit 200. So its hard to get our owner behind that up front.

Mender has been much easier to get going. Its dependencies are far less and without the docker containers easier to get going initially. Docker I think will have its day, but host<->container configuration for peripherals is kind of clunky.

Also Mender can be self hosted so that makes it far less friction for me to get going with.

[0] https://uptane.github.io/

For myself, I'm comfortable with some form of A/B partition update (assuming the problem of distribution and verification is solved elsewhere) however at the very least you still have to patch or script u-boot (or your bootloader of choice) to make it smart enough to try booting the primary partition and also have some sort of canary file it can check on the next boot to validate that the partition booted successfully and e.g. made it all the way to the target runlevel. And if that check fails fall back to the secondary partition or some recovery image.

Embedded firmware updates - especially for M2M devices that are not necessarily user-facing - are sort of like changing the engine of your car while driving down the highway. It's a very tricky thing to get right. Plus if something goes wrong, it's not like you can just SSH into your server or kill that cloud instance and start a new one :)

[1] https://github.com/fhunleth/fwup [2] https://snapcraft.io/

Anyone know more precisely what he's talking about? The article doesn't specify.

>> The V850 controller software was built to only listen to the CAN bus and not write commands to it.

If the hardware was intently designed for sniff only, you'd think a simple uni-directional buffer between the V850 and CAN bus would have mitigated this risk in one fell swoop. Maybe it's hinde sight bias, but directly interfacing a complex, OTA-enabled embedded accessory to a bus used for safety-critical control sounds about as sensible as strapping a Raspberry Pi to a flight control computer's 1553 bus and thinking it's all gravy because the former's software is designed to "only listen".

That being said, I understood from a former Delphi engineer who designed engine control modules that there's a pretty strict and expensive approval process for electronics in the automobile industry, and reliability predictions are taken quite seriously. I suspect even if an engineer were to design in a true read-only interface, it'd probably get nerfed during design review as a consequence of lacking traceability to a hard requirement.

I really hope the project gets more attention. Not only was the firmware update system nice, but having the promis of having the core OS managed and only having to worry about your application was nice as well.

http://cloud2.opensystemsmedia.com/share/images/pulse.gif

that'd be pretty sweet to have, and it would potentially be a multi-hundred million dollar company.