組み込みLinuxのOTAアップデート、パート1 –基本と実装

更新の必要性

組み込みLinux製品がラボを離れて実際の世界に入ると、デバイスを更新する方法の問題を検討することが重要になります。

更新は必ずしも必要ではありませんが、ある時点で発見されたバグがないソフトウェアを考えるのは難しいです。ソフトウェアが完璧であっても、デバイスがネットワークまたはインターネット上でオープンソースライブラリと通信する場合は、セキュリティの更新が必要になる可能性があります。

CVE-2104-01650（ハートブリード）を例にとってみましょう。この脆弱性は、OpenSSL暗号化ライブラリに影響を及ぼし、ひいてはネット上のWebサイトの3分の2に影響を及ぼしました。 3年後の今でも、攻撃に対して広く開かれた、防御されていないバージョンのOpenSSLを実行している多くの組み込みLinuxデバイスがあります。

ブロックとファイルの更新

Linuxの更新について話すとき、「ブロック」および「ファイル」更新システムが言及されているのを目にするかもしれません。これは、ブロックデバイスに直接書き込むか、個々のファイルを更新して更新を実行することにより、一度にパーティション全体を更新することを意味します。デスクトップまたはサーバーLinuxのファイル更新システム（「sudoapt-getupgrade」など）に精通している場合があります。

組み込みLinuxでは、ブロックベースのアップグレードは、その原子性と、ファイルシステム全体が通常は組み込みLinuxビルドシステムの出力であるという事実のために進むべき道です。各組み込みデバイスのストレージスペースは特定の製品で一定であると予想されるため、毎回同じサイズのパーティションを作成します。このタイプの更新は、ある種のフォールバックまたはリカバリイメージと密接に関連しています。

障害が発生した場合の復旧

デバイスが使用できない状態のままになることは決してありません（たとえば、停電が発生した場合）。これを解決するには、更新プロセスで問題が発生した場合に、常に別のパーティションに「フォールバック」できるようにします。

図1.障害が発生した場合の回復–フォールバックオプション（出典：ByteSnap）

上記では、停電の場合のフォールバックモードの2つの可能な実装を見ることができます。左側では、ブートローダーがレスキューパーティションを起動し、レスキューパーティションがメインパーティションを起動します。右側では、ブートローダーはスイッチに基づいて2つのパーティションのうちの1つを起動します。

ブートローダーは、ブートが成功したかどうかを判断する何らかの方法を実装する必要があり、成功しなかった場合は、レスキューパーティション（左側の図）または前の作業パーティション（右側の図）に戻る必要があります。

レスキュー方式（左側）では、メインパーティションにより多くのスペースを提供できますが、デュアルrootfs方式（右側）では、2つのパーティション間でスペースをほぼ均等に分割する必要があります。スペースが問題にならない場合は、ダウンタイムが少なくなるという理由だけで、dual-rootfsメソッドを使用することをお勧めします。レスキュー方式で更新するには、2回のリブートが必要です。1回はレスキューパーティションに、もう1回はメインに戻します。更新はいつでも実行できるため、dual-rootfs方式では再起動が1回だけ必要です。

これらのシステムで安全に更新できないのは、ブートローダー（または実際にはレスキューパーティション）です。ブートローダーも更新できるようにする場合は、2つの別個のブートローダーパーティションと、2つの間で切り替えるロジックを実装するための何らかのBoard-Management-Controllerが必要になります。

図2.障害が発生した場合の回復–ボード管理コントローラー（出典：ByteSnap）

これはもちろん複雑なソリューションであり、追加のマイクロコントローラー、新しいファームウェアセット、およびより複雑なハードウェア設計が必要です（たとえば、別のインテリジェントプラットフォーム管理インターフェイス（IPMI）コントローラーを含む一部のデバイスで使用されます） 。したがって、機能的でスコープが小さく、更新する必要のないブートローダーの構築を目指す必要があります。

U-Boot環境変数

U-bootは、変数を格納できる不揮発性の「環境」を実装します。これらはLinuxからもアクセスできます（elinux.orgで詳しく説明されているように、環境の保存方法に応じてさまざまな方法で）。

これは、上記の「スイッチ」を実装するための最も明白な方法です。また、以前の起動の成功または失敗に関する情報を保存するために使用できるため、起動に失敗した場合にスイッチを元に戻して、作業パーティションを復元できます。

図3.U-boot環境変数（出典：ByteSnap）