31–40 of 48 posts
Neat :)! In case the Mender folks are here, have you looked into incorporating the concerns addressed bt The Update Framework (TUF) https://theupdateframework.github.io/
Neat :)! In case the Mender folks are here, have you looked into incorporating the concerns addressed bt The Update Framework (TUF) https://theupdateframework.github.io/
Why? TUF is all about reimplementing SSL and PKI. Since mender can use regular SSL with good-old PKIs, there is no reason to go with weird solutions.
Earlier quoted context omitted.
Interesting! How did you go about falling back to an older version if the update was bad? Is there a nice way to do this automatically? Say I update to a really botched version with the kernel panicing before it reaches userland. Does this need manual intervention?
disclaimer: I work for Mender It is possible to make rollback fully automatic. In order to do so you need some integration with bootloader. It needs to be configured so that it can roll back to the previously working partition if update is broken. What is more, you can add some user space runtime checks that can verify the update and if those are not passing (updated image is broken) you can rollback to the previous…
In my case, the first thing I do once an unverified version boots is to switch back to the other partition (so the known good version is active during the next boot), then run a detached reboot process that forces a reboot in 5 minutes. Once the system is up and it verified that everything is ok, it commits the next version (by switching back to the partition that booted and marking it as confirmed) so it is now active by default. Finally it kills the still running 'reboot' process.
As far as I understand your update process: You download a complete new version for every update and are able to stream that directly to the new partition? Is there any way to do delta updates? In my experience, most of the disk content is unchanged, unless you do major updates. In my case I download the new version using zsync, verify the downloaded/updated `install.zip` (which is kept on the volatile data partition), then extract that to the new partition. I make sure that `install.zip` is created in a way that it is rsyncable, so updates are pretty small that way. Of course you lose the streaming feature, unless you modify zsync somehow to support that.
Can someone summarize the difference between Mender and OSTree? I see that QtOTA chose OSTree as their underlying mechanism, which is significant in embedded automotive industry.
From my perspective as a curious observer of both projects, OSTree certainly looks attractive, because it doesn't waste space on two rootfs partitions which have to be oversized to accommodate future growth of the image. I initially thought OSTree required btrfs, because Project Atomic used btrfs the last time I looked at it. But according to the docs, while OSTree will take advantage of btrfs features if btrfs is be…
Neat :)! In case the Mender folks are here, have you looked into incorporating the concerns addressed bt The Update Framework (TUF) https://theupdateframework.github.io/
Yes, we have looked into it and the nice thing is that TUF seems to be quite easy to add as an additional security layer down the road.
One interesting challenge is downgrade attacks. How do you allow rollback of a bad deployment while disallowing an attacker to deploy an old and vulnerable version?
Earlier quoted context omitted.
I'm kind of in this boat now with a couple of products. The catch is I need to do both local and OTA updates. This seems to be a rare feature that nobody is doing. I also am trying to get Resin.io like containers working. It seems like it would be an easier way to test and deploy.
That's also a requirement for me - local updates (via connected USB stick, triggered via reboot or web interface) should work also in addition to OTA. _In fact local updates would have an even higher priority. We fiddled around also a little bit with the container route. I liked it for quick iteration times (rebuild a docker container, pull it from local image registry to device and test it there). But we found out t…
Like you, many teams are still doing local updates, or transitioning from local to OTA, at least for some products.
[0] https://docs.mender.io/1.0/Architecture/Overview#modes-of-op...
Earlier quoted context omitted.
Why? TUF is all about reimplementing SSL and PKI. Since mender can use regular SSL with good-old PKIs, there is no reason to go with weird solutions.
TUF protects against more attacks than just HTTPS or regular trivial signing methods do (rollback attacks, freezes, mix and match attacks, and helps secure mirrors), and has little to do with HTTPS or raw "transport layer encryption". It absolutely compliments and suppliments HTTPS if you're using it for your downloads, it is not obsoleted by it. (Though, the subtext on the introduction page probably doesn't help thi…
- rollback attacks -- impossible since all comms are secure, and there are no untrusted mirrors
- freezes -- impossible, because SSL channel must be re-negotiated every time
- mix and match attacks -- nothing to mix+match, mender only does one file (rootfs)
- helps secure mirrors -- mender does not support 3rd party mirrors, so no need to secure them.
You can see it right on the TUF homepage: it claims to replace application, library package and system package managers. This is a lot of work, which requires a lot of complexity, and there is no need at all to pay that price if you do not need to.
Can someone summarize the difference between Mender and OSTree? I see that QtOTA chose OSTree as their underlying mechanism, which is significant in embedded automotive industry.
Yocto layer: https://github.com/advancedtelematic/meta-updater Quickstart project with a nice tutorial: https://github.com/advancedtelematic/garage-quickstart-rpi
And yes, we have chosen it because you don't have to waste twice as much disk space, and, more importantly (for wireless networks at least), you don't have to download the whole image.
Earlier quoted context omitted.
disclaimer: I work for Mender It is possible to make rollback fully automatic. In order to do so you need some integration with bootloader. It needs to be configured so that it can roll back to the previously working partition if update is broken. What is more, you can add some user space runtime checks that can verify the update and if those are not passing (updated image is broken) you can rollback to the previous…
As someone that also implemented A/B booting for the Pi: I wonder how you roll back fully automated? I read a bit of the code but wasn't able to find that. Or is that already handled by u-boot? In my case, the first thing I do once an unverified version boots is to switch back to the other partition (so the known good version is active during the next boot), then run a detached reboot process that forces a reboot in…
The update is written to the inactive rootfs partition, uboot is configured to boot from it and the device is rebooted. Using the bootcount feature of uboot it is possible to roll back automatically if booting fails. Once the mender daemon comes up it will try to report the success of the deployment to the server. If this fails it will also roll back. Only after successfully reporting the success to the server Mender will "commit" the update, meaning configuring uboot to persistently boot from this updated partition.
Mender already does compression, but you are right that there are optimizations that can be made for application updates, e.g. delta or other types of updates. We are planning to implement this as well. The first priority for Mender is to make it robust, i.e. make sure the update is atomic and that you can always roll back.
Can someone summarize the difference between Mender and OSTree? I see that QtOTA chose OSTree as their underlying mechanism, which is significant in embedded automotive industry.
OSTree seems to rely on underlying filesystem to provide protection from power failures. This is, in my experience, is not a very reliable mechanism, especially when the SD cards are used. Thus, it is likely that if you have a device using OSTree updater and someone yanks the power cord at the bad time, your device may become unbootable.