著者：コーリー・ミニヤード
核心的な結論
前回の記事では、信頼性や私が取り組んだカーネルのバグについてお話ししました。しかし、それらは一体何を意味するのでしょうか？
これらのバグはいずれも、お客様から再現手順を提供していただけるものではありませんでした。完全なラボ環境、あるいはさらに悪いことに、お客様のサイトでのみ発生しました。ほとんどのお客様は品質と信頼性を非常に重視しており、カーネルのコアダンプを設定し、クラッシュ情報を記録する仕組みを備え、徹底的なテストを実施しています。そのため、システムを限界まで酷使し、障害発生時に必要な情報を抽出することができます。弊社もテストを実施しており、カーネルは様々なソースから膨大な量のテストを受けています。それでもなお、バグは解消されません。
これらのバグ例はあくまで例示ですが、私がこれまで取り組んできたバグの範囲とよく一致しています。したがって、
- 顧客がコードを追加する場合、ほぼ確実にバグが含まれるでしょう。主流のカーネル開発プロセスで検証されていないため、抜本的な対策を講じない限り、主流のカーネルコードよりも品質が劣る可能性が非常に高いです。
- ファームウェアもまた、危険要因の一つです。システムによっては、起動後にファームウェアがなくても動作するものもありますが、ファームウェアはシステムを起動させる役割を担っているため、依然として非常に重要です。一方、ファームウェアが常に動作しているシステムもあります。ファームウェアはソフトウェアと同様に重要であり、多くの場合、クローズドソースです。私は多くのファームウェアコードを見てきましたが、正直なところ、信頼感は持てません。
- カーネルには競合状態が数多く存在します。それらは常に発見されています。こうしたバグは非常に見つけにくく、現在の分析ツールではカーネルほどの規模のものを処理することはできません。発生頻度は低く、発生したとしても根本原因の特定は困難です。後続のパッチでバグが修正された事例をいくつか見てきましたが、それらのパッチは品質改善のためのパッチであり、バグを修正しているとは認識されていませんでした。
- 最適化コンパイラやスーパースカラシステムでは、メモリ操作の順序付けに関わる競合状態型のバグが存在します。（疑問点があれば、メモリバリアについて検索してください。）適切なバリアを設定するのは非常に困難です。幸いなことに、ほとんどのLinuxコードは順序付けにミューテックスとロックを使用していますが、こうした種類のバグはカーネル内に潜んでいる可能性が高く、競合状態よりもさらに厄介です。さらに、RCUという非常に難しいバグもあります。RCUなしではスケーラビリティが確保できないため、カーネル内で多用されています。（疑問点があれば、Linux RCUについて検索してください。RCUは最初は少し理解しにくいかもしれません。）
顧客が追加したコードは、品質管理プロセスを通じて管理することが可能です。
ファームウェアはより複雑ですが、起動後に何も行わない非常に簡略化されたブートローダーであればおそらく管理可能です。しかし、ほとんどのファームウェアは、システムの実行に巨大なブラックボックスを導入します。ACPIとEFIがOSの制御なしにシステムの動作をプリエンプトできるようになった現在では、以前よりもさらに複雑になっています。リアルタイムLinuxグループは、一部のシステムでファームウェアがレイテンシの原因となっていることを特定しました。一部のシステムでは、ファームウェアがOSの動作と非同期で実行されることがあります。安全性のために、ファームウェアはシステムの他の部分と同様に厳格な要件を満たす必要があります。EFIとACPIは非常に大きく、カーネルに匹敵するほどのサイズです。
カーネルの競合状態は、現在の技術力では現実的に管理できません。具体的な数値があれば良いのですが、そのようなデータは非常に入手困難です。私がお答えできるのは、Linuxカーネルの保守経験に基づいたものだけです。
私の意見では、Linux の障害確率を 10^-6 にするには、以前に議論した競合状態や解放後使用シナリオを検出できるツールが必要になります。そのようなツールが存在するまでは、Linux カーネル単体では、安全性が重要なシステムに必要な障害確率を満たすことはできないと思います。そのようなツールがあっても、10^-7 に到達するのは困難に思えます。プリエンプティブ システムで 10^-8 に到達するのは不可能に思えます。複雑すぎるのです。それは 11,500 年に 1 回しか障害が発生しないことを意味します。それをどうやって測定できるのかさえわかりません。十分な規模に拡張できる正式な分析手法があれば可能かもしれませんが、そこまでには程遠い状況です。
そしてこれはカーネルだけの話です。カーネルエンジニアが「ユーザーランド」と呼ぶものも考慮する必要があります。安全性が極めて重要な機能がそこで実行される場合、ユーザーランドに必要なライブラリやツールも重要になります。ユーザーランドのコードはカーネルよりも多く、多くの場合、品質への配慮はカーネルほどではありません。さらにファームウェア、そしてハードウェアもあります。確かに、状況はかなり深刻です。
では、Xenについてはどうでしょうか？
Xenについて少し調べてみました。カーネルよりもコード量は少なく、複雑さもやや劣ります。よく書かれていて、よく設計されているように見えます。しかし、同じ問題が依然として存在します。マルチスレッドのプリエンプティブシステムであることに変わりはなく、競合状態が多々あることは間違いないでしょう。さらに、Xenが管理していないものの、必要なデバイスをすべて管理する仕組みも必要です。Linuxカーネルの安全性を認証するのは、太平洋を泳ぐようなもので、不可能です。Xenの認証は、大西洋を泳ぐようなものです。規模ははるかに小さいですが、それでも不可能です。
どのハイパーバイザーでも同じ問題が発生するだろう。どれも同じようなことをしているからだ。
イギリス海峡横断泳のような偉業が必要だ。確かに難しいが、不可能ではない。
では、私たちは希望を捨てるべきなのでしょうか？
そうではないかもしれません。次の記事でいくつかの選択肢についてお話しします。
Please reach out to discuss your particular scenario today.
