Software is steadily increasing its complexity and this raises the size of a whole Update. SWUpdate allows incremental updates based on filesystem, and single file updates are possible. A good update concept will still allow lightweight updates without losing on reliability, but more care must be taken to handle all use cases. A well known way for reliable updates is to replace the whole filesystem as a single binary, but of course the size can be in term of several hundreds of megabytes or even gigabytes.

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


 

A new exciting SWUpdate was released ! A short changelog from previous release:

SWUpdate can be used to restore complete a device if it gets broken or it helps in the factory to install for the first time the software on a new branded device. The diskpart handler can set up partitions (for NAND flash the ubipartition) handler is used. This feature is often used together with a rescue system, that can restore even in field a broken device by initializing the device. Up now, SWUpdate was able to partition disks but it required external tools (like mkfs) to initialize a filesystem. However, an update agent like SWUpdate must be as much as possible self contained. This increase both reliability and security.

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”];
}

Self-driving Chevrolet Bolt by Cruise Automation undergoing testing in San Francisco. The vehicle is equipped with numerous Velodyne LiDAR sensors – San Francisco, CA, USA – 2020

Check talk at ELC 2020 how SWUpdate was used by Cruise for self driving cars in San Francisco (https://static.sched.com/hosted_files/ossna2020/56/No_Store_for_AV_Parts_ELC_NA_2020.pdf).

SWUpdate is chosen by CIP Project as Updater Agent – check on https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip_comparison_report for more information.