linux-3.0.35_CVE-2019-10220

SOFTWARE REQUIREMENTS

3.x カーネルのコンパイルと実行には、さまざまなソフトウェアパッケージの最新バージョンが必要です。必要な最小バージョン番号とこれらのパッケージの更新方法については、Documentation/Changes を参照してください。これらのパッケージの古すぎるバージョンを使用すると、追跡が非常に困難な間接的なエラーが発生する可能性があるため、ビルドまたは操作中に明らかな問題が発生した場合に単にパッケージを更新すればよいとは考えないでください。

BUILD directory for the kernel:

カーネルをコンパイルする場合、デフォルトではすべての出力ファイルがカーネルソースコードと一緒に保存されます。オプション "make O=output/dir" を使用すると、出力ファイル（.config を含む）の代替場所を指定できます。例： kernel source code: /usr/src/linux-3.N build directory: /home/name/build/kernel

カーネルを構成してビルドするには、次を使用します： cd /usr/src/linux-3.N make O=/home/name/build/kernel menuconfig make O=/home/name/build/kernel sudo make O=/home/name/build/kernel modules_install install

注意：'O=output/dir' オプションを使用する場合は、make のすべての呼び出しでそれを使用する必要があります。

CONFIGURING the kernel:

マイナーバージョンを 1 つだけアップグレードする場合でも、この手順をスキップしないでください。各リリースで新しい構成オプションが追加され、構成ファイルが期待どおりに設定されていないと、奇妙な問題が発生します。最小限の作業で既存の構成を新しいバージョンに引き継ぎたい場合は、"make oldconfig" を使用します。これにより、新しい質問に対する回答のみが求められます。

• 代替の構成コマンドは次のとおりです： "make config" プレーンテキストインターフェース。 "make menuconfig" テキストベースのカラーメニュー、ラジオリスト、ダイアログ。 "make nconfig" 拡張テキストベースのカラーメニュー。 "make xconfig" X ウィンドウ (Qt) ベースの構成ツール。 "make gconfig" X ウィンドウ (Gtk) ベースの構成ツール。 "make oldconfig" 既存の ./.config ファイルの内容に基づいてすべての質問をデフォルト化し、新しい構成シンボルについて尋ねます。 "make silentoldconfig" 上記と同様ですが、既に回答済みの質問で画面を乱雑にするのを避けます。 さらに依存関係を更新します。 "make defconfig" アーキテクチャに応じて、arch/$ARCH/defconfig または arch/$ARCH/configs/${PLATFORM}_defconfig のデフォルトシンボル値を使用して ./.config ファイルを作成します。 "make ${PLATFORM}_defconfig" arch/$ARCH/configs/${PLATFORM}_defconfig のデフォルトシンボル値を使用して ./.config ファイルを作成します。 "make help" を使用して、アーキテクチャで利用可能なすべてのプラットフォームのリストを取得します。 "make allyesconfig" シンボル値を可能な限り 'y' に設定して ./.config ファイルを作成します。 "make allmodconfig" シンボル値を可能な限り 'm' に設定して ./.config ファイルを作成します。 "make allnoconfig" シンボル値を可能な限り 'n' に設定して ./.config ファイルを作成します。 "make randconfig" シンボル値をランダムな値に設定して ./.config ファイルを作成します。

  Linux カーネル構成ツールの使用に関する詳細は、Documentation/kbuild/kconfig.txt にあります。

  "make config" に関する注意事項：

  • 不要なドライバを含めるとカーネルが大きくなり、状況によっては問題を引き起こす可能性があります。存在しないコントローラカードのプローブが他のコントローラを混乱させる可能性があります。
  • "Processor type" を 386 より高く設定してカーネルをコンパイルすると、386 では動作しないカーネルになります。カーネルは起動時にこれを検出し、動作を停止します。
  • 数値演算エミュレーションを組み込んでコンパイルされたカーネルは、コプロセッサが存在する場合でもそれを使用します。その場合、数値演算エミュレーションは使用されません。カーネルはわずかに大きくなりますが、数値演算コプロセッサの有無にかかわらず、異なるマシンで動作します。
  • "kernel hacking" 構成の詳細は、通常、カーネルを大きくまたは遅くし（あるいはその両方）、一部のルーチンを積極的に不良コードを壊してカーネルの問題を見つけるように構成することによって、カーネルの安定性を低下させる可能性があります（kmalloc()）。したがって、「開発」、「実験」、「デバッグ」機能の質問にはおそらく 'n' と答えるべきです。

COMPILING the kernel:

• 少なくとも gcc 3.2 が利用可能であることを確認してください。詳細については、Documentation/Changes を参照してください。

  このカーネルでも a.out ユーザープログラムを実行できることに注意してください。

• "make" を実行して、圧縮されたカーネルイメージを作成します。カーネル makefile に合うように lilo がインストールされていれば "make install" を実行することも可能ですが、最初に特定の lilo 設定を確認することをお勧めします。

  実際のインストールを行うには root である必要がありますが、通常のビルドでは root は必要ありません。root の権限を軽々しく使わないでください。

• カーネルの一部を modules として構成した場合は、"make modules_install" も実行する必要があります。

• 詳細なカーネルコンパイル/ビルド出力：

  通常、カーネルビルドシステムはかなり静かなモードで実行されます（ただし完全に無音ではありません）。ただし、あなたや他のカーネル開発者は、コンパイル、リンク、その他のコマンドが正確にどのように実行されるかを確認する必要がある場合があります。そのためには、「verbose」ビルドモードを使用します。これは、"make" コマンドに "V=1" を挿入することで行います。例：

  make V=1 all

  ビルドシステムに各ターゲットの再ビルドの理由も表示させるには、"V=2" を使用します。デフォルトは "V=0" です。

• 問題が発生した場合に備えて、バックアップカーネルを手元に用意してください。これは特に開発リリースに当てはまります。各新リリースにはデバッグされていない新しいコードが含まれているためです。そのカーネルに対応するモジュールのバックアップも必ず保持してください。動作中のカーネルと同じバージョン番号の新しいカーネルをインストールする場合は、"make modules_install" を実行する前にモジュールディレクトリのバックアップを作成してください。 あるいは、コンパイル前にカーネル構成オプション "LOCALVERSION" を使用して、通常のカーネルバージョンに一意のサフィックスを追加します。LOCALVERSION は "General Setup" メニューで設定できます。

• 新しいカーネルを起動するには、カーネルイメージ（例：コンパイル後の .../linux/arch/i386/boot/bzImage）を、通常の起動可能なカーネルが置かれている場所にコピーする必要があります。

• LILO などのブートローダの支援なしでフロッピーから直接カーネルを起動することは、もはやサポートされていません。

  ハードドライブから Linux を起動する場合、おそらく LILO を使用しており、/etc/lilo.conf ファイルで指定されたカーネルイメージを使用します。カーネルイメージファイルは通常 /vmlinuz、/boot/vmlinuz、/bzImage、または /boot/bzImage です。新しいカーネルを使用するには、古いイメージのコピーを保存し、新しいイメージを古いイメージの上にコピーします。その後、LILO を再実行してローディングマップを更新する必要があります！！そうしないと、新しいカーネルイメージを起動できません。

  LILO の再インストールは、通常 /sbin/lilo を実行するだけです。新しいカーネルが動作しない場合に備えて、古いカーネルイメージ（例：/vmlinux.old）のエントリを指定するために /etc/lilo.conf を編集することもできます。詳細については LILO のドキュメントを参照してください。

  LILO を再インストールしたら、準備完了です。システムをシャットダウンし、再起動してお楽しみください！

  カーネルイメージでデフォルトのルートデバイス、ビデオモード、ramdisk サイズなどを変更する必要がある場合は、'rdev' プログラム（または適切な場合には LILO ブートオプション）を使用してください。これらのパラメータを変更するためにカーネルを再コンパイルする必要はありません。

• 新しいカーネルで再起動してお楽しみください。

IF SOMETHING GOES WRONG:

• カーネルのバグが原因と思われる問題がある場合は、MAINTAINERS ファイルを確認して、問題が発生しているカーネルの部分に関連する特定の人物がいるかどうかを確認してください。そこに誰もリストされていない場合は、次善の策として、私 ([email protected]) にメールを送り、場合によっては他の関連するメーリングリストやニュースグループに送信してください。

• すべてのバグレポートでは、必ず どのカーネルについて話しているのか、問題を再現する方法、およびあなたの設定（常識的に判断してください）を教えてください。問題が新しい場合はその旨を伝え、問題が古い場合は最初に気付いた時期を教えてください。

• バグが次のようなメッセージを生成した場合

  unable to handle kernel paging request at address C0000010 Oops: 0002 EIP: 0010:XXXXXXXX eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx ds: xxxx es: xxxx fs: xxxx gs: xxxx Pid: xx, process nr: xx xx xx xx xx xx xx xx xx xx xx

  または、画面やシステムログに同様のカーネルデバッグ情報が表示された場合は、正確に 複製してください。ダンプは理解不能に見えるかもしれませんが、問題のデバッグに役立つ情報が含まれています。ダンプの上のテキストも重要です。カーネルがコードをダンプした理由について何かを示しています（上記の例では、不良なカーネルポインタが原因です）。ダンプを理解する詳細については、Documentation/oops-tracing.txt を参照してください。

• CONFIG_KALLSYMS を有効にしてカーネルをコンパイルした場合は、ダンプをそのまま送信できます。それ以外の場合は、"ksymoops" プログラムを使用してダンプを理解する必要があります（ただし、CONFIG_KALLSYMS でのコンパイルが通常は推奨されます）。このユーティリティは ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ からダウンロードできます。または、手動でダンプのルックアップを行うこともできます：

• 上記のようなデバッグダンプでは、EIP 値の意味を調べられると非常に役立ちます。16 進数の値そのものは私や他の人にあまり役立ちません。それは特定のカーネル設定に依存します。すべきことは、EIP 行から 16 進数値を取得し（"0010:" は無視）、カーネル namelist でそれを調べて、問題のアドレスを含むカーネル関数を特定することです。

  カーネル関数名を見つけるには、症状を示したカーネルに関連付けられたシステムバイナリを見つける必要があります。これはファイル 'linux/vmlinux' です。namelist を抽出し、カーネルクラッシュからの EIP と照合するには、次のコマンドを実行します：

  root@kitploit:~

   nm vmlinux | sort | less
  

  これにより、昇順にソートされたカーネルアドレスのリストが得られ、そこから問題のアドレスを含む関数を簡単に見つけられます。カーネルデバッグメッセージで指定されるアドレスは関数アドレスと正確に一致するとは限らない（実際、ほとんど一致しない）ため、リストを単に 'grep' することはできません。しかし、リストには各カーネル関数の開始点が示されているため、検索中のアドレスより低い開始アドレスを持ち、その後に高いアドレスの関数が続く関数を探すことで、目的の関数を見つけられます。実際、問題レポートに「コンテキスト」を少し含め、目的の行の前後数行を提供すると良いでしょう。

  何らかの理由で上記の手順を実行できない場合（事前コンパイルされたカーネルイメージなどを使用している場合）、設定についてできるだけ多く教えていただけると助かります。詳細については、REPORTING-BUGS ドキュメントをお読みください。

• あるいは、実行中のカーネルで gdb を使用できます（読み取り専用、つまり値を変更したりブレークポイントを設定したりすることはできません）。これを行うには、最初に -g フラグを付けてカーネルをコンパイルします。arch/i386/Makefile を適切に編集し、その後 "make clean" を実行します。また、CONFIG_PROC_FS を有効にする必要があります（"make config" 経由）。

  新しいカーネルで再起動した後、"gdb vmlinux /proc/kcore" を実行します。これで、通常の gdb コマンドをすべて使用できます。システムがクラッシュしたポイントを調べるコマンドは "l *0xXXXXXXXX" です（XXX を EIP 値に置き換えてください）。

  現在、実行されていないカーネルを gdb でデバッグすることはできません。gdb が（誤って）カーネルがコンパイルされた開始オフセットを無視するためです。