Linux頁面表的過程

Question

Intel core i5, Ubunu 16.04

我在讀有關內存分頁這里現在試圖用它來試驗。 我寫了一個簡單的匯編程序來獲取Segmentation Fault並在gdb中運行。 這里是：

 section .text
     global _start

 _start:
     mov rax, 0xFFFFFFFFFFFF0A31
     mov [val], eax
     mov eax, 4
     mov ebx, 1
     mov ecx, val
     mov edx, 2

     int 0x80

     mov eax, 1
     int 0x80

 segment .bss
     dummy resb 0xFFA
     val resb 1

我將它組裝並鏈接到64位ELF靜態可執行文件中。

據我所知，每個進程都有自己的頁表， cr3注冊指向該表。 現在我想自己查看頁面表？ 是否有可能在Linux中找到有關進程頁表的信息？

Answer 1

您需要將編譯為內核模塊的程序讀取頁表。 我相信有些項目可以做到這一點。

看看這里： https ： //github.com/jethrogb/ptdump

似乎描述了你想要的東西

Answer 2

您可以在/proc/PID/smaps看到進程的所有映射。 這告訴您在不獲取SIGSEGV的情況下可以訪問的內容。

這是不一樣的東西作為你的CR3頁表，因為內核並不總是“線”所有的映射。 即硬件頁面錯誤並不總是SIGSEGV：內核頁面錯誤處理程序檢查您的進程是否邏輯上已映射該內存並更正該情況，或者您是否確實違反了內存保護。

---

在mmap()系統調用之后，或者在進程啟動以映射文本/數據/ BSS段時，您在邏輯上已經映射了內存，但Linux可能已經決定是懶惰的並且還沒有提供任何物理頁面。 （例如，頁面可能尚未在頁面緩存中，因此在您嘗試實際觸摸該內存並出現頁面錯誤之前無需阻止）。

或者對於BSS內存，多個邏輯頁面可能會開始寫入映射到零的相同物理頁面的寫入時復制。 盡管根據Unix語義，您的內存是讀寫的，但頁表實際上只具有只讀映射。 編寫頁面會出現頁面錯誤，內核會在新的零物理頁面指向該條目，然后在出現故障的指令返回到您的進程（然后將重新運行並成功）。

無論如何，這並不直接回答你的問題，但可能是你真正想要的一部分。 如果你想深入了解，那么確實可以看到實際的頁面表，但通常不需要這樣做。 smaps可以告訴你有多少映射駐留在內存中。

另請參閱/ proc / pid / smaps中pss的含義，了解字段的含義。

---

順便說一下 ， 為什么在64位虛擬地址與物理地址（52位長）相比，4位短（48位長）？ 一個很好的4級頁表格式圖（以及2M / 1G大頁面如何適應）。

Answer 3

我寫了一個簡單的匯編程序來獲取Segmentation Fault並在gdb中運行....據我所知，每個進程都有自己的Page表，其中cr3注冊指向。 現在我想自己查看頁面表？ 是否有可能在Linux中找到有關進程頁表的信息？

操作系統維護頁表。 它們受到保護，不受用戶模式訪問（正如您嘗試的那樣）。

要了解保護的工作原理，您需要了解處理器模式（例如，內核和用戶）之間的差異以及處理器在這些模式之間切換的方式。

但是，簡而言之，嘗試編寫代碼來檢查頁面表是否是一個死胡同。 您最好從書本中學習頁表結構，而不是嘗試編寫代碼。 我建議查看英特爾手冊。

https://software.intel.com/en-us/articles/intel-sdm

可悲的是，這是相當干燥的，英特爾編寫了我見過的最糟糕的處理器手冊。 我建議專門查看64位模式。 英特爾的32位過於復雜。 如果有關於段的討論，那么您正在讀取32位並且可以忽略它。 英特爾的文檔從未指定地址是物理的還是邏輯的。 因此，您可能需要查看在線講座以進行說明。

要補充此讀數，您可以查看Linux源代碼。 https://github.com/torvalds/linux

總而言之，您需要兩個先決條件才能到達目的地：（1）處理器模式; （2）頁表結構。