Atomic Updates (and Fallback)

The magic word for fail-safe updating of systems is atomicity. This means: It must be ensured that an update has been successfully installed in full before it is enabled for use.

To ensure this, redundant boot partitions are used (also called dual copy or A + B approach). Two completely equivalent system partitions are used to perform updates on each other. The active partition gets written from to the inactive one, which is only switched to be the new active partition after the write process has been successfully completed. Switching between the partitions takes place in the boot loader. This also offers an advantage in terms of availability: With this mechanism, the update can easily be carried out in the background of the running application without interrupting it.

The use of redundant partitions then makes it possible optionally to fall back on the inactive system even in the event of a fault in the active system, thus significantly improving the availability of the platform.

Cryptographically Secured Updates

Since the update system enables the system software to be exchanged, this is a particularly critical area. In order to deny unauthorized persons access to the system, the update must be cryptographically signed when it is created and verified by the target system before installation. Asymmetric methods are ideal for this, as only the key for signing has to be kept secret, while the key for verification can be stored on the device without any further effort.

The use of common standards such as X.509 also allows more complex hierarchies with development keys, per device keys, multiple signatures, etc.

Further Requirements

The devil is often in the details, and so is the development of an update strategy. The technical specifications such as processor type and memory technology must be taken into account as well as the requirements of the application and the ecosystem in which the device is integrated.

Typical further questions that then arise

• How do you separate data and logs from the operating system?
• How do you migrate application data after an update?
• What does a sensible partitioning of the memory look like?
• Is it possible to safely update the bootloader?
• How should the device behave in the event of an error?
• How does the device reliably recognize that there is an error?

How Can we Support You?

Together with you, our integration team sheds light on the obvious and less obvious questions and requirements for the update system and first develops a basic update concept that can be refined in the further course of the project.

With RAUC there is already an update framework maintained by Pengutronix and fully licensed as open source as a starting point. This allows you to focus on the essentials without having to reinvent the wheel. Nevertheless, the coordination of the overall system to the specific requirements of the customer and the operational environment is anything but trivial and includes the configuration of various components that have to be closely interlinked.

On the basis of your Board Support Package (BSP), our integration team implements a redundant boot setup, configures all necessary system components and prepares everything so that update artifacts can be generated and installed.

If you need additional functionality that is not or not fully covered by the existing components, we will be happy to expand this for you. If possible, so that new features can flow back directly into the main development branch of the projects and do not accumulate as a technical debt in the project.

As part of the clarification of the requirement and the specific individual setup of the basic update and boot loader configuration, Pengutronix supports you with, among other things:

• Adaptation of the boot loader for redundant boot partitions (barebox, U-Boot, Grub, UEFI)
• Initial configuration of RAUC in the BSP (Yocto, PTXdist, Buildroot)
• Coordination of the watchdog behavior
• Clarification of security / verification behavior
• Clarification of related issues such as configuration management, data migration, etc.
• Integration in customer application / connection to deployment infrastructure
• Support in the further course

The biggest mistakes in the design of a redundant booting system are often made in the early phase of the project. Pengutronix will be happy to evaluate for you on the basis of many years of experience 'right from the start' whether the selected hardware and in particular the storage technology used, the power management or the processor pose risks.

And why RAUC?

RAUC is a modern open source update framework that offers a lean and easy-to-maintain code base through efficient use of established libraries such as glib, OpenSSL and curl. RAUC is divided into a service that runs on the target platform and verifies the update artifacts there and installs them atomically, and a host tool with which the update artifacts (bundles) are generated.

With the reduction to the essentials and the provision of both a command line tool and a D-Bus API, RAUC can be easily integrated into existing customer applications.

One of the essential philosophies of RAUC is the description of the redundant boot behavior via configuration file directly on the device. This not only allows the system to be introspected, but also allows generic update artifacts to be created.

Additional features such as PKCS#11 support for signing bundles, options for re-signing bundles or accommodating intermediate certificates in bundles make it possible to meet the security requirements in a professional environment.

For the boot loader updates, which are often underestimated in the field, but often urgently required later, RAUC offers the option of performing them completely atomically for many applications.

How Can OTA Updates be Implemented?

If the company already has a deployment infrastructure or a hosted solution is to be used, RAUC can be triggered with the help of a simple service that accepts requests from the infrastructure and calls RAUC via D-Bus or the command line.

The open source project hawkBit is ideal for OTA updates in your own (self-hosted) infrastructure. This offers a highly configurable solution for device management, deployment scheduling and feedback.

The connection to RAUC is quite easy to implement thanks to the existing clients in the RAUC project. With the rauc-hawkbit-updater, a solid client component written in C is available that interacts with the Device (DDI) API from hawkBit via REST and with RAUC via D-Bus.