Streaming Updates Over HTTP

Although RAUC has some basic HTTP download functionality, it so far focused on installing from update bundles on local storage. When not using casync, an update with a bundle provided by a remote web server was a two-step process: First download the bundle to local storage (e.g. by rauc-hawkbit-updater) and then install it using RAUC.

But, even when most modern embedded systems are not that short on storage, the need for reserving extra space for a temporary update image is still quite inefficient.

RAUC's new built-in HTTP streaming removes the need for intermediate local storage. The bundle data (i.e. file system images) is read on-demand while writing it to its destination device(s) on the target. No intermediate storage is required.

To build RAUC with streaming support, you must enable the network and the streaming option during configuration:

$ ./configure --enable-network --enable-streaming [..]

Also note that your kernel must have CONFIG_BLK_DEV_NBD enabled as either module or compiled-in.

The RAUC command line tool (as well as the InstallBundle() D-Bus method) then allows starting an installation directly from a remote URL:

# rauc install https://example.com/update-bundle.raucb

How Does This Work Internally?

The HTTP streaming support leverages another well-established Linux kernel feature, the network block device (NBD). NBD provides access to a remote block device via a standardized network protocol and a client/server architecture. The Linux kernel implements the NBD client and allows transparent access via a /dev/nbdN block device.

In RAUC, an unprivileged helper process implements the NBD server part that converts NBD read requests to HTTP range requests. This way, RAUC has random access to a remote bundle.

Since almost all common web servers (and CDNs) support range requests, the requirements on server side are actually quite simple.

Streaming supports HTTP/1.1 and HTTP/2, basic authentication (user/password), HTTPS (with TLS-based client authentication) and custom headers.

Bundle Encryption

With its use of signed bundles, RAUC is explicitly designed to not require any trusted/secure communication channel or infrastructure. For example, this makes it possible to use a USB memory stick as well as untrusted cloud storage as update source.

However, in some scenarios though, it's not enough to ensure the authenticity of the bundle, but also that it cannot be extracted or examined by third party. Sensitive application code or calibration data might be part of an update and should be protected during transport.

This is where the new bundle encryption comes into play. With 1.7, RAUC allows encrypting a bundle for one or more different recipients. An encrypted bundle can still be streamed, which makes it possible to use the same bundle for both the USB and the untrusted cloud storage cases above.

Encrypted bundles introduce a third bundle format: the crypt bundle. Just like for the legacy plain format and the recommended verity format, you can specify the bundle format to use in your bundle's manifest:

[bundle]
format=crypt

The actual encryption is designed as a two-step process as often the entity that builds the system software and thus generates the bundle and the entity that manages the per-device keys use independent infrastructure.

Thus in a first step, one can build a so-called 'unencrypted crypt bundle', which means that the payload is already (symmetrically) encrypted, but with a random unencrypted key:

$ rauc bundle [..] unencrypted-crypt-bundle.raucb

In a second step, the CMS structure holding the signature and the bundles manifest can be asymmetrically encrypted for one or multiple recipients:

$ rauc encrypt [..] --to recipients.pem unencrypted-crypt-bundle.raucb encrypted-crypt-bundle.raucb

What Will Come Next?

This is of course not always predictable, as contributions are community or customer project driven, but we can already give a preview of some features that are already being worked on or close to being merged:

• Support for desync (as an alternative implementation of the casync protocol) which is used together with RAUC on Valve's Steam Deck finally made its way into the master branch.
• Support for atomic bootloader updates for support ROM loaders that support fallback images at fixed addresses/offsets (instead of a partition) was contributed and merged in PR #918.
• We are working on built-in incremental updates, also leveraging the new built-in streaming capabilities. The draft PR #936 contains working code, but still needs review and documentation. A preparation PR that supports the incremental image property is already part of RAUC 1.7 to ease compatibility.
• There has been ongoing discussion and also promising PRs to enhance the progress handling of RAUC on various levels (better partitioning, more fine-grained updates, etc.)

Even more ideas and PRs are in progress already. Stay tuned and feel invited to participate and guide the direction of RAUC's development, for example by joining our Matrix channel.