淺析Linux 64位系統虛擬地址和物理地址的映射及驗證方法

時間 2020-12-23

標籤 html linux git 程序員 github ubuntu 架構 ide 佈局 post 欄目 Linux 简体版

原文原文鏈接

虛擬內存

先簡單介紹一下操做系統中爲何會有虛擬地址和物理地址的區別。由於Linux中有進程的概念，那麼每一個進程都有本身的獨立的地址空間。html

如今的操做系統都是64bit的，也就是說若是在用戶態的進程中建立一個64位的指針，那麼在這個進程中，這個指針可以指向的範圍是0~0xFFFFFFFFFFFFFFFF(總共有16個F，每一個F是4個bit)。linux

每一個進程「理論上」都有這樣的地址範圍（-，-這裏的」理論「是指猜想一下，指針亂指向未定義的範圍會引起段錯誤，下文中會寫明64bit的用戶空間的地址範圍）。git

咱們看到了，Linux爲了讓每一個進程空間的獨立，創造了虛擬地址這個概念。可是計算機最終仍是須要操做物理的內存的。
程序員

那麼虛擬地址和物理地址的映射關係是怎樣的？也只能用映射表了。好比說：進程A虛擬空間中的第0x1234個字節，對應於物理內存中的第0x823ABC個字節。這個一個字節和一個字節對應，理論上是能夠的，可是太消耗資源了，爲了映射這「一個字節」，僅映射這「一個字節」的表項的大小也遠超過了一個字節的大小（大約四十個字節左右）。這是不行的，這就像幾十個產品和項目經理去管一個程序員工做，這是效率低下的。
github

頁

因此頁這個概念產生了，一個頁一個頁映射總還能夠了吧，咱們將頁做爲最小單位去映射就行了。大多數32位體系結構支持4KB的頁，而64位體系結構通常會支持8KB的頁。在linux使用命令獲取當前系統的頁大小：ubuntu

getconf PAGE_SIZE

在個人ubuntu 16.04 x86_64上的系統獲得的結果是 4096。目前大部分64位的系統的頁大小都是4096個字節。
架構

系統中每一個物理頁都會創建一個相似映射表的結構體，可是依然會有人以爲這有點浪費內存。咱們來算一下，好比一個物理頁的屬性和映射表的內容佔用40個字節（linux代碼中是struct page）。假設如當前大部分Linux上的頁爲4KB大小，系統有4GB物理內存，那麼就有1048576個頁，這麼多頁的映射表消耗的內存是1048576 * 40byte = 40MB。用40MB去管理4GB，仍是能夠接受的。ide

64位系統的虛擬內存佈局

在AArch64下，頁大小爲4KB時，頁管理爲四級架構時的Linux的進程中的虛擬內存佈局以下：
佈局

能夠看到即便是虛擬地址，用戶態下能用的地址也就只是0 ~ 0000ffffffffffff，不過也有256TB大小了。也就是說每一個進程都有本身獨立的0 ~ 0000ffffffffffff的地址空間。0x0000ffffffffffff是12個f，也就是48個bit。post

每一個進程都有本身的虛擬地址到物理地址的映射關係表。Linux內核會根據每一個不一樣的進程去查找表：如進程A的虛擬空間地址K的物理地址是哪一個。爲了加快查找效率，虛擬內存的地址的不一樣段映射到了不一樣的entry上，頁管理表有4級的也有3級的。最經常使用的4級頁管理映射表以下：

能夠看到[47:0]這48個bits的虛擬地址，被分紅了五段，前四段的每一份長度都是9 bits，最後一段是12 bits。

每一個9 bits的段都是2^9 = 512，也就是說每一個分級段都有512個entry。

最後一段[11:0]，大小是12 bits的即2^12 = 4096，4096就是一個頁的大小，因此最後一段是頁內偏移（由於映射是以頁爲單位，因此虛擬地址和物理地址的頁內偏移都是同樣的）。前四段合在一塊兒就是虛擬頁號。

咱們舉一個48 bit 虛擬地址的例子，這個地址以八進制表示：

003 010 007 413 1056

上面所述的每一個Entry的結構體以下：

能夠看到物理地址的頁號是40 bits，也就是說最多有2^40個物理頁，每一個頁是4096個字節，也就是最多4PB（4096TB）。

虛擬地址到物理地址的驗證方法

說了這麼多，如何驗證上面說的這些是真的。就算推導出物理地址了，那又有啥用呢？

若是你知道共享庫和靜態庫的區別的話，那麼就會知道不一樣的進程若是用了同一個共享庫，那麼其實這兩個不一樣的進程使用的共享庫是指向同一個物理地址！若是能驗證這一點，那麼從虛擬地址推導到物理地址的方法大致是正確的，以上所述大致也是對的。

藉助proc下的maps和pagemap

經過man命令

man proc

能夠找到如下條目：

以上咱們知道經過/proc/[pid]/maps就可以知道一個進程的虛擬地址。

以上咱們知道經過/proc/[pid]/pagemap就可以將一個進程的虛擬地址頁轉成物理地址頁。

測試代碼

下面上硬菜。小夥子你要講武德，你不能閃！

代碼以下:

#include <fcntl.h>
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <unistd.h>

size_t virtual_to_physical(pid_t pid, size_t addr)
{
    char str[20];
    sprintf(str, "/proc/%u/pagemap", pid);
    int fd = open(str, O_RDONLY);
    if(fd < 0)
    {
        printf("open %s failed!\n", str);
        return 0;
    }
    size_t pagesize = getpagesize();
    size_t offset = (addr / pagesize) * sizeof(uint64_t);
    if(lseek(fd, offset, SEEK_SET) < 0)
    {
        printf("lseek() failed!\n");
        close(fd);
        return 0;
    }
    uint64_t info;
    if(read(fd, &info, sizeof(uint64_t)) != sizeof(uint64_t))
    {
        printf("read() failed!\n");
        close(fd);
        return 0;
    }
    if((info & (((uint64_t)1) << 63)) == 0)
    {
        printf("page is not present!\n");
        close(fd);
        return 0;
    }
    size_t frame = info & ((((uint64_t)1) << 55) - 1);
    size_t phy = frame * pagesize + addr % pagesize;
    close(fd);
    printf("The phy frame is 0x%zx\n", frame);
    printf("The phy addr is 0x%zx\n", phy);
    return phy;
}

int main(void)
{
    while(1)
    {
        uint32_t pid;
        uint64_t virtual_addr;
        printf("Please input the pid in dec:");
	scanf("%u", &pid);
        printf("Please input the virtual address in hex:");
	scanf("%zx", &virtual_addr);
	printf("pid = %u and virtual addr = 0x%zx\n", pid, virtual_addr);
        virtual_to_physical(pid, virtual_addr);
    }
    return 0;
}

首先，我編譯一下！

gcc test.c -o haha

而後，我拷貝一下！

cp haha hahatest1; cp haha hahatest2; cp haha hahamonitor

接着，我運行一下！

nohup  ./hahatest1 &
[1] 3943
nohup  ./hahatest2 &
[2] 3944
sudo ./hahamonitor

這裏你可能已經發現個人意圖了，我是用進程hahamonitor查看進程hahatest1和進程hahatest2的內存地址。

可是你不能大意，運行hahamonitor 必定要加sudo或者root權限，否則讀出來就都是0了。

先看看hahatest1和hahatest2進程的地址空間：

zbf@zbf:~$ cat /proc/3943/maps 
00400000-00401000 r-xp 00000000 08:06 11150436                           /home/zbf/physic_virtual_memory/hahatest1
00600000-00601000 r--p 00000000 08:06 11150436                           /home/zbf/physic_virtual_memory/hahatest1
00601000-00602000 rw-p 00001000 08:06 11150436                           /home/zbf/physic_virtual_memory/hahatest1
011ad000-011cf000 rw-p 00000000 00:00 0                                  [heap]
7ffbf1b64000-7ffbf1d24000 r-xp 00000000 08:06 20714662                   /lib/x86_64-linux-gnu/libc-2.23.so
7ffbf1d24000-7ffbf1f24000 ---p 001c0000 08:06 20714662                   /lib/x86_64-linux-gnu/libc-2.23.so
7ffbf1f24000-7ffbf1f28000 r--p 001c0000 08:06 20714662                   /lib/x86_64-linux-gnu/libc-2.23.so
7ffbf1f28000-7ffbf1f2a000 rw-p 001c4000 08:06 20714662                   /lib/x86_64-linux-gnu/libc-2.23.so
7ffbf1f2a000-7ffbf1f2e000 rw-p 00000000 00:00 0 
7ffbf1f2e000-7ffbf1f54000 r-xp 00000000 08:06 20714659                   /lib/x86_64-linux-gnu/ld-2.23.so
7ffbf2133000-7ffbf2136000 rw-p 00000000 00:00 0 
7ffbf2153000-7ffbf2154000 r--p 00025000 08:06 20714659                   /lib/x86_64-linux-gnu/ld-2.23.so
7ffbf2154000-7ffbf2155000 rw-p 00026000 08:06 20714659                   /lib/x86_64-linux-gnu/ld-2.23.so
7ffbf2155000-7ffbf2156000 rw-p 00000000 00:00 0 
7ffd2529f000-7ffd252c0000 rw-p 00000000 00:00 0                          [stack]
7ffd25302000-7ffd25305000 r--p 00000000 00:00 0                          [vvar]
7ffd25305000-7ffd25307000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

zbf@zbf:~$ cat /proc/3944/maps 
00400000-00401000 r-xp 00000000 08:06 11150444                           /home/zbf/physic_virtual_memory/hahatest2
00600000-00601000 r--p 00000000 08:06 11150444                           /home/zbf/physic_virtual_memory/hahatest2
00601000-00602000 rw-p 00001000 08:06 11150444                           /home/zbf/physic_virtual_memory/hahatest2
01e8b000-01ead000 rw-p 00000000 00:00 0                                  [heap]
7fe786964000-7fe786b24000 r-xp 00000000 08:06 20714662                   /lib/x86_64-linux-gnu/libc-2.23.so
7fe786b24000-7fe786d24000 ---p 001c0000 08:06 20714662                   /lib/x86_64-linux-gnu/libc-2.23.so
7fe786d24000-7fe786d28000 r--p 001c0000 08:06 20714662                   /lib/x86_64-linux-gnu/libc-2.23.so
7fe786d28000-7fe786d2a000 rw-p 001c4000 08:06 20714662                   /lib/x86_64-linux-gnu/libc-2.23.so
7fe786d2a000-7fe786d2e000 rw-p 00000000 00:00 0 
7fe786d2e000-7fe786d54000 r-xp 00000000 08:06 20714659                   /lib/x86_64-linux-gnu/ld-2.23.so
7fe786f33000-7fe786f36000 rw-p 00000000 00:00 0 
7fe786f53000-7fe786f54000 r--p 00025000 08:06 20714659                   /lib/x86_64-linux-gnu/ld-2.23.so
7fe786f54000-7fe786f55000 rw-p 00026000 08:06 20714659                   /lib/x86_64-linux-gnu/ld-2.23.so
7fe786f55000-7fe786f56000 rw-p 00000000 00:00 0 
7fffd3388000-7fffd33a9000 rw-p 00000000 00:00 0                          [stack]
7fffd33ce000-7fffd33d1000 r--p 00000000 00:00 0                          [vvar]
7fffd33d1000-7fffd33d3000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

能夠看到這兩個進程都連接了/lib/x86_64-linux-gnu/libc-2.23.so這個動態庫，在進程3943（hahatest1）中的虛擬地址是：7ffbf1b64000，但在進程3944中的虛擬地址是：7fe786964000

咱們用hahamonitor康康它們的最終的物理地址都是什麼？

zbf@zbf:~/$ sudo ./hahamonitor 
Please input the pid in dec:3943
Please input the virtual address in hex:7ffbf1b64000
pid = 3943 and virtual addr = 0x7ffbf1b64000
The phy frame is 0x12ee58
The phy addr is 0x12ee58000

Please input the pid in dec:3944
Please input the virtual address in hex:7fe786964000
pid = 3944 and virtual addr = 0x7fe786964000
The phy frame is 0x12ee58
The phy addr is 0x12ee58000

能夠看到物理地址是同樣的，都是0x12ee58000。另外我也實驗過這兩個進程對應的堆棧的物理地址都是不同的，這就對了！

有興趣的朋友能夠自行下載代碼跑一下。

若是你看到了這裏並以爲有點收穫，請幫忙點一下下面的推薦好文要頂（）按鈕，很是感謝~

參考資料: