（番外一）Arm32 中虛擬地址機制分析（Arm cortex-A系列 MMU作業機制分析）

Arm Cortex-A 系列 記憶體管理單元（MMU）

由于直接分析 linux arm32 mmu版 的啟動代碼會涉及到記憶體直接物理映射模式到開啟虛擬地址映射模式的轉換，這需要對 ARM32 中的虛擬地址實作機制有足夠的了解才行，本文通過分析Arm Cortex-A 系列記憶體管理單元來分析ARM32中的虛擬地址機制， Memory Management Unit 簡稱為 MMU ，它的一個最主要的功能就是進行地址轉換，將處理器發出的 虛擬地址 轉換為 物理地址 ，有了 MMU 的支持，才能讓我們更容易地設計處多任務作業系統，以及在作業系統上開發應用程式，如果學習過逆向分析，就知道不同的可執行檔案（區別于元件與可重定向檔案）的裝載地址（entry point）在一般情況下都是相同的，并且在不同的程式中，也會有極大概率訪問到相同的記憶體地址，為了防止沖突以及不必要的重定向任務， 虛擬地址 與地址轉換的概念應運而生，只要作業系統為每一個行程維護一個虛擬地址轉換表，這樣就可以通過地址轉換將處理器發出的相同地址轉換為不同的物理地址，程式中也不再存在訪問同一個地址發生沖突的問題，也有效阻止了一個行程非法讀寫另一個行程的記憶體資料的現象發生，

在不同的處理器架構中，虛擬地址轉換的實作往往各不相同，本文主要分析 Arm Cortex-A 系列處理器的 MMU 與虛擬地址轉換程序，

首先拋開理論，憑感覺簡單考慮一下處理器發出記憶體訪問請求后，按道理應該出現的一個操作流程：

• 1、首先處理器從記憶體中讀入一個指令，例如：ldr r0, [r1] ，而 r1 在之前已經被賦上了某個標號的值，這個值代表這個標號的所在地址，而此地址是一個虛擬地址，在程式原始碼 通過鏈接程序，將目標檔案鏈接為可執行檔案 的時候就已經確定下來了，可執行檔案和元件不同，可執行檔案沒有重映射表，所以當裝載到記憶體后，不會進行指令地址重映射操作，程式中的每一個指令對記憶體的認知就只局限在被鏈接的時候所分配的虛擬地址，處理器通過查看 opcode 發現這個指令需要寫記憶體，但是它知道這個是虛擬記憶體，通過這個記憶體地址直接找物理記憶體一定是一無所獲的，所以它將地址交給了另一個處理單元，即 MMU

• 2、 MMU 收到了虛擬地址后，它應該會通過某種映射機制來將此虛擬地址轉換為物理地址，這就需要在某處持續保存且更新這個映射資訊，但是由于片內高速快取資源是非常有限的，不可能將所有的映射資訊全部存盤在片內高速快取中，并且在設備重啟或掉電的時候，作業系統與其他應用程式會重新載入并運行，而不是繼續運行，所以也沒有必要將映射資訊持久化保存；這樣我們可以猜測這個映射資訊應該是會被保存在記憶體中的某個位置，并且很有可能為了提高查詢映射資訊的速度而將部分資訊存盤在高速快取中，

• 3、如果映射資訊在記憶體中，則 MMU 必須知道映射資訊位置的物理實際地址，而不是虛擬地址，要不然就發生永不停息的遞回查詢了，而這個物理地址必須是 MMU 事先知道的，比如存盤在記憶體中的固定位置， MMU 通過訪問記憶體能得到這個物理地址，或者是存盤在特殊的暫存器中， MMU 獲取到這個物理地址后才能找到映射資訊，并使用映射資訊把虛擬地址映射為物理地址，最后在此轉換得到的物理地址上執行 ldr 指令，

在上文中需要注意的資訊有以下兩點：

• 映射資訊與其存盤位置
• 映射資訊的物理地址

這兩點是支持地址轉換的重要元素，
現在通過手冊仔細閱讀 MMU 實作原理與作業機制，來驗證我們的猜想，這里我使用的手冊是 《Arm Cortex-A Series Programmer’s Guide》version 4 Chapter 9 （在本次分析中不涉及 Large Physical Address Extensions 技術），

通過閱讀手冊知道，Arm 中的 translation table 就對應著上文提到的映射資訊， MMU 通過查詢 translation table 來獲取虛擬地址與物理地址的映射關系，而這個查詢與轉換程序如何實作，則與這個所謂的 translation table 的結構與定義有著很大的關系，這就需要深入了解這個 translation table 的結構組織了，根據手冊描述，Arm 將可尋址的 4GB 大小的記憶體空間分為特定大小的塊，每一個塊被稱作頁（page），然后再給每一個塊建立一個映射關系表項來完成虛擬地址中的塊到物理地址中的塊的映射（這個與虛擬地址中的塊所對應的物理地址空間中的塊被稱作頁框 page frame），這個以分塊來映射的機制就叫做分頁技術（paging），為什么要分塊呢？可以想象一下如果將每一個位元組，甚至每一個位元都設定一個特定的映射關系，那需要多少空間來存盤這個映射資訊呢？如果每一個物理記憶體都被映射到了虛擬記憶體上，是不是所有物理記憶體上存盤的都是映射資訊？那就不用干別的事情了，所以要給虛擬地址空間進行磁區，每一個特定大小的塊做一個映射關系，每個塊內部地址映射關系則是線性的（虛擬地址空間塊中的每個位置到塊起始位置的偏移都與物理地址空間的塊中的相應位置到物理地址空間塊的起始位置的偏移相同），這樣就不用存盤過多的資訊了，但是這個塊又不能太大，不然如果每個應用行程都只占用一個塊中的很小空間，那么就會留下很多的記憶體碎片無法被利用，會產生極大的浪費，關于塊的大小，可以通過配置 translation table 表項的屬性來決定，Arm 留給了作業系統開發人員極大的可定制空間，

了解了映射機制后，來具體探究一下 translation table 的結構：
每個 translation table 都占據了一塊連續的物理地址，并將這塊物理地址分為大小相等的塊，每一塊代表一個表項 （translation table entry），可以認為 translation table 是一個陣列，每個元素都是一個 table entry，每個表項中都存盤有特定的資訊，或者是未映射，或者是映射到下一級 tranlation table（Arm 中的地址轉換可以是多級的，即通過多層映射來獲取虛擬地址對應的物理地址），或者是直接映射到一個物理地址上（Arm 中的地址轉換也可以是單級的，即表項中包含的地址即為虛擬地址所對應的物理地址），在沒有啟用 LPAE 技術時，Arm 最多可以分成兩級頁表，即 L1 translation table 與 L2 translation table，

現在我們有 translation table 了，也知道 translation table 的表項中存盤有映射地址資訊了，那問題是 MMU 獲得一個虛擬地址后，怎么知道去查詢哪個 translation table 和查詢 translation table 中的哪個表項？

查詢哪個地址轉換表

上文說過，想要查詢 translation table ， MMU 一定需要通過某種方式獲得這個 translation table 的實際物理地址，而這個物理地址就存盤在協處理器 CP15 的 C2 暫存器中（在 《ARM 體系結構與編程》第二版的第 178 頁有全部的 CP15 協處理器的暫存器的作用），叫做地址轉換表基址，當 MMU 收到一個虛擬地址，它通過查詢協處理器 CP15 的 C2 寄存器來獲取地址轉換表的基址，然后通過這個地址轉換表來進行地址轉換，當考慮多任務作業系統時，往往每一個行程都會存盤一個地址轉換表基址，當發生行程切換時，會將這個存盤的基址加載到處理器 CP15 的 C2 暫存器中，然后就能對這個行程對虛擬地址的訪問進行轉換作業了，

查詢哪個地址轉換表表項

MMU 收到的所有與記憶體訪問有關的資訊只有處理器傳過來的虛擬地址，所以查詢哪個表項這個問題只能通過這個虛擬地址本身來決定，對于 ARM32 平臺下，這個虛擬地址一定是 32bits 長的， MMU 使用虛擬地址的高 12bits 來決定查詢的地址轉換表項，虛擬地址高 12bits 表示的數值代表表項的下標索引，即從頭開始的 第幾個 表項（注意這個數值不代表偏移地址，而是代表“第幾個表項”），所以當設虛擬地址高 12bits 的值為 INDEX ，并且協處理器 CP15 的 C2 暫存器的值為 BASE 那這個表項在記憶體中的實際物理地址就是 INDEX * 4 + BASE ，從這一點我們也可以看出，我們用了高 12bits 去尋找一級地址轉換表的表項，還剩下 20 bits沒有使用，這就代表每個表項可以分割 2^20 bytes 的地址空間，即 1MB 的記憶體段，以類似的方式我們可以在虛擬地址中提取出二級地址轉換表表項的索引值，或者直接使用這 20bits 去映射物理記憶體，這些具體細節將在下文描述，

L1 Translation Table

上文已經解釋過如何定位一級地址轉換表，也提到了一級地址轉換表可以指向二級地址轉換表，也可以直接指向物理地址進行映射，現在來看一下一級地址轉換表的表項的結構來明確一下怎么分辨表項指向的是物理地址還是下一級地址轉換表，一級地址轉換表一共有 4096 個表項，每個表項的大小為 32bits，他將整個 4GB 虛擬記憶體空間分為 4096份，每份 1MB 大小，一級地址轉換表的表項一共有 4種，如下圖所示：

可以看到表項之間通過第0、1位來判斷表項的種類，像 00 代表沒有進行映射的表項，01 代表表項指向下一級（圖中的 Level 2 Descriptor Base Address ），即二級地址轉換表的基地址，而 10 的情況比較特殊，這兩個都是直接映射物理地址，但是 section 類表項代表直接映射 1MB 大小的物理地址空間，而 supersection 通過幾個表項組合的方式來映射 16MB 大小的物理地址空間，supersection 比較特殊，就不展開討論，這塊內容在手冊的 9.4 節有具體描述，在這里主要描述 01 表項的情況，我們注意到 Level 2 Descriptor Base Address 的大小為 22bits 這顯然不能覆寫所有 4GB 大小的記憶體空間，看來二級地址轉換表的存盤位置必定會受到限制，22bits 表示的大小可以將記憶體均勻分為 4194304 個區域，每個區域大小為 1KB，而 Arm 剛好定義二級地址轉換表的大小為 1KB，并且二級轉換表的起始位置為 1KB 對齊的，所以我們均勻分出來的 4194304 個區域，每個區域都正好能存盤一個二級地址轉換表，嗯，二級地址轉換表的基地址在記憶體中 1KB 對齊，并且大小為 1KB，這樣就能通過一級地址轉換表的表項中的 22bits 大小的 Level 2 Descriptor Base Address 來尋找二級地址轉換表，

L2 Translation Table

通過上文的方式我們已經找到了二級地址轉換表的位置，現在我們要利用二級地址轉換表繼續進行地址映射（注：我們已經利用了虛擬地址的高 12bits 來進行一級地址轉換表表項的尋址作業，只剩下 20bits 來尋找二級地址轉換表表項了），這里要強調一下，進行地址轉換的程序是不存在浪費地址空間的行為，即一級地址轉換表將記憶體劃分為 1MB 大小的塊，如果不進行直接物理地址映射的話，那么二級地址轉換表必須保證能夠將每個 1MB 的塊全部分配出去，現在我們還剩下 20bits，理論上可以進行 1MB 大小的記憶體尋址，但是需要利用這 20bits 的前幾位來尋找二級地址表的表項，后幾位來作為這個表項所映射的物理地址空間的地址偏移值，而我們也知道二級地址轉換表的大小為 1KB，如果我們利用前 8bits 來進行地址表項的尋找，這樣可以將轉換表分為 256 個表項，每個表項 4bytes，并且每個表項應該表示 1MB / 256 = 4KB 大小的頁框（上文已經提到頁框這個術語）的起始地址，而 4bytes 全部用來尋找頁框起始物理地址才能讓頁框的起始物理地址在記憶體的任意位置，但是為了給頁框加一些必要的訪問屬性（可讀可寫之類的屬性），不能用表項的全部 4bytes 表示頁框的起始物理地址，這樣就引出了經典問題，頁框的起始地址不能是 4GB 空間中的任意位置，當然如果細想一下也不應該是任意位置，如果一個頁框起始地址往上1KB又是另一個頁框的起始地址，那么這兩個頁框不就重疊了么？這必定會引起訪問沖突，所以最好的辦法還是讓 4KB 的頁框的起始地址以 4KB 進行對齊，這樣就能將 4GB 地址空間均勻分為 1048576 份，這個數量正好能用 20bits 來尋址，所以二級地址轉換表的表項中的 20bits 應該用于映射頁框，而剩下的 12bits 可以用來表示頁框的屬性，上述分析只是二級地址轉換表表項的其中一種表示方法，二及地址轉換表表項也有 3 個表示方法，如下圖所示：

未完待續