Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== CIP Software updates architecture ======

This document describes the requirements and a non-detailed architecture for CIP software updates

===== Requirements =====

These requirements were extracted from a survey conducted among CIP members and by investigating popular update software.

[*] means "essential requirements"

  - Functionality requirements
    - Ability to update the kernel, rootfs, and applications [*]
    - Ability to update the bootloader
    - Easy to customize the update steps [*]
    - Whitelist: update only these files/folders
    - Blacklist: update everything except these files/folders
  - Portability requirements
    - Independent of the image build system [*]
    - Independent of the underlying filesystems [*]
    - Minimize client program dependencies [*]
    - Provide an interface to interact with bootloaders [*]
  - Update media requirements
    - Ability to update from a network server [*]
    - Ability to update from local media: USB, microSD, LAN [*]
  - Resource requirements
    - Minimize network bandwidth usage [*]
    - Minimize storage overhead on the client [*]
    - Keep downtime below a few minutes [*]
    - Minimize CPU utilization peaks
    - Minimize storage costs on the server [*]
  - Security requirements
    - Signed updates (authentication, integrity) [*]
    - Encrypted communication [*]
    - Ability to run on OP-TEE
    - Ability to update encrypted filesystems
    - Ability to update block devices using dm-verity
    - Device authentication
  - Fail-safety requirements
    - Reliable against power loss (atomic updates) [*]
    - Ability to roll back to a previous working image [*]
    - Ability to do a factory reset (rollback to initial version)
    - Ability to wipe a partition (only clear data)
  - Network server requirements
    - Ability to search and get information from devices
    - Ability to see the update status [*]
    - Ability to select what devices to update
    - Ability to scale to millions of devices

===== Non-detailed architecture =====

The architecture is composed of multiple components that work together to implement the updating system. The build tool is used to create the operating system image, and it may also provide information about the way the system is partitioned and the filesystem format. The server is in charge of storing different versions of the operating system images for each device, and delivering those images to the devices in an efficient and secure way. The client is in charge of applying updates and interact with the bootloader and the server. We will use a typical A/B update architecture because it is stable, fail*safe, and has support on most available tools. Below we show the main roles realized by each component and possible open*source candidates to satisfy them.

  * Build tool
    * builds operating system images
    * examples: deby, isar, debos, yocto/oe, live*wrapper, etc.
  * Server
    * Storage
      * stores operating system images and versions efficiently
      * candidates: casync, ostree
    * Delivery
      * sends only data that has changed (deltas)
      * candidates: casync, courgette, ostree, rsync
    * Security
      * guarantees encryption, authenticity and integrity of updates
      * candidates: digital signature (x509), https, delta hashes
    * Server application
      * has an https REST API (requires a token on the client)
      * communicate status, send commands, download manifests
      * as a frontend to visualize update status and control updates
      * candidates: mender.io, hawkbit, custom(flask, django, expressjs, ..)
    * File*based vs block based
      * block based updates ensure that any file attributes are updated
      * if the tool supports the necessary attributes file*based updates are possible too
  * Client
    * Updater
      * a daemon that accesses the server and performs the updates
      * verifies digital signatures
      * supports various bootloaders (u*boot, efibootguard, etc)
      * candidates: swupdate, rauc, mender, custom script
    * A/B updates
      * each partition is duplicated (with exceptions such as the data partition)
      * enables lower downtime, rollback, and seamless updates
      * stream updates directly to avoid needing a cache
      * use the active partition as the seed to reduce bandwidth usage
      * For small storage devices jump to an update ramdisk
      * For local updates use a USB filesystem
Wiki

User Tools

Site Tools

Page Tools
