Linuxカーネルページテーブルを分析する目的でカーネルドライバーを作成していました。ドライバー内部から CR3 レジスタを読み取るたびに、CR3 の内容が読み取られるたびに異なることがわかりました。
なぜこれが起こるのですか？ドライバーはカーネル モードで実行されるため、CR3 はカーネル ページ ディレクトリを指す必要があります (そうですか?) では、CR3 が毎回変更されるのはなぜですか?
CR3 が変化し続ける場合、ドライバによるメモリ アクセスはどのように意図したとおりに正しく行われるのでしょうか?
他の人が言及したように、現在のプロセスの「ページテーブル」が表示されています。x86 では、3 未満の特権レベルを入力しても、ページ テーブルは変更されません。これが、ほとんどのオペレーティング システムがカーネル用に仮想アドレス空間のセクションを予約する理由です。そのスペースのメモリは、すべてのプロセスにマップされます。ページ フレームの u/s フラグを "0" に設定することで、カーネル アドレス空間のメモリをユーザー モード コードから隠すことができます。これにより、ユーザーメモリではなく「システム」メモリとしてマークされます。
ページ テーブルの変更は通常、カーネル モードに移行した後に行われます。これが、カーネル メモリがプロセスのアドレス空間の一部である必要がある理由です。そうしないと、データ構造がどこにあるのかわかりません。1 つの例外は、アドレス空間を透過的に切り替える「システム管理モード」です。ただし、これは「システム管理割り込み」に応答してのみ発生する可能性があり、マザーボードからの特別なハードウェア サポートが必要であり、設計上、オペレーティング システムによって抑制または応答することはできません。
それ以外の場合、保護モードでは、ページ テーブルの操作は、カーネル モードへの移行後に常に OS によって行われます。これが、「モード スイッチ」が完全なコンテキスト スイッチよりも高速である理由の一部です。
CR3 はページ ディレクトリ ポインタです。少なくともアドレス空間が変更されるたびに変更されます。単一の「カーネル」メモリ空間はありません。ほとんどの (すべての?) メモリ モデルでは、表示される CR3 値は、現在のアドレス空間コンテキスト (たとえば、syscall を処理しているプロセスなど) に固有のものになります。