5 ms·

Can someone summarize the difference between Mender and OSTree? I see that QtOTA chose OSTree as their underlying mechanism, which is significant in embedded au

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.

mwcampbell 10y ago
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 being used, OSTree itself will work with a variety of filesystems including ext4. Edit: An upside of the alternating rootfs partition approach is that the rootfs can be cryptographically verified at the block level. Chromium OS implemented this, and CoreOS also uses that implementation. This is probably outside the scope of Mender itself, but the updating approach used by Mender enables it.
- eystein 10y ago
  Cryptographic signing and verification is in scope for Mender [0], and frankly it should be in scope for all updaters -- too many hacks have happened due to lack of codesigning. [0] https://tracker.mender.io/projects/MEN/issues/MEN-1020 https://tracker.mender.io/projects/MEN/issues/MEN-1020
oytis 10y ago
If you are interested in OSTree, there is an open-source solution for OSTree updates on embedded devices. Yocto layer: https://github.com/advancedtelematic/meta-updater https://github.com/advancedtelematic/meta-updater Quickstart project with a nice tutorial: https://github.com/advancedtelematic/garage-quickstart-rpi 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.
theamk 10y ago
Mender should be pretty immune to power failures in the middle of the updates -- even if second partition is only half-written , it is still not activated. 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.
ralphmender 10y ago
<disclaimer: I am with Mender> We have been evaluating OSTree as a potential building block for Mender, however the key challenges we've come across: integrating OSTree into an existing device/OS seems quite invasive - https://ostree.readthedocs.io/en/latest/manual/adapting-existing/ https://ostree.readthedocs.io/en/latest/manual/adapting-exis... block level signatures is not possible, which we feel is a requirement for an over-the-air updater rollback is not built-in and can be quite challenging to implement reliably (bootloader level) Think OSTree as more of a building block, like Git is for your development process. We might use it in the future but robustness and easy integration are our first priorities.
- mwcampbell 10y ago
  Why is it important to have signatures at the block level? Wouldn't signing an archive or binary diff be good enough?
  - eystein 10y ago
    Signing an archive would probably be good enough for many cases. Block level is a bit simpler (all or nothing) and thus less risk of mixing with unsigned parts (sideloading attacks). For security-sensitive embedded devices (e.g. payment terminals), block level signatures would allow hardware verification during boot as well (1st stage bootloader verifies 2nd stage, then kernel, etc.) if designed correctly.

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.

mwcampbell 10y ago

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 being used, OSTree itself will work with a variety of filesystems including ext4. Edit: An upside of the alternating rootfs partition approach is that the rootfs can be cryptographically verified at the block level. Chromium OS implemented this, and CoreOS also uses that implementation. This is probably outside the scope of Mender itself, but the updating approach used by Mender enables it.

eystein 10y ago
Cryptographic signing and verification is in scope for Mender [0], and frankly it should be in scope for all updaters -- too many hacks have happened due to lack of codesigning. [0] https://tracker.mender.io/projects/MEN/issues/MEN-1020 https://tracker.mender.io/projects/MEN/issues/MEN-1020

oytis 10y ago

If you are interested in OSTree, there is an open-source solution for OSTree updates on embedded devices. Yocto layer: https://github.com/advancedtelematic/meta-updater https://github.com/advancedtelematic/meta-updater Quickstart project with a nice tutorial: https://github.com/advancedtelematic/garage-quickstart-rpi 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.

theamk 10y ago

Mender should be pretty immune to power failures in the middle of the updates -- even if second partition is only half-written , it is still not activated. 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.

ralphmender 10y ago

<disclaimer: I am with Mender> We have been evaluating OSTree as a potential building block for Mender, however the key challenges we've come across: integrating OSTree into an existing device/OS seems quite invasive - https://ostree.readthedocs.io/en/latest/manual/adapting-existing/ https://ostree.readthedocs.io/en/latest/manual/adapting-exis... block level signatures is not possible, which we feel is a requirement for an over-the-air updater rollback is not built-in and can be quite challenging to implement reliably (bootloader level) Think OSTree as more of a building block, like Git is for your development process. We might use it in the future but robustness and easy integration are our first priorities.

mwcampbell 10y ago
Why is it important to have signatures at the block level? Wouldn't signing an archive or binary diff be good enough?
- eystein 10y ago
  Signing an archive would probably be good enough for many cases. Block level is a bit simpler (all or nothing) and thus less risk of mixing with unsigned parts (sideloading attacks). For security-sensitive embedded devices (e.g. payment terminals), block level signatures would allow hardware verification during boot as well (1st stage bootloader verifies 2nd stage, then kernel, etc.) if designed correctly.