Armadillo Base OS のソフトウェアアップデートの概要仕様

アップデート機能の要件

Armadillo Base OSのアップデート機能は以下の要件を実現しています。

製品機能の維持:

耐障害性の確保 (突然の電源断、瞬断、ネットワーク断によってデバイスはブリックにならない)
アップデート中でも製品機能を利用可能 (アップデートで特別なモードに入らない)で、アップデートを再試行ができる。外部からデバイス状態をできる限り観測可能。

アップデート処理のガード:

バージョンのダウングレードの防止。
ハードウェア種別の事前チェック。

差分アップデート:

ソフトウェアサイズを小さくするため差分アップデートに対応。
テキスト差分、バイナリ差分に対応。

その他:

ソフトウェアの署名、暗号化、圧縮。
btrfsを利用することでファイルシステムの書き換えが頻繁に発生する状況でもロバストに開発が可能。

モジュールと管理情報

以下のモジュールがアップデート処理に重要な役割をもっています。

SWUpdate
- SWUイメージの署名確認、解釈、ファイルの解凍、復号や、データ化け確認、イメージの書き込みなどアップデートの実処理を行います。
- 実処理の前処理 (pre install)、後処理 (post inst) にスクリプトを実行します。
SWUpdate用のスクリプト
- 前処理 (pre install)、後処理 (post inst) でArmadillo Base OS独自の処理を実行します。
armadillo-twin-agent
- アップデート処理の状態管理、Armadillo Twinと連携します。
ブートローダー。
- 起動失敗時に待機状態 (suspended) のArmadillo Base OSから起動します。この仕様はアップデート直後だけでなく通常時も有効です。

アップデート処理に密接に関係する起動処理を含めて以下の情報があります。

情報	起動時の責務	アップデート中の責務
eMMC EXT_CSD (PARTITION_CONFIG)	boot partition 0/1のどちらが有効か判断するために利用される	なし。アップデート処理が終わった後で boot partition 0/1 が切り替えられる
GPT メタデータ	パーティションテーブル	なし。基本的に変更されない
uboot environment variables	Linux+rootfsパーティションの A/B どちらが有効か判断するために利用される	アップデート処理が終わった後で A/B が切り替えられる
btrfs (user application 用のファイルシステム)	コンテナデータを保管するファイルシステム	RO スナップショットを利用して、現Application をバックアップする
user application コンテナー	ユーザーアプリケーションを起動する	書き込み対象 (コンテナー単位)。すべてをアップデートも、コンテナレイヤーを利用して差分アップデートも可能

アップデートの処理フロー

Armadillo Base OSをアップデートした際の大まかなアップデートフローは以下のとおりです。アプリケーション(コンテナー)のアップデートを実行した場合も基本的には同じフローです。大きな違いとして、Armadillo Base OSのアップデートを実行した場合にはデバイスの再起動が必要となり、一時的にデバイスが切断されます。一方、アプリケーション(コンテナー)のアップデートを実行した場合にはデバイスの再起動は発生しません。

デバイスローカルにファイル展開する。
署名を確認する。
ヘッダーを解釈する。
pre installスクリプトを実行する。
解凍してチェックサムを確認する。
イメージを書き込む。
post installスクリプトを実行し、A/Bの切り替えなどをおこなう。
必要であれば再起動する。
もし起動に3回失敗したらA/Bの切り替えを戻して前システムで起動する。

製品機能の維持

ソフトウェアアップデート中もデバイスのソフトウェアが持つ機能をほぼ利用できます。AV機能やネットワーク機能はそのまま利用できます。ソフトウェアアップデート処理は裏で動いています。そのため若干CPUとフラッシュへの書き込みにリソースを割くことになります。

Armadillo Base OSをアップデートした後は基本的に再起動が必要です。新しいOSが起動中には問題が発生して起動ができない場合もあります。その場合には、デバイス側はリカバリーモードで起動してサービスへの再接続を試み、サービス側はデバイスが再接続されることを待ち、結果的にエラーログを出力することになります。ユーザーアプリケーションをアップデートするときには再起動は発生しません。

ソフトウェアアップデートのタイミング図

A/Bアップデート (アップデートの2面化)

Armadillo Base OSのアーキテクチャでは、OSやブートローダー、アプリケーションなどフラッシュメモリのコンテンツを二重化して2つのパーティションに配置します。アップデートを行うときには、動作中のバンクには変更を加えず、通常動作をしながらスタンバイバンクをアップデートします。そのため、たとえ電源断、ネットワーク切断、ソフトウェアの問題による中断があっても動作中のバンクには影響ありません。アップデートが完了するとスタンバイしているバンクへと切り替えます。つまり、アップデートを繰り返すと交互にバンクを切り替えることになります。

リカバリー (ロールバック)動作

動作が不安定なソフトウェアを書いてしまい、システムが起動できなくなった際、自動的にアップデート前のシステムへロールバックする機能を提供します。ブートに必要なファイルが存在しない場合、もしくは3回起動に失敗した場合、スタンバイバンクからの起動を試みます。主に動作が不安定な開発フェーズを想定しており、セキュリティ上の懸念があれば市場運用で無効にできます。

アップデート対象とパーティション

以下の図はArmadillo Base OS対応製品のパーティションレイアウトのモデルです。

Armadillo Base OS対応製品のパーティションレイアウトのモデル

アップデート対象	書き込み単位	耐障害性
bootloader	パーティション単位	２面化
dtb + Linux kernel + rootfs	パーティション単位/ファイル単位での書き込み	２面化
ユーザーアプリケーション	ファイル単位での書き込み/バイナリ差分 (podman container で実現)	btrfs のスナップショットによる冗長化

起動、アップデートに関連する情報の耐障害性

領域	耐障害性
GPTメタデータ	２面化
uboot environment variables	２面化
btrfs (ユーザーアプリケーション用のファイルシステム)	meta のみ cow + dup
ユーザーアプリケーション用コンテナー	RO スナップショット

SWU イメージ

SWUイメージはSWUpdateで利用可能なファイル形式です。書き込むソフトウェアのイメージやソフトウェアアップデートに必要な情報を含ます。以下はSWUイメージのフォーマットです。

SWUイメージのフォーマット

header (sw-description) 部に以下の情報を含みます。

アップデート対象のイメージファイルのハッシュ
書き込み先ストレージの情報
ソフトウェアのバージョン情報
Boot環境変数の書き換え情報
アップデート前後に実行するスクリプトの情報

data部に以下の情報を含みます。

複数のアップデート対象のイメージファイル (zstで圧縮、AES256による暗号化を選択可能)
アップデート前後に実行するスクリプト

mkswu

mkswuはArmadillo Base OS向けにヘッダー情報とSWUイメージを簡単に作ることができる独自ツールです。デバイスの開発環境であるATDEには標準でインストールされており、VS CodeのプラグインによってSWUイメージのビルドが簡単にできます。詳しくは以下を参照してください。開発から運用までのベストプラクティス

アップデート処理のガード

コンポーネントとバージョン

SWUイメージとデバイスにはアップデート対象のコンポーネント名とバージョン番号を含んでいます。コンポーネント名はアップデート対象を識別するために利用され、バージョン番号はダウングレード防止に利用されます。アップデート開始前にSWUpdateはバージョン番号をチェックしてバージョンが上がる場合にのみアップデートが可能になります。セキュリティ対策を無効にするようなダウングレード攻撃の防止のために有効です。開発時に不必要な場合、このガードを無効にできます。

ハードウェアの識別

SWUイメージとデバイスにはハードウェア種別名とリビジョンを識別するための情報を含んでいます。ハードウェア種別名とリビジョンを含めて1つのハードウェアとして認識されます。ハードウェアの識別が異なる場合にはアップデートは無効になります。

差分アップデート

dockerのイメージレイヤー

docker¹ のレイヤーの仕組みを使ってファイル差分のみを抽出することで、ファイルサイズの増加を抑制したSWUイメージをビルドして、アップデートに利用できます。

Armadillo Base OSではdockerと互換性をもつpodmanを利用しています ↩