前言
有好久沒更新了，和物這段時間發生了挺多大喜事哈。理地但是址的證方也還是有挺久沒更新了，不得不意識到自己是映射個小菜雞，就算是及驗小菜雞也要做一只快樂小菜雞。就算更新慢但是淺析我依然會持續更新，因為更文使我快樂。系統虛擬
虛擬內存
先簡單介紹一下操作系統中為什么會有虛擬地址和物理地址的地址區別。因為Linux中有進程的和物概念，那么每個進程都有自己的理地獨立的地址空間。
現在的址的證方操作系統都是64bit的，也就是映射說如果在用戶態的進程中創建一個64位的指針，那么在這個進程中，這個指針能夠指向的范圍是0~0xFFFFFFFFFFFFFFFF(總共有16個F，每個F是4個bit)。
每個進程“理論上”都有這樣的地址范圍（-，-這里的”理論“是指猜測一下，指針亂指向未定義的范圍會引發段錯誤，下文中會寫明64bit的用戶空間的地址范圍）。
我們看到了，Linux為了讓每個進程空間的獨立，創造了虛擬地址這個概念。但是計算機最終還是需要操作物理的內存的。
那么虛擬地址和物理地址的映射關系是怎樣的？也只能用映射表了。比如說：進程A虛擬空間中的第0x1234個字節，對應于物理內存中的第0x823ABC個字節。這個一個字節和一個字節對應，理論上是可以的，但是太消耗資源了，為了映射這“一個字節”，僅映射這“一個字節”的表項的大小也遠超過了一個字節的大小（大約四十個字節左右）。這是不行的，這就像幾十個產品和項目經理去管一個程序員工作，這是效率低下的。
頁
所以頁這個概念產生了，一個頁一個頁映射總還可以了吧，我們將頁作為最小單位去映射就好了。大多數32位體系結構支持4KB的頁，而64位體系結構一般會支持8KB的頁。在linux使用命令獲取當前系統的頁大小：
getconf PAGE_SIZE
在我的ubuntu 16.04 x86_64上的系統得到的結果是 4096。目前大部分64位的系統的頁大小都是4096個字節。
系統中每個物理頁都會建立一個類似映射表的結構體，但是依然會有人覺得這有點浪費內存。我們來算一下，比如一個物理頁的屬性和映射表的內容占用40個字節（linux代碼中是struct page）。假設如當前大部分Linux上的頁為4KB大小，系統有4GB物理內存，那么就有1048576個頁，這么多頁的映射表消耗的內存是1048576 * 40byte = 40MB。用40MB去管理4GB，還是可以接受的。
64位系統的虛擬內存布局
在AArch64下，頁大小為4KB時，頁管理為四級架構時的Linux的進程中的虛擬內存布局如下：
可以看到即使是虛擬地址，用戶態下能用的地址也就只是0 ~ 0000ffffffffffff，不過也有256TB大小了。也就是說每個進程都有自己獨立的0 ~ 0000ffffffffffff的地址空間。0x0000ffffffffffff是12個f，也就是48個bit。
每個進程都有自己的虛擬地址到物理地址的映射關系表。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
#include
#include
#include
#include
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。另外我也實驗過這兩個進程對應的堆棧的物理地址都是不一樣的，這就對了！
有興趣的朋友可以自行下載代碼跑一下。
參考資料:
- https://www.kernel.org/doc/html/v4.19/admin-guide/mm/pagemap.html
- https://www.kernel.org/doc/Documentation/vm/pagemap.txt
- https://www.kernel.org/doc/html/latest/arm64/memory.html
- https://constantsmatter.com/posts/virtual-address/
- 程序喵大人：https://mp.weixin.qq.com/s?__biz=MzI3NjA1OTEzMg==&mid=2247484681&idx=1&sn=45b7d8f38402622718fcdc10ba77f443&chksm=eb7a039adc0d8a8cc6bb635fcb8a3f2f567e064f9c0ee863297c90f486394b788de5c3fe6dbd&mpshare=1&scene=1&srcid=1129bC44tMBu7lpXza2ki1k6&sharer_sharetime=1606655711296&sharer_shareid=741c39217c916aaf06bf9827e80dbff6&exportkey=AX19wECY41gfhbceNfjn7ws%3D&pass_ticket=Tv1TS4ibFzi6ZvNrbr2emqQu9boZCHYlwz5dSAFLvlJHUrIsSAibiRbzFP%2FmiurU&wx_header=0#rd
- https://zhou-yuxin.github.io/articles/2017/Linux%20%E8%8E%B7%E5%8F%96%E8%99%9A%E6%8B%9F%E5%9C%B0%E5%9D%80%E5%AF%B9%E5%BA%94%E7%9A%84%E7%89%A9%E7%90%86%E5%9C%B0%E5%9D%80/index.html
往期推薦
免責聲明：本文內容由21ic獲得授權后發布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯系我們，謝謝！
