カーネルモジュールのブラックリストはなぜそれほど弱いのですか?

カーネルモジュールのブラックリストはなぜそれほど弱いのですか?

過去1〜2年間、Linuxカーネルモジュールをブラックリストに追加しようとしましたが(blacklist.confまたはカーネルコマンドラインパラメータを介して)機能しませんでした。とにかく、モジュールはカーネルにロードされました。これには、ブラックリストモジュールを試したときに発生する同様の困難に関連して、次のようないくつかの質問が提起されているようです。

modprobe.dおよびカーネルパラメータのブラックリストモジュールは機能しません。

/etc/modprobe.d/blacklist.conf を介してカーネルモジュールを除外すると動作しません。

カーネルモジュールブラックリストが機能しない

それでは、Linuxのブラックリストの動作がなぜそれほど脆弱なのでしょうか?

Sourcejediが彼の記事で述べたように回答、モジュールブラックリストはカーネルでは実装されていませんが、modprobe実際にはユーザースペースツールはオプションを使用する必要があります-bmodprobeそれ以外の場合は、ブラックリストにあるモジュールをロードします。

しかし、これは弱い行動の私のポイントに戻ります。つまり、ユーザースペースツールはオプトブラックリストを尊重してください。ユーザースペースツールはモジュールブラックリストを無視する必要がありますか、それともシステム管理者にこの動作が必要なのですか?ユーザースペースツールで単純に無視できないように、カーネルにブラックリストを実装する方が合理的ではないでしょうか?確かにこれはより強力な方針でしょうか?

それとも、modprobeブラックリストポリシーを基本的に単純にしたくないのはなぜですか?なぜ無視できるオプションですか?

簡単に言えば、これはデザインが悪いからですか、それともブラックリストの動作をより簡単で強力にすることができないのですか?

ベストアンサー1

現在の実装

ブラックリストはカーネルでは実装されません。によって実装されますmodprobe

ユーザーが名前付きモジュールのロードを手動で要求すると、ブラックリストの影響を受けません。

ブラックリストは、1)udevがハードウェアを検出すると自動的にロードし、2)request_module()呼び出しが次の場合にrequest_module()へのカーネル呼び出しを介して要求時にモジュールがロードされるのを防ぐために存在します。モジュールエイリアスまたはchar-major-10-237net-pf-10-proto-132

(udevの使用は、エイリアスを使用してモジュールをロードする場合にも適用されます。たとえば、エイリアスはドライバモジュールを必要とするscsi:t-0x01*scsiデバイスに使用されますst。)

modprobemodprobeに渡されないモジュール名で呼び出されたスクリプトは、-bブラックリストの影響を受けません。これにより、スクリプトの変更を依頼できます。推測するこれが適切なオプションを持つ理由です-b。または、他の方法を使用して問題のスクリプトを無効にします:-).

エイリアスではなく名前でモジュールを要求するカーネルのrequest_module()を使用することもできます。を実行するとrequest_module()-bが通過できませんでしたmodprobe

modprobeブラックリストは、他のモジュールの要件としてカーネルモジュールをロードしても参照されません。特定のドライバモジュールの自動ロードを停止したい場合、これは大きな問題ではありません。 udevがロードするモジュールを見つけたり、いくつかの異なる可能性をブラックリストに追加する必要があるかもしれません。

したがって、もともとカーネルの設計について質問しましたが、コマンドがデフォルトmodprobeでそれを暗示していない理由を尋ねることもできます。-b

デザイン

[ブラックリスト]を無視するオプションがあるのはなぜですか?

明らかに、「モジュールを自動的にロードしたくないが、必要に応じて手動でロードできるようにしたい場合」です。

私の基本的な仮定は、これが設計目標ではなく、偶然達成できないということです。設計が広く採用されている場合、特定のタイプの変更は危険または既存のシステムを損傷する可能性があります。私はまた、ブラックリストがモジュールロードコマンドの最初のバージョンの一部ではないことを指摘したいと思います。

さらに、このような構成ラインは、上記のすべてのinstall bad-module /bin/false「弱点」を防止します。技術的には、これは「指定されていません。[インストールコマンド]を置き換えるためのものです。」これまで「長期間使用」されており、少なくとも1回以上の書き換え/再ライセンス(module-init-toolsプロジェクト - >kmodプロジェクト)を経ていました。 1つは代替を実装しました。

ユーザーの例を見つけました。する〜したいブラックリストバイパス。しかし、これは非常に良い例ではないようです。これは明らかに正しいことであるように見える他の解決策を示しているからです。

実験するときは、現在ブラックリストにあるモジュールを使用していることを確認するのも便利です。浮上する最も明確な例は、再起動全体をテストしたいグラフィックドライバであるため、ブラックリストファイルを編集するのが最善です。

弱点

上記の回答の弱点 -

  1. request_module() 呼び出しが発生したときに表示されるロギングがないようです。したがって、可能な要因でrequest_module()呼び出しを除外したい場合は、これには透明性はあまりありません。

  2. モジュールがロードされると、lsmod他のモジュールで使用されているかどうかを簡単に確認できます。ただし、たとえば、モジュールにエラーが多すぎてロード時にシステムがすぐにクラッシュした場合、これは役に立ちません。 :-).そして、特定のモジュールXに対して、どのモジュールが厳しい要件を持っているかを検索するために事前に作成されたコマンドがないようです。 modprobe --show-depends X反対方向が表示されます。

  3. 他の未知の複雑さ。上記のいずれかが質問の問題を説明しているかどうかは、実際には明確ではないからです。modprobe.dおよびカーネルパラメータのブラックリストモジュールは機能しません。

おすすめ記事