動的なソフトウェア更新

コンピュータ サイエンスにおいて、動的ソフトウェア更新( DSU ) は、実行中のプログラムのアップグレードに関する研究分野です。DSU は現在、業界で広く使用されていません。ただし、研究者は DSU を実装するためのさまざまなシステムと手法を開発しています。これらのシステムは、実際のプログラムでよくテストされています。

現在のオペレーティング システムとプログラミング言語は、通常、DSU を考慮して設計されていません。そのため、DSU 実装では、既存のツールを使用するか、専用のコンパイラを実装するのが一般的です。これらのコンパイラは、元のプログラムのセマンティクスを保持しますが、ソース コードまたはオブジェクト コードをインストルメント化して、動的に更新可能なプログラムを生成します。研究者は、DSU 対応のプログラムのバリアントを元のプログラムと比較して、安全性とパフォーマンスのオーバーヘッドを評価します。

実行中のプログラムはタプル と考えることができます。ここで は現在のプログラム状態、は現在のプログラムコードです。動的ソフトウェア更新システムは、実行中のプログラムを新しいバージョン に変換します。これを行うには、状態をが期待する表現に変換する必要があります。これには状態変換関数が必要です。したがって、DSU はプログラムを に変換します。実行中のプログラムを、新しいバージョンのプログラムの開始点 から到達可能なポイントタプル に縮小できる場合にのみ、更新が有効と見なされます。^[1]${\displaystyle (\delta,P)}$${\displaystyle \delta}$${\displaystyle P}$${\displaystyle (\delta,P)}$${\displaystyle (\delta ',P')}$${\displaystyle P'}$${\displaystyle (\delta,P)}$${\displaystyle (S(\delta ),P')}$${\displaystyle (S(\delta ),P')}$${\displaystyle (\delta ,P')}$${\displaystyle (\delta _{init},P')}$

プログラム内で動的更新が発生する場所は、更新ポイントと呼ばれます。既存の DSU 実装では、更新ポイントの扱いが大きく異なります。UpStare や PoLUS などの一部のシステムでは、実行中にいつでも更新が発生する可能性があります。Ginseng のコンパイラは、更新ポイントの適切な場所を推測しようとしますが、プログラマが指定した更新ポイントを使用することもできます。Kitsune と Ekiden では、開発者がすべての更新ポイントを手動で指定して名前を付ける必要があります。

更新システムは、サポートするプログラム変更の種類が異なります。たとえば、Ksplice は関数のコード変更のみをサポートし、状態表現の変更はサポートしません。これは、Ksplice が一般的な更新ではなく、主にセキュリティの変更を対象としているためです。対照的に、Ekiden は、異なるプログラミング言語で記述されたものであっても、実行可能な他のプログラムにプログラムを更新できます。システム設計者は、更新の範囲を制限することで、貴重なパフォーマンスまたは安全性の保証を引き出すことができます。たとえば、更新の安全性チェックでは、更新の範囲がその安全性チェックに合格した更新に制限されます。コードと状態の変換に使用されるメカニズムは、システムがサポートする更新の種類に影響します。

DSU システムは、ツールとして、開発者にとっての使いやすさとわかりやすさでも評価できます。Ginseng などの多くの DSU システムでは、プログラムがさまざまな静的解析に合格する必要があります。これらの解析は、DSU にとって価値のあるプログラムの特性を証明しますが、本質的に高度で理解しにくいものです。静的解析を使用しない DSU システムでは、専用のコンパイラーを使用する必要がある場合があります。一部の DSU システムでは、静的解析も特殊なコンパイラーも必要ありません。

DSU システムによって更新されるプログラムは、ターゲット プログラムと呼ばれます。DSU システムの学術出版物には、ケース スタディとして複数のターゲット プログラムが含まれることがよくあります。vsftpd 、OpenSSH、PostgreSQL、Tor、Apache、GNU Zebra、memcached、およびRedis はすべて、さまざまなシステムの動的更新ターゲットです。動的更新のサポートを念頭に置いて作成されたプログラムはほとんどないため、既存のプログラムを改造することは、実際の使用に向けて DSU システムを評価する貴重な手段となります。

動的更新によって対処される問題領域は、他のいくつかの問題の共通部分として考えることができます。例としては、チェックポイント、動的リンク、永続性などがあります。たとえば、ディスク上のファイル形式の以前のバージョンと下位互換性を保つ必要があるデータベースは、動的更新システムに期待されるのと同じタイプの状態変換を実現する必要があります。同様に、プラグイン アーキテクチャを持つプログラムは、実行時に新しいコードをロードして実行できる必要があります。

同様の技術は、ロード時や実行時に条件付きでデッドコードや到達不能なコードを削除し、残りのコードを再結合してメモリフットプリントを最小限に抑えたり速度を向上させたりする動的なデッドコード除去の目的でも使用されることがあります。^{[2] [3]}

動的なソフトウェア更新の最も古い先駆者は、冗長システムです。冗長環境では、メイン システムに障害が発生した場合にアクティブな計算の制御を引き継ぐ予備システムが用意されています。これらのシステムには、メイン マシンとホット スペアが含まれます。ホット スペアには、プライマリ システムのチェックポイントが定期的にシードされます。障害が発生した場合、ホット スペアが引き継ぎ、メイン マシンが新しいホット スペアになります。このパターンは更新にも一般化できます。更新が発生した場合、ホット スペアがアクティブになり、メイン システムが更新され、更新されたシステムが制御を再開します。

最も初期の真の動的ソフトウェア更新システムはDYMOS（Dy namic Modification System ）です。^{[4] 1983年にInsup Leeの博士論文で発表されたDYMOSは、インタラクティブなユーザーインターフェイス、} Modulaバリアントのコンパイラとランタイム、およびソースコードにアクセスできる完全に統合されたシステムでした。これにより、DYMOSは既存のプログラムに対して更新の型チェックを行うことができました。

DSU システムは、実行中のプログラムに新しいコードをロードし、既存の状態を新しいコードが理解できる形式に変換する必要があります。DSU の多くの動機付けとなるユースケースは時間的に重要であるため (たとえば、稼働中の脆弱なシステムにセキュリティ修正プログラムを展開するなど)、DSU システムは適切な更新の可用性を提供する必要があります。一部の DSU システムでは、更新を適用する前にその安全性を確認しようとします。

これらの問題には、標準的な解決策は一つではありません。通常、ある問題領域で優れたパフォーマンスを発揮する DSU システムは、他の問題領域とのトレードオフでそのパフォーマンスを発揮します。たとえば、動的更新の実験的テストでは、更新ポイントの数を増やすと、安全でない更新の数が増えることが示されています。^[5]

ほとんどのDSUシステムでは、更新のコード単位としてサブルーチンを使用していますが、新しいDSUシステムではプログラム全体の更新を実装しています。 ^{[6] [7]}

ターゲットプログラムが仮想マシン言語で実装されている場合、最新の仮想マシンは DSU (主にデバッグ)以外のユース ケースでランタイム ローディングをサポートしているため、VM は既存のインフラストラクチャを使用して新しいコードをロードできます。HotSpot JVM はランタイム コードのローディングをサポートしており、 Java (プログラミング言語)をターゲットとする DSU システムはこの機能を利用できます。

CやC++などのネイティブ言語では、DSU システムはプログラムに間接参照を挿入する特殊なコンパイラを使用できます。更新時に、この間接参照は最新バージョンを指すように更新されます。DSU システムがコンパイラを使用してこれらの間接参照を静的に挿入しない場合は、バイナリ書き換えを使用して実行時に挿入します。バイナリ書き換えは、実行中のネイティブ プログラムのメモリ イメージに低レベル コードを書き込んで関数をリダイレクトするプロセスです。これにはプログラムの静的分析は必要ありませんが、プラットフォームに大きく依存します。

EkidenとKitsuneは、 fork-execまたは動的ロードのいずれかを介して完全に新しいプログラムを起動することにより、新しいプログラムコードをロードします。その後、既存のプログラム状態が新しいプログラム空間に転送されます。^{[6] [7]}

更新中、プログラムの状態は元の表現から新しいバージョンの表現に変換される必要があります。これを状態変換と呼びます。状態オブジェクトまたはオブジェクト グループを変換する関数は、トランスフォーマー関数または状態トランスフォーマーと呼ばれます。

DSU システムは、トランスフォーマー関数の合成を試みるか、開発者が手動で提供することを要求するかのいずれかです。一部のシステムでは、これらのアプローチを組み合わせて、トランスフォーマーの一部の要素を推測しながら、他の要素については開発者の入力を求めます。

これらの変換関数は、古いバージョンの状態の各部分にアクセスするときにプログラム状態に遅延して適用することも、更新時にすべての状態を積極的に変換することもできます。遅延変換では、更新が一定時間で完了することが保証されますが、オブジェクト アクセス時に定常状態のオーバーヘッドも発生します。積極的な変換では、更新時にコストがかかり、すべての変換の実行中はシステムが停止する必要があります。ただし、積極的な変換では、コンパイラーが状態アクセスを完全に最適化できるため、遅延変換に伴う定常状態のオーバーヘッドを回避できます。

ほとんどの DSU システムは、更新に対して何らかの安全性プロパティを示すことを試みます。安全性チェックの最も一般的なバリエーションは型の安全性であり、更新によって古い状態表現で新しいコードが動作しない場合、またはその逆の場合、更新は安全であると見なされます。

型の安全性は、通常、アクティブ性安全性またはコンスフリー性安全性という 2 つの特性のいずれかを示すことによってチェックされます。更新時にコール スタックに更新された関数が存在しない場合、プログラムはアクティブ性安全であると見なされます。これは、データの新しい表現にアクセスする古いコードに制御が戻れないため、安全性を証明します。

コンスフリーは型の安全性を証明するもう一つの方法で、コードの一部が型の表現の知識を必要とする方法で特定の型の状態にアクセスしない場合は安全であるとみなされます。このコードは、抽象的には状態にアクセスする可能性がありますが、具体的には状態にアクセスしないと言えます。コードのどの部分でも、すべての型に対してコンスフリーを証明または反証することは可能であり、DSUシステムGinsengはこれを使用して型の安全性を証明しています。^{[8] [9]}関数がコンスフリーであることが証明された場合、古い表現を使用して状態にアクセスすることで型エラーが発生しないため、スタック上でライブであっても更新できます。

ヘイデンらによるcons-freenessとactiveness safetyの実証的分析では、どちらの手法もほとんどの正しい更新を許可し、ほとんどの誤った更新を拒否することが示されています。ただし、手動で更新ポイントを選択すると、更新エラーはゼロになり、頻繁な更新が可能になります。^[5]

DYMOSは、最も早く提案されたDSUシステムであるという点で注目に値します。DYMOSは、 Modulaの派生で書かれたプログラムのための完全に統合された環境で構成されており、 REPLと同様に、システムはコマンドインタープリタ、ソースコード、コンパイラ、ランタイム環境にアクセスできます。DYMOSでは、対話型環境でコマンドを実行することで更新が開始されます。このコマンドには、いつ更新が行われるかを指定する指令（when-conditionsと呼ばれる）が含まれています。DYMOSが利用できる情報により、実行中のターゲットプログラムに関して更新の型安全性を強制することができます。^[4]

Ksplice はLinux カーネルのみをターゲットとする DSU システムであり、ターゲット プログラムとしてオペレーティング システム カーネルをサポートする特殊な DSU システムの 1 つです。Ksplice はソース レベルのdiff を使用してLinux カーネルの現在のバージョンと更新バージョン間の変更点を特定し、バイナリ書き換えを使用して実行中のカーネルに変更を挿入します。^[10] Ksplice は、元の作者によって設立された商用ベンチャーである Ksplice Inc. によって保守されていましたが、2011 年 7 月にOracle Corporationによって買収されました。 ^[11] Ksplice は商用ベースで使用され、Oracle Linuxディストリビューションでのみ使用されています。^[12]

SUSE はライブカーネルパッチのオープンソース代替手段としてkGraft を開発し、Red Hat もkpatchで同様のことを行いました。どちらも、ftraceによって確立されたライブパッチメカニズムに依存しながら、実行中の Linux カーネルに関数レベルの変更を適用できます。kGraft と kpatch の主な違いは、ホットパッチを適用しながら更新されたコードセクションの実行時一貫性を確保する方法です。kGraft と kpatch は、それぞれ 2014 年 4 月と 2014 年 5 月にLinux カーネルメインラインへの組み込みが提案され、^{[13] [14]}ライブパッチの最小限の基盤は、2015 年 4 月 12 日にリリースされたカーネルバージョン 4.0 で Linux カーネルメインラインに統合されました。^[15]

2015 年 4 月以降、Linux カーネル メインラインが提供する共通のライブ パッチ コアに kpatch と kGraft を移植する作業が進行中です。ただし、関数の元のバージョンとパッチを適用したバージョン間の安全な移行に必要な関数レベルの一貫性メカニズムの実装は、適切なスタック フレームのないアセンブリ コードが関係する状況では Linux カーネルが提供するコール スタックが信頼できない可能性があるために遅れています。その結果、移植作業は 2015 年 9 月現在も進行中です。カーネルのコール スタックの信頼性を向上させるために、カーネルのコンパイル時オブジェクト ファイルをチェックし、コール スタックが常に維持されるようにすることを目的とした、専用の健全性チェックスタックツールユーザー空間ユーティリティも開発されました。これにより、カーネルの oopsメッセージの一部として、より信頼性の高いコール スタックを実現する可能性も開かれます。^{[16] [17][アップデート]}

Ginseng は汎用 DSU システムです。これは、cons-freeness安全技術を使用する唯一の DSU システムであり、更新された型に具体的なアクセスを行わない限り、スタック上でライブになっている関数を更新できます。

Ginsengは、 OCamlのC中間言語フレームワークを使用して記述されたソースツーソースコンパイラとして実装されています。このコンパイラは、すべての関数呼び出しと型アクセスに間接参照を挿入し、プログラム実行全体に定数時間のオーバーヘッドを課すことで、Ginsengが状態を遅延変換できるようにします。^[9] Ginsengのコンパイラは、初期プログラム全体と動的パッチの consフリー性を証明します。

Ginseng の最新バージョンでは、トランザクション安全性の概念もサポートされています。これにより、開発者は関数呼び出しのシーケンスを論理ユニットとして注釈付けし、アクティブ性安全性やコンスフリー性安全性では検出できない方法で更新がプログラムセマンティクスに違反するのを防ぐことができます。たとえば、 Ginseng の作者が調査したOpenSSHの 2 つのバージョンでは、重要なユーザー検証コードが、順番に呼び出される 2 つの関数間で移動されていました。最初の関数の最初のバージョンが実行され、更新が行われ、2 番目の関数の新しいバージョンが実行された場合、検証は実行されません。このセクションをトランザクションとしてマークすると、更新によって検証が妨げられることがなくなります。^[18]

UpStareは、スタック再構築という独自の更新メカニズムを使用するDSUシステムです。UpStareでプログラムを更新するには、開発者は可能なスタックフレーム間のマッピングを指定します。UpStareはこのマッピングを使用して、任意の時点で、任意の数のスレッドで、スタック上にある任意の関数でプログラムを即座に更新できます。^[19]

PoLUSはC言語用のバイナリ書き換えDSUシステムです。実行中のどの時点でも、変更されていないプログラムを更新することができます。関数を更新するには、ターゲット関数の前置きを新しい関数にリダイレクトするように書き換え、これらのリダイレクトを複数のバージョンに連鎖させます。これにより、更新されていない関数の定常状態のオーバーヘッドを回避できます。^[20]

Katana は、ユーザー モードELFバイナリに対して限定的な動的更新 (Ksplice およびそのフォークと同様) を提供する研究システムです。Katana のパッチ モデルは ELF オブジェクトのレベルで動作するため、コンパイル ターゲットが ELF である限り、言語に依存しない機能を備えています。

Ekiden と Kitsune は、 Cで書かれたプログラムに DSU の状態転送スタイルを実装する単一の DSU システムの 2 つのバリエーションです。 Ekiden と Kitsune は、単一のプログラム内の関数を更新するのではなく、プログラム全体を更新し、2 つの実行間で必要な状態を転送します。 Ekiden は、UNIXのfork-execというイディオムを使用して新しいプログラムを開始し、ターゲット プログラムの状態をシリアル化して転送することでこれを実現しますが、 Kitsune は動的リンクを使用して「インプレース」状態転送を実行します。 Kitsune は Ekiden のコードベースから派生したもので、Ekiden の後のバージョンと考えることができます。

Ekiden と Kitsune は、特殊なランタイムやコンパイラではなく、主にアプリケーション レベルのライブラリとして実装されている点でも注目に値します。そのため、Ekiden や Kitsune を使用するには、アプリケーション開発者は転送する状態を手動でマークし、プログラム内で更新が発生する可能性のあるポイントを手動で選択する必要があります。このプロセスを容易にするために、Kitsune には状態変換を書くためのドメイン固有言語を実装した特殊なコンパイラが含まれています。^{[6] [7]}

Erlang は動的ソフトウェア更新をサポートしていますが、これは一般に「ホット コード ローディング」と呼ばれます。Erlang では更新の安全性の保証は必要ありませんが、Erlang の文化では、開発者は更新によって生成される型エラーを適切に処理する防御的なスタイルで記述することが推奨されています。^{[引用が必要]}

PymoultはPythonで書かれた動的更新のプロトタイピングプラットフォームです。他のシステムから多くの技術を集め、それらを組み合わせて構成することができます。このプラットフォームの目的は、開発者が自分のニーズに合った更新技術を選択できるようにすることです。たとえば、Ginsengのように状態の遅延更新と、KitsuneやEkidenのようにアプリケーションのコード全体を変更を組み合わせることができます。^{[21] [22]}

マイクロソフトは、Microsoft Visual C++の内部パッチ適用技術を利用して、パッチの機能的正確性を維持しながら個々のC++関数にパッチを適用できるようにしています。現在知られているアプリケーションは、Azure SQL DatabaseのSQL Serverです。^[23]

• ホットスワップ § ソフトウェア
• 持続性（コンピュータサイエンス）
• 実行時検証

• Kspliceホームページ
• Ksplice ソースコード
• Ginseng プロジェクト ページとソース コード / UpStare 論文 / PoLUS 論文
• Erlang ホームページ
• Katanaホームページ
• Visual C++ パッチに関するホワイトペーパーのブログ投稿