Post has shared content
OSADL Networking Day, Part II

In the 2nd session, Jan Altenberg talked about why you should care about security. He repeated customer arguments he has heared of, such as: "my device is running in a secure network" - that didn't work i.e. in the UK hospitals. Also, "there is no interest in attacking your device" is no valid argument, because devices can be abused for botnets, no matter what device it is. Some people even assume that their software is "100% bug free", because, oh, well... And, last but not least, if manufacturers don't care about security, they will almost certainly be forced to care by the governments in the future. There are several easy steps to secure devices: don't run things as root if not necessary, use file system permissions, remove unnecessary services and make use of capabilities, plus several more higher level mechanisms in Linux. If you use distributions like Debian, they already take care of serveral of those issues. An important aspect is that security needs to be taken of in the beginning of a project, not in the end (because then everyone runs out of time). Finally, if companies need help with these things, support companies like his are there to help.

Next, Patrick Ohly (Intel) talked about "Four system update mechanisms except RAUC, with and without integrity protection", with a focus on integrity protection of the filesystem. Patrick works on the Yocto project, so building root filesystems before shipping is one of his tasks. Often, devices are located in areas where they can't be physically updated by a technican, so updating over the network and making sure only the intended software runs on the device is essential.  Patrick looked at swupd, OSTree (used by AGL), swupdate, Mender.io and RAUC, but in his talk, he wanted to focus on the underlying mechanisms, not about particular solutions. One of the key criteria is if an update system is block based or file based: some integrity mechanisms work on block level, some on file level, and in order to activate updated content, block based mechanisms need to be rebooted, but keep the image together and improve testability. On the other hand, file based systems make live updates much faster (but maybe also more complicated). Wearing out flash based storage media is also an aspect which needs to be taken care of. Another aspect is that some update systems make assumptions about which bootloader to use, which update server to support and which provisioning service to use. Several systems seem to agree on hawkbit for provisioning. The kernel has mechanisms for integrity measurement and enforcement (IMA/EVM), but their finding is that i.e. SQLite has issues with it (it keeps files open, so the hashes are never recreated), and directories are not protected. However, the upstream development for IMA/EVM is slow, but there are block based alternatives like DM-Verity, coming from ChromeOS. Finally, Intel now has an IoT demo platform based on Yocto, where they demonstrate the whole setup.

In the last talk before lunch, my colleague +Enrico Jörns talked about the RAUC (Robust Auto Update Controller) framework. While customers might disagree, the most important reason for updating is deploying security updates and bugfixes, not features. Updating should be as robust as possible; unattended updates should not brick your device. In addition, unauthorized modification should be avoided. Often people start with a shell script (well, there is never enough time to develop an update system, right?), but over the time it turned out that this also often misses a lot of important corner cases regarding NAND handling, sudden power loss, out-of-memory situations etc. An updating concept always starts with a controlled environment (i.e. Yocto, PTXdist, Buildroot) and a lot of (mostly automated) testing of the generated root filesystem. Then you need to verify identity, both of the device (is it the right image for it?) and of the update service (is this authorized to update this device?). In order to achieve atomicity, RAUC makes use of redundancy. A+B scenarios have the advantage that it is really robust (you can fallback if something goes wrong), but needs enough space for two systems. One of the design criteria for RAUC was that it is designed as a framework, so you can use it with many different bootloaders (Barebox, U-Boot, Grub), media (USB stick, NAND, eMMC, ...). RAUC contains an update daemon that runs on the device under Linux, plus a D-Bus connected command line tool to talk to RAUC. Updates are put into bundles (compressed and mountable squashfs) which are signed with X.509 signatures and can basically contain anything. Bundles contain things to put into slots (i.e. rootfs, app-fs, bootloader).  Enrico outlined that RAUC also supports different integrity mechanisms (IMA/EVM, DM-Verity), even those where files are re-hashed with a key which is only available on the target. Finally, RAUC can be integrated with the Hawkbit deployment server. For integration, there is meta-rauc for Yocto, and it is also integrated in PTXdist mainline.



PhotoPhotoPhotoPhoto
31.05.17
4 Photos - View album

Post has shared content
Interesting discussion about field upgrade strategies at OSADL Networking Day.
Photo

Post has attachment
RAUC v0.1.1 released!

https://github.com/rauc/rauc/releases/tag/v0.1.1

Fixes signature verification with OpenSSL1.1.x, D-Bus activation for non-systemd systems, and different build system issues.

For a more detailed overview of changes in this version, see
http://rauc.readthedocs.io/en/latest/changes.html#release-0-1-1-released-may-11-2017

PTXdist 2017.04.0 now provides full RAUC integration and thus allows you to easily manage embedded Linux updates for your next project! 

Post has attachment
Robust updating of redundant root filesystems using the Open Source update framework #RAUC at the #EmbeddedWorld2017. See our demo switching between Yocto- and PTXdist-based file system images in different rollout scenarios. The #Barebox bootchooser framework allows to safely switch between multiple boot targets and provides advanced fallback handling. Visit the +Pengutronix booth (H4-261) to see how to use it for your next Embedded Linux project!
Photo

Post has attachment
Visit us at at the +Chemnitzer Linux-Tage and see RAUC working in cooperation with a HawkBit deployment server. We have set up 6 Raspberry Pis with a PiTFT and demonstrate safe and secure updating from a file system image built with Yocto to a file system image built with PTXdist.
Photo

Post has shared content
Just in time for the +Chemnitzer Linux-Tage next weekend, +Enrico Jörns just published the new website for RAUC, the Robust Auto Update Controller. So if you want to update your Embedded Linux devices in the field in a reliable and scalable way, you should either meet us in Chemnitz (or at Embedded World in Nuremberg next week), come to Enrico's talk or have a look at the growing documentation.

http://www.rauc.io

Post has shared content
Next talk at the +Chemnitzer Linux-Tage​ embedded track: +Enrico Jörns​ reporting about RAUC, the Robust Auto Update Controller. 
Photo

Post has attachment
RAUC moved to its own GitHub organization, find us now on
https://github.com/rauc

Post has attachment
Our Yocto layer meta-rauc is now available on GitHub. Use it to easily integrate RAUC into your next project https://github.com/rauc/meta-rauc
Wait while more posts are being loaded