The core of the docker support is to load a new image. Standard SWUpdate’s features are supported as well, and images for containers can be installed in streaming mode like the other artifacts. The loader docker image is an image handler, and an example for its usage can be:

images: ({

filename = “docker-image.tar”
type = “docker_imageload”;
installed-directly = true;  // if you need streaming

})

As well as for loading, there are a set of handlers to manage images. All of them are realized as script handler, and they runs as postinstall script. Images can be deleted and “prune” to remove old images.

Container can be created with the own handler. In that case, the artifact passed to the handler is the JSON file interpreted by docker to configure the container. For example, to create a “Hello World” container, the configuration can be something like:

{

“Image”: “hello-world”,

“HostConfig”: {

“RestartPolicy”: {

“Name”: “always”

},

“AutoRemove”: false

}

}

This file should be packed into the SWU. In sw-description, the handler to install the JSON above looks like:

scripts: ( {

filename = “hello-world.json”;
type = “docker_containercreate”;
properties: {

name = “helloworld”; /* Name of container */

}

});

Further handlers allow to delete and prune containers. Not the full REST-API is implemented, but just the entry points required for an update. Next, further API could be added, as to manage networks and volumes.

New release does not just have news related to containers. There is support for application variables, that allow to split and to set persistent values without using bootloader variables and without using files for this. Of course, writing application variables are fully power-cut safe and redundant like the bootloader variables.

Delta update can run over encrypted channels, like other communication.  Better support for wfx backend is introduced. And of course, a set of fixes flew into mainline – you can check what was changed and fixed by reading the git history of the project.

But what about to update just the part of the giant blob that was changed between two updates ? This is more complex than replacing a single file, but it guarantees the maximum reliability and the installed software will be exactly the same as the one built on your host. This is more important in case you sign the software, and in all case secure boot is required on your device.

The “Delta Handler” in SWUpdate addresses these topics. Thanks to the “rolling hash” theory, SWUpdate is able to compute on the device itself which part of the binary blobs are different and to download only the changed parts, strongly reducing the size of the downloaded data. And this maintaining all features present in SWUpdate. Do not trust to fairy tale: not any frog will turn into a prince !

And of course: still everything Open Source !

The Civil Infrastructure Platform (CIP)’s Software Update Working Group, has announced the immediate availability of the CIP SWUpdate Lua Round Robin Handler:

https://gitlab.com/cip-project/cip-sw-updates/swupdate-handler-roundrobin

It is meant to augment SWUpdate’s core features ― such as the recent getroot() addition ― in order to provide a generic run-time dynamic target selection handler, chain-calling other SWUpdate handlers for the heavy lifting works. In its simplest form, such can be a round robin target selection in an A/B deployment scenario, i.e., when currently running on system A, flash system B and vice versa. As with SWUpdate, contributions are more than welcome! So, be invited to poke around and take a look at https://www.cip-project.org/about

• security:
  • first block decryption with pkcs11
• general:
  • merge install from file with OTA install
  • extend -o option
    • create directory if not present
  • selections via configuration file
  • optimize reuse of configuration file
  • fix postinstall in case of downloader
  • add thread synchronization at startup
• License:
  • prepare to be REUSE compatible (WIP)
• handlers:
  • diskpart : extend to initialize a filesystem
    • support for VFAT
    • support for ext2 / ext3 /ext4
• Lua :
  • detect root device and export to Lua
• Webserver:
  • Update to Mongoose 6.18
• doc:
  • rewrote some parts not very clear
• ipc:
  • extend IPC with new option
  • -o can be set via IPC
  • dry-run can be set via IPC
  • version checking via IPC
  • increase robustness
• parser:
  • full support of links
  • extend hook to partitions
• bootloader:
  • fix grub interface
• build:
  • do not rebuild if nothing changed
• fixes :
  • fix defects reported by coverity

In fact, a common goal for an attacker is to replace some system tools and the shell with an own implementation to get control of the attacked device. Any call to “system” or the execution of an external tool could become potentially a security leak. SWUpdate does not call “system” with the exception of shell scripts, and it is also strongly encouraged to replace shell scripts with Lua, as Lua is called in the process context of the updater without spawning new processes.

Going on in the direction to provide a very flexible updater without reducing security, SWUpdate has now support to initialize without external tools the partitions it creates. An open source library is added to SWUpdate to support VFAT filesystem, while support to initialize a Linux ext (ext2 / ext3 or more common ext4) is implemented by porting part of the mkfs tool into SWUpdate sources and linking to the standard libextfs libraries. You can easy set in sw-description which partitions should be formatted by setting the new property fstype as done in the following example:

partitions: (
{

type = “diskpart”;
device = “/dev/sde”;
properties: {
labeltype = “gpt”;
partition-1 = [ “size=64M”, “start=2048”, “name=bigrootfs”, “type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B”];
partition-2 = [“size=256M”, “start=133120”, “name=ldata”, “type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7”, “fstype=vfat“];
partition-3 = [“size=512M”, “start=657408″,”name=log”, “fstype =ext4“, 63DAF-8483-4772-8E79-3D69D8477DE4”];
partition-4 = [“size=4G”, “start=1705984″,”name=system”, “type=0FC63DAF-8483-4772-8E79-3D69D8477DE4”];
partition-5 = [“size=512M”, “start=10094592″,”name=part5”, “type=0FC63DAF-8483-4772-8E79-3D69D8477DE4”];
}

    software =
     {
             version = "0.1.0";

             myboard = {
                 stable = {

                     hardware-compatibility: ["1.0", "1.2", "2.0", "3.0", "3.1"];
                     rev-1.0: {
                             images: (
                                     ...
                             );
                             scripts: (
                                     ...
                             );
                     }
                     rev-1.2: {
                             hardware-compatibility: ["1.2"];
                             images: (
                                     ...
                             );
                             scripts: (
                                     ...
                             );
                     }
                     rev-2.0: {
                             hardware-compatibility: ["2.0"];
                             images: (
                                     ...
                             );
                             scripts: (
                                ...
                             );
                     }

The device should recognize which hardware revision is running, and SWUpdate is started via “selection” to parse just the relevant part of the file. A lot of entries must be duplicated, for example if most releases share the same kernel or rootfs. Using links, the example above can be written as:

     software =
     {
             version = "0.1.0";

             myboard = {
                 stable = {

                     hardware-compatibility: ["1.0", "1.2", "2.0", "1.3, "3.0", "3.1"];
                     rev-1x: {
                             images: (
                                ...
                             );
                             scripts: (
                                 ...
                             );
                     }
                     rev1.0 = {
                             ref = "#./rev-1x";
                     }
                     rev1.2 = {
                             ref = "#./rev-1x";
                     }
                     rev1.3 = {
                             ref = "#./rev-1x";
                     }
                     rev-2x: {
                             images: (
                                  ...
                             );
                             scripts: (
                                  ...
                             );
                     }
                     rev2.0 = {
                             ref = "#./rev-2x";
                     }

This factorizes big blocks, that is some blocks are common between the revisions.

Links has the following syntax:

• the attribute name is ref
• link start with the character #
• relative links can be set with :
  • a single “.” : points to the current level in the tree, that means the ref”s parent
  • a double “..” : points to the parent’s leven in the tree
  • “/” is the separator to traverse the tree

Anyway, it was not possible until now to split one of the sections to share a common block and some specific extensions. For example, if the application consists of more entries (image and files), but depending on hardware revision or on the mode the device is started there are some entries that differ.

somecommon: {
      images: (
              {
                  .............
              },
              {
                  .......
              }
      )
}
somespecific: {
      images: (
              {
                  .............
              },
              {
                  .......
              }
      )

}      
selection : {
       images: (
                {
                    ref = "#./../../somecommon/images";
                },
                {
                    ref = "#./../../somespecific/images";
                },
                {
                    filename = "somefilename";
                    device = "/dev/somedevice";
                    type = "raw";
                }
            )

Links are now available in whole sw-description and this simplify the readability and maintainability. This feature is now commited.

• security:
  • encryption of sw-description (aes-cbc-256). Even the meta description of the release can be encrypted, specially useful if you add your own Lua embedded script.
  • fix IVT size for encryption (IPC)
  • support WolfSSL library and PKCS#11
  • fix encryption of single block
  • mbedTLS : support RSA PSS
• general:
  • rework dry-run mode. Adding dry-run to IPC, you can drive how the installation of the software should run
  • semantic version to compare versions.
  • resume after a power-cut.
  • IPC library becomes shared.
• handlers:
  • diskpart: new table available as soon as it is set. No additional reboot required !
  • diskpart : write table only in case of changes
  • new: UUID checker. It checks that a filesystem with same UUID does not exist.
• Lua :
  • add interface to get which selection is chosen
  • LuaJIT (5.1) compatibility