ここ数年間ライブカーネルパッチこの技術は、可能な限り最高のシステム稼働時間を確保するために努力するシステム管理者の間で人気がありました。
このプロセスを可能にするためにカスタムパッチを準備し、しばしば有料の顧客に配布し、時には自宅のユーザーに無料で配布します。
実行中のカーネルバージョンと利用可能な最新のソースコードの違いを利用してこれらのパッチを自動的に生成できないのはなぜですか？私が理解したのは、最も多くの利点を得ることができるサーバーコアは、一般的に数年に一度の大きな変更だけを受け取り、それ以外には主なバグ修正とセキュリティ更新のみを受け取るため、これが簡単になるようです。同様に、安定性が問題である場合は、比較的重要度の低いマシンを実行しているボランティアが最初にパッチを構築し、パッチがどれだけうまく機能しているかを自動的に報告するシステムを設定するのが簡単に見えます。
しかし、このうち何も起こりませんでした。私が何を逃してこのようなことが起こったのですか？
答え1
私たちは、プログラムの実行をプログラムを生成する静的ソースコードと考えたいと思います。しかし、彼らは変化し続けています。同様に、メモリのカーネルはディスクのカーネルとは異なります。
ディクストラの手紙を引用しようとしたら」gotoは有害と見なされます。「…
私が最初に指摘したのは、正しいプログラムを構築するとプログラマーの活動が終わるのですが、プログラムの制御下で発生するプロセスが彼の活動の実際の主題であるということです。なぜなら、望む効果を達成しなければならないのがまさにこのプロセスだからです。必須仕様を満たす必要があるこのプロセスの動的動作。しかし、一度プログラムが作成されると、そのプロセスの「作成」はマシンに任されます。
2番目のステートメントは、私たちの知能は静的関係を把握するのに適していますが、時間の経過とともに進化するプロセスを視覚化する能力は比較的適切に開発されていないということです。したがって、私たちは（私たちの限界を知っている賢明なプログラマーが）最善を尽くすべきです。静的プログラムと動的プロセス間の概念的なギャップの解消、プログラム（テキストスペースに拡張）とプロセス（時間に拡張）の間の対応をできるだけ単純にします。
これから私はディスクからカーネルをロードしないプログラムやカーネルをメモリに入れることは悪い考えだと推論しました。他のことを知りたくない場合は、できる再起動すると、現在実行中のカーネルと同じカーネルが生成されます。
システム管理者として、あなたは実際のカーネルがパッチしたカーネルと微妙に異なるので、フランケンシュタインのモンスターではなく実際の一般的なカーネルで終わっていることを知りたいです。
リアルタイムパッチが本当に難しいですね。ライブパッチを自動的に作成することは技術的に不可能です。
プログラムコードが効果的に独自に書き換えられることを理解することが重要です。
int X = 10;
void run(){
X=5;
}
このコード例では、X=10数値はコードとして実行されません。コンパイラは10数値を「X」位置に配置します。行3が実行時に実行されると、「X」位置の値が置き換えられます。実際に値を上書きします。これは、10 実行中のプログラムコードから数字が完全に消えることを意味します。
次に、次のコマンドを使用してこの問題をライブにパッチしようとしています。
int X = 20;
void run(){
X=15;
}
Xは何を20または15にパッチする必要がありますか？パッチする必要がありますか、それともそれを置くべきですか？ここでは、コードだけを変更するのではなく、動的に生成された値を変更します。動的に生成されるので、変更する必要はないと思いますが、変更しない場合は、新しいコードで5または10がまだ有効な値であることを知っていますか?これは自動的には実行できません！
簡単に言えば、ライブパッチを作成する技術と関連ツールがありますが、それを使用して結果をテストするには専門家が必要です。これらのツールをリリースし、一般ユーザーがそのツールを使用する方法を理解することを期待するのは、多くの一般ユーザーがシステムを台無しにするのに最適な方法です。
答え2
実行中のカーネルにパッチを導入するために使用できるすべてのメカニズムは、実行中のカーネルにルートキットを導入するなど、悪い用途にも使用できます。
マルウェアが他の適切なネットワークレベルの脆弱性を介して侵入すると、破損の証拠として使用される可能性があるローカルに修正されたファイルがまったく存在しない可能性があります。
また、以下のものがKASLR（カーネルアドレス空間レイアウトのランダム化）カーネルへの攻撃をさらに困難にするように設計されたこの方法は、保護したい情報（メモリ内のさまざまなカーネルルーチンのアドレス）も成功したライブパッチに必要な情報であるため、ライブパッチを複雑にします。おそらく、この情報は合法的な目的でのみ使用できるように賢く管理できますが、これは難しい問題だと思います。
単一の大規模なサーバーではなく、仮想化、並列性、および複数の小型サーバーを強調する最新の「クラウド」アプリケーション設計の原則によって、個々のサーバーの稼働時間が以前よりも重要ではなくなりましたか？アプリケーションアーキテクチャにロードバランシングされた複数のサーバーセットが含まれており、セットのサイズが可変である場合は、パッチが適用された新しい仮想サーバーを起動し、パッチが適用されていない古い仮想サーバーを解体してからすべてのサーバーが回復するまで、を繰り返すことができます。パッチしました。新しいものに置き換えられました。アプリケーションスタックのすべてのレベルでこれを行うことができれば、問題は他の方法で解決される可能性があるため、ライブパッチはまったく必要ありません。
答え3
カーネルは* nixベースのオペレーティングシステムの中核です。オペレーティングシステムのすべての動作を制御します。したがって、リアルタイムパッチは現在進行中の作業を妨げる可能性があります。だからリアルタイムパッチはできませんね。