RAUC v1.6 Released
While major changes are about to come, the RAUC v1.6 release already paves the way under the hood. Built-in streaming support will be one of the next features built on top of the 'verity' bundle format in RAUC.
But even if the v1.6 release contains only some preparations with regards to streaming support, it provides a number of other new features and fixes worth mentioning. They originate from 63 merged pull requests with a total of 181 commits.
A special thanks goes out to the notable number of first-time contributors showing RAUC's growing popularity and community!
Below you will find an excerpt of things that have changed since RAUC v1.5.1. For a complete list, refer to the release notes
Improved Misconfiguration Checking and Handling
This release adds some more protections against common pitfalls when configuring RAUC. One of the most obvious is that commands like rauc service, which cannot work without a system configuration present, will now refuse to start without a valid configuration.
Also common mistakes in the configuration of slots and hooks are now checked and reported during parsing.
New Slot Types for Flash Storage
Although use of raw flash storage is being phased out in favor of eMMCs, there are still some use cases for them. RAUC received support for two new slot types.
[slot.rootfs.0] type=nor ...
it now supports writing images to raw NOR flash (using flashcp).
[slot.rootfs.0] type=jffs2 ...
writing a JFFS2 partition from a tar archive is supported.
Improved Hook Handling
Hook handling gained improvements in various ways in this release:
Hook configuration parsing and handling gained some consistency checks to prevent manifest authors from running into common misconfiguration, misspelling etc.
Pre- and post-install hooks of boot-* slots now support manipulation of data written due to changed execution order and additional information passed via environment variables.
If an image is given, hooks now also have access to the size of the image in the environment variable RAUC_IMAGE_SIZE.
Installing a slot using an install slot hook will now be more visible in the log which now prints:
Updating /dev/sda5 with 'install' slot hook
Install Hooks for Data Migration
A potential use case for install hooks (that allow to fully customize the slot installation) is to use them for copying the content of one redundant data partition to the other one. While this does not require any image at all, having an image (i.e. filename set) for a slot was mandatory so far. With this release, you can now omit the filename property if an install slot hook is used.
The manifest would then contain:
[hooks] filename=hooks.sh ... [image.datafs] hooks=install
Copying can then be done with this (simplified) hook snippet for example:
case "$1" in slot-install) mkdir -p $RAUC_MOUNT_PREFIX/data mkfs.ext4 $RAUC_SLOT_DEVICE mount $RAUC_SLOT_DEVICE $RAUC_MOUNT_PREFIX/data cp -a /data/* $RAUC_MOUNT_PREFIX/data/ umount $RAUC_MOUNT_PREFIX/data ;; [...]
Mounting RAUC Bundles on the Target
The new rauc mount command was added as a preparation for the upcoming streaming support where a simple mount call will not be sufficient anymore for mounting the bundle (for development or debugging purposes).
However, you can already benefit from this command in terms of convenience and security as this ensures the bundle is verified and protected against malicious access.
Note that this is really only meant for development / debugging purposes and not for misusing RAUC bundles as a signed container.
$ rauc mount /path/to/bundle.raucb Mounted bundle at /mnt/rauc/bundle. Use 'umount /mnt/rauc/bundle' to unmount $ umount /mnt/rauc/bundle
Manual Signature Extraction and Replacement for External Signing
In some use-cases it is required that the bundle signature is created in a dedicated isolated room or environment where external tools like rauc are not permitted.
The new commands rauc extract-signature and rauc replace-signature target this use case. See the documentation for a comprehensive example on how to use it in this scenario.
The extract-signature command can also be useful when manually debugging signing or verification issues.
$ ./rauc extract-signature --keyring test/openssl-ca/dev-ca.pem test/good-verity-bundle.raucb extracted-signature.cms
you get the extracted signature that (for the 'verity' bundle format) you can process using openssl cmdline tool to either inspect the ASN1 content
$ openssl cms -verify -CAfile test/openssl-ca/dev-ca.pem -out manifest.raucm -inform DER -in extracted-signature.cms
or extract the inline manifest.
$ openssl asn1parse -inform der -in extracted-signature.cms
Trusted Host Environment
When using rauc convert with the older plain format, people encountered problems by the 'trusted environments' checks that were introduced as a mitigation for CVE-2020-25860 with RAUC v1.5.
The new option --trust-environment allows to explicitly override these checks for rauc convert.
Similar to this, a new option --no-check-time was added for rauc resign and rauc info to allow ignoring a possibly incorrect system clock on the host system.
In 2021, as Docker decided to remove autobuilds from their free plan, we switched to GitHub Actions for building our test container.
A new scan-build workflow adds another static code checker to our CI to detect potential issues early. However, we had to disable memory leakage checks since llvm is not yet able to deal with glib's autofree handling.
Testing Changes in an Interactive QEMU System
The qemu-test script, that is primarily meant for executing the RAUC test suite under QEMU, got a new system argument. With this specified, the QEMU will roughly behave like a system running RAUC. It will boot into an interactive shell, start the RAUC service, etc.
$ ./qemu-test system
# rauc status === System Info === Compatible: Test Config Variant: Booted from: rootfs.0 (A) [..]
You can use this for a quick interactive test of changes done to the code.
In the past, we have seen some people running into misconfiguration or misinterpretation of how the RAUC boot-mbr/gpt-switch slot types and feature is to be configured. A partial rewrite of these sections should prevent this in the future.
Some of the bugs that were fixed since v1.5.1:
- The check for 'safe' file systems that was introduced as a CVE mitigation in v1.5 now also allows installing bundles from ZFS and ramfs.
- An unexpected abort of raw image copying could have led to a file descriptor being left open (potentially preventing further installations until a service restart).
- A failed boot state determination of single slots sometimes led to all slots being displayed as bad.
- The VFAT filesystem label names generated by RAUC didn't pass the stricter checks in new mkfs.vfat versions. The generation was adapted to always emit valid label names.
- Limiting the bundle download size did not work when the server does not advertise the content size.
... to the long list of contributors since v1.5.1:
Ahmad Fatoum, Alexander Dahl, Arnaud Rebillout, Bastian Krause, Christian Hitz, Christoph Steiger, Daniel Mack, Enrico Jörns, Fabian Büttner, Holger Assmann, Ian Abbott, Jan Lübbe, Jean-Pierre Geslin, Ladislav Michl, Livio Bieri, Ludovico de Nittis, Marcel Hellwig, Michael Heimpold, Michael Tretter, Omer Akram, Pascal Huerst, Richard Forro, Roland Hieber, Rouven Czerwinski, Sijmen Huizenga, Taras Zaporozhets, Vivien Didelot, Vyacheslav Yurkov.
In its current master branch, RAUC now supports encrypted Bundles. This tutorial will introduce you to the basics of using encryption in RAUC and show how to use it in a simplified Yocto setup with the meta-rauc Layer.
RAUC is an update framework for safely deploying verified updates on your embedded Linux devices. It ensures atomicity of the update process to protect from sudden power outages, hardware failures, etc. So, why would one like to run RAUC on an emulated platform?