web-dev-qa-db-ja.com

カーネルモジュールを完全に削除します

カーネルモジュールを完全に削除するにはどうすればよいですか？私は本当に削除することを意味します。 rmmodを使おうとしましたが、modprobe -rと同じようにモジュールをアンロードしただけです。そこで、modprobe -n -vを使用してすべてのモジュールのリストを取得し、手動で削除しました。

rmmod cramfs:
ERROR: Module cramfs does not exist in /proc/modules

したがって、モジュールをロードしようとすると、次のようになります。

modprobe -v -n cramfs:
FATAL: Could not open '/lib/modules/2.6.32-573.12.1.el6.x86_64/kerne/fs/cramfs/cramfs.ko': No such file or directory

しかし、それは、システムがcramfs.koファイルへのパスを知っているため、削除されたモジュールに関する情報をまだ取得していることを意味します。ロードされていないがロード可能なモジュールの例：

modprobe -v -n jffs2
insmod /lib/modules/2.6.32-573.12.1.el6.x86_64/kernel/lib/zlib_deflat/zlib_deflate.ko 
insmod /lib/modules/2.6.32-573.12.1.el6.x86_64/kernel/fs/jffs2/jffs2.ko

rmmod jffs2
ERROR: Module jffs2 does not exist in /proc/modules

モジュールを正しく削除する方法はありますか？

linuxkernelkernel-module
9
Majzlik

モジュールは、実行時に何らかの理由で必要に応じてRAM（および実行中のカーネルにリンク）にロードされます。それが発生するまで、モジュールは（または同等の）ディスク領域を使用します。

モジュールが構成された独自のカーネルを構築することで、diskスペースを少し節約できます。必要なものを（モジュールとしてではなく、組み込みで）含むカーネルを構築すると、関連する機能を使用してカーネルが非常に小さい少し速くなります。しかし、それは柔軟性と手間で大ヒットです。

1
vonbrand

それはあなたのディストリビューション/システムに依存します。

Linux ロード可能なモジュール は/lib/modules/$(uname -r)/にあるkoファイルで、サブフォルダーにソートされています。このフォルダ内のいくつかのファイル、特にmodules.dep[.bin]とmodules.order[.bin]はそれらすべての処理に役立ちます。 modprobeこれらのファイルを読み取って、モジュールのフルパスとその依存関係を取得します。

通常のコンピューターLinuxディストリビューション

ほとんどのLinuxディストリビューションでは、モジュールファイルはパッケージマネージャーのパッケージによってインストールされます。それらのコアセットは、たとえばkernel-modulesという名前の非常に一般的なパッケージによってインストールされ、一部のディストリビューションでは、使用頻度の低いモジュールを特定のパッケージによってインストールできます（モジュールは複数のパッケージに分割されます）。どのパッケージが不要なモジュールを提供しているかを見つけて、それらをアンインストールできます。

警告：

  • 特定の追加モジュールパッケージをアンインストールしても、その名前とパスはmodule.orderファイルとmodules.depファイルに引き続き表示されます。これらのファイルは脅威ではなく、modprobeを使用するために必要です。これらは、コアモジュールパッケージをアンインストールした場合にのみ削除されます。
  • モジュールをアンインストールすると、カーネルの主要な機能が削除され、システムが破損する可能性があります。 lsmodを実行して、削除してはならないモジュールの最小限のリストを取得することをお勧めします。

テキストファイルを編集して不要なモジュールの参照を削除したくなるかもしれませんが、対応するバイナリファイルの編集は面倒であり、パッケージが更新されるたびにそれらのファイルが復元されます。

組み込みシステム

小さな組み込みシステムは、ロード可能なモジュールに依存できますが、パッケージマネージャーを提供しない場合があります。一部の組み込みシステムは読み取り専用のルートファイルシステムを使用するため、組み込みシステムを完全に再構築して変更する必要がある場合があります。

カーネルまたは組み込みシステムを完全に再構築します

必要に応じて、カーネルを再構築して次のことを行うことができます。

  • 不要な機能のサポートを削除する
  • 可能な限りカーネル自体の内部にモジュールを構築することにより、ロード可能なモジュールの使用を減らします
  • モジュール署名を有効にして、カーネルがパッチ適用されたモジュールまたは外部モジュールを拒否するようにします
  • また、ロード可能なモジュールのカーネルサポートを削除して、モジュールをロードできないようにします。

ただし、これを行うにはいくつかのスキルが必要です。

その他のカーネル強化技術

他のいくつかの使いやすいメカニズムにより、動的にロードされるモジュールに対するカーネルのセキュリティを強化できます。

  • sysctl kernel.modules_disabled 特殊ファイル（実際には/ proc/sys/kernel/modules_disabled）に1を書き込むと、それ以上ロード可能なモジュールが拒否されますロードまたはアンロード、それらの凍結。
  • kernel.kexec_load_disabled で同じことを行うと、別のカーネルバイナリへのホットスイッチを拒否します（ダウンタイムなしでサーバーにカーネルアップグレードを適用するために使用される最近のカーネル機能）
1
A. Loiseau

カーネルモジュールがロードされていない場合、それが存在しない場合と同じですカーネルに組み込まれていない限り（説明します）以下）、唯一の例外は、通常、後でinsmodコマンドを使用してリロードできることです。

modprobeでエラーメッセージにパスが表示される理由は、modprobeがモジュールの標準の場所をチェックするようにハードコードされているためです（ 参照 ）。設定ファイルなど、modprobeにそのように指示するものはありません。 （モジュールが標準パスになく、挿入したい場合は、いつでもinsmodを使用できます）。

モジュールは、カーネルの起動後に、カーネルの外部にあるメカニズムによってロードされます。 systemdはモジュールをロードできるため、udevもロードできます。システムが使用しているメカニズムを見つけて、そこからモジュールをブラックリストに登録する必要があります。

_jffs2_は、ルーターまたはAndroid電話などの他のデバイスでこれを行うことを強くお勧めします。ここで具体的なアドバイスを提供するには、デバイスのメーカー/モデルに関する詳細情報が必要です。

`/ proc/modulesについてエラーが発生する理由は2つあります。

  1. _modprobe jffs2_を使用した例では、rmmodでエラーが発生します。これは、_insmod jffs2.ko_が機能しなかった可能性がありますが、エラーメッセージは出力されませんでした。ログ（dmesgなど）にエラーがないか確認してください。

  2. proc仮想ファイルシステムがマウントされていません。 chroot、SELinux、カーネル機能などにより、rootとしても_/proc_にアクセスしたりマウントしたりできない場合があります。 _ls /proc_できるかどうかを確認し、システム上の各PIDのディレクトリのリストのようなものを取得します。これをchrootで実行している場合は、マウント_/proc_をchrootにバインドする必要があります。

モジュールをカーネルに構築することは可能です。これにより、カーネルの一部になります。その時点ではモジュールではなくなったため、rmmodなどは機能しません。カーネルの一部であるモジュールをinsmodしようとするとどうなるかわかりません（すでに使用されているカーネルリソースを参照する不可解な「使用中のファイル」エラーが発生する可能性があります）。

以前はディスクコントローラなどのサポートを組み込むのが一般的でしたが、一部の組み込みプラットフォームでも、ソフトウェアにアクセスするために必要なデバイスに対して同じことを行う場合があります。

1
LawrenceC