背景
Linux カーネル開発に携わっている人はおそらく、Linux 5.7 以降、サードパーティ モジュールのバイパスを防ぐために、このことを知っているでしょう。 EXPORT_SYMBOL 内部機能へのアクセスを制限するため、 kallsyms_lookup_name() は輸出されなくなりました。
同時に、eBPF も開発および成長していますが、ハードウェア ドライバーの開発や、カーネルの動作を一時停止してユーザー モード プログラムが判定結果を返すのを待つ必要がある特定のセキュリティ機能の実装など、従来のカーネル モジュールを置き換えることはできません。
これにより、私の中に疑問が生じました。従来のカーネル モジュールには互換性の問題があるのに、なぜ eBPF の開発中に従来のカーネル モジュールの互換性メカニズムをさらに改善できないのでしょうか。
虐待について
輸出禁止 kallsyms_lookup_name()サードパーティ モジュールが内部シンボルにアクセスするためのしきい値が高くなりますが、これらのシンボルに本当にアクセスする必要がある場合は、他の方法でターゲットを見つけることができます。
その結果、悪用は完全には排除されていませんが、エクスポートされた関数を通じて直接実行できた操作には、より間接的な手段が必要になります。
たとえば、Linux 5.7 のこの変更は LTTng に影響を与えました。
カーネルの管理者がサードパーティのドライバーが内部実装に依存することを望んでいないことは理解していますが、クエリ エントリと等しくない要件がキャンセルされました。
もちろん、シンボルを見つけることもできます。に等しくすることはできません任意に呼び出すことができ、両者の間に矛盾はありません。
適応の複雑さについて
eBPF はいくつかの問題を解決しますが、すべてのシナリオをカバーできるわけではありません。
メインライン カーネルに属していないドライバー開発者にとって、プロジェクトが完全にオープン ソースであっても、シンボリック CRC、構造の変更、インターフェイスの削除、および異なるリリース間の違いに直面する必要があります。
すでに、異なる機能を備えた 2 セットのカーネル拡張メカニズムがありますが、従来の外部モジュールに対するユニバーサルなクロスバージョン互換性ソリューションはまだ提供されていません。
別の考え方
カーネル管理者はすべての内部シンボルの長期安定性を保証するつもりはないので、既存のベースで最も基本的なモジュール ロード プロトコルのセットとより完全なシンボル クエリ インターフェイスのみを保証できるでしょうか?
たとえば、開発者がシンボルをクエリすると、より多くのメタデータが返されることがあります。
- シンボリックアドレス
- シンボルタイプとABIバージョン情報
- 関数プロトタイプまたは型ハッシュ
- シンボルが属するモジュールとそのライフサイクル情報
- エクスポートの種類、アクセス制限、利用可能な機能
エクスポートされていない内部シンボルについては、すべてを禁止するのではなく、よりきめ細かいアクセス許可を導入することも検討できます。
型情報は可能な限りビルド ツールによって自動生成できますが、動作互換性情報は保守者のメンテナンス負担を軽減するために明確なバージョン規則が必要です。
使用方法については、ドライバー開発者の決定に任されています。このようにして、カーネルは、ほとんどの内部関数に対して長期的に安定した ABI コミットメントを提供する必要がありません。
コストの考慮事項
この設計には当然コストがかかります。
安定した基本インターフェイス自体を維持する必要があり、シンボルのセマンティックな変更をすべてバージョン番号に依存して解決できるわけではありません。特にエクスポートされていない内部シンボルの場合、アクセス権をどのように区切るかが依然として問題です。
しかし、これらの問題は、「安定したカーネル ABI の保証がない」ということを終点とするのではなく、少なくとももう一度議論することができます。基本的なインターフェイスに互換性のない変更が本当に必要な場合は、新しいバージョンを導入し、古いインターフェイスに対して適切なサポート サイクルを設定するだけです。
Red Hat と Android GKI は、さまざまなスコープで安定したカーネル ABI を実装しました。これは、特定の条件下で安定性を維持できることも示しています。
結論
カーネルを自由に進化させ、外部ドライバーが変化を積極的に識別して適応できるのであれば、なぜそうしないのでしょうか?
