現代作業系統管理記憶體,到底是分段還是分頁,段暫存器還有用嗎?

  • 2021 年 9 月 14 日
  • 筆記

大家好,我是你們的老朋友軒轅。

點進這篇文章的朋友,恭喜你們,又要收穫新知識了~

這又是一篇非常硬核的技術文,建議配合一瓶怡寶或營養快線食用,效果更好哦。

很多小夥伴在學作業系統的時候,學習到記憶體管理的部分時,都會接觸到分段記憶體管理、分頁記憶體管理。

但很多人學完以後一頭霧水:

到底現在用的是分段還是分頁?
段暫存器這個東西現在還在用嗎?
為什麼在講到虛擬地址翻譯的時候,好像跟段又沒有關係了呢?

之所有有這個問題,是因為很多同學看的教程很多都是偏理論的或者是過時的,根本不給你講現代作業系統中實際的情況(關於這一點我已經吐槽很多次了)。

今天軒轅就帶大家把記憶體管理的這些疑問一次性弄清楚,分段還是分頁,別再傻傻分不清楚了!

Let’s go!

在開始之前,我們還是先來簡單複習一下,作業系統書上講到的Intel x86 CPU架構下的分段式記憶體管理和分頁式記憶體管理。

分段式記憶體管理

早在16位的8086時代,CPU為了能定址超過16位地址能表示的最大空間(64KB),引入了段暫存器。

通過將記憶體空間劃分為若干個段,然後採用段基地址+段內偏移的方式訪問記憶體,這樣能訪問1MB的記憶體空間了!

那時候,段暫存器有4個,分別指向不同的段。

cs: 程式碼段
ds: 數據段
ss: 棧段
es:擴展段

在那個時候,段暫存器中存放的是段基地址,注意,是一個地址。

在通過ip暫存器讀取指令的時候,實際上是cs:ip,通過sp暫存器訪問棧的時候,實際上是ss:sp。

我看到網路上很多文章介紹分段式記憶體或者介紹段暫存器的時候就止步於此了,而事實上,進入32位時代後,情況已經發生了翻天覆地的變化,只講上面這一部分內容實際上會誤導很多人。

變化1:

在32位時代,段暫存器又增加了兩個:fs、gs,這兩個段暫存器有特殊用途。

變化2:

段暫存器裡面存放的不再是段基地址,而是一個叫段選擇子的東西。注意,注意,一切的變化都從這裡開始。

段暫存器是16位的寬度,原來這16位是個物理記憶體地址,但現在,它是這樣一個結構:

實際上,現在的段暫存器中存放的是一個號碼,什麼號碼呢?是一個表格中表項的號碼,這個表,有可能是全局描述符表GDT,也有可能是局部描述符表LDT。

那到底是哪個表?是由段選擇子從低到高的第三位來決定的,如果這一位是0,則是GDT,否則就是LDT。

那這兩個表又是啥,表裡面裝的又是什麼,怎麼來定址呢?

這兩個表的表項叫做段描述符,描述了一個記憶體段的資訊,比如段的基地址、最大長度、訪問屬性等等一系列資訊,它長這個樣子:

CPU中單獨添置了兩個暫存器,用來指向這兩個表,分別是gdtr和ldtr。

在定址的時候,CPU首先根據段暫存器中的號碼,通過gdtr或ldtr來到GDT/LDT中取出對應的段描述符,然後再取出這個段的基地址,最後再結合段內的偏移,完成記憶體定址。

 

也就是說,在16位模式下,段暫存器中直接就是一個地址,相當於一個指針,而到了32位下,則變成了一個句柄,或者說二級指針了。

分頁式記憶體管理

相比分段式記憶體管理,可能大家對分頁式記憶體管理要熟悉的多。

作業系統將記憶體空間按照「頁」為單位劃分了很多頁面,這個頁的大小默認是4KB(當然可以改的),各進程擁有虛擬的完整的地址空間,進程中使用到的頁面會映射到真實的物理記憶體上,程式中使用的地址是虛擬地址,CPU在運行時自動將其翻譯成真實的物理地址。

既然要翻譯,那就得有地方記錄虛擬地址和物理地址的映射關係,只有根據這個關係,才能完成翻譯。

這個映射關係,是通過頁表來完成的。

頁表是用來記錄虛擬記憶體頁面和物理記憶體頁面之間的映射關係的,每一個頁表項記錄一個頁面的映射關係。但進程的地址空間很大,這樣算下來需要的頁表項的數量也會非常多。而實際上進程地址空間中很多頁面都沒有真正使用,也就沒有映射關係,這樣是一種浪費。

為了解決這個問題,CPU引入了多級頁表的機制,在32位下一般是2級頁表,像下面這樣:

將虛擬地址劃分了三段:頁目錄索引、頁表索引、頁內偏移。

執行緒切換時,如果同時發生了進程切換,CPU中的CR3暫存器將會載入當前進程的頁目錄地址。

在定址的時候,通過CR3,一級一級按表索頁,最終找到對應的物理記憶體頁面,再結合頁面內的偏移值,實現最終的記憶體定址。

現代作業系統實際情況

學完了這兩種記憶體管理方式,很多人就要懵了:

現在作業系統到底用的哪種方式? 好像是分頁,但為什麼段暫存器好像還是有,到底是怎麼一回事?

先說結論,答案就是:分段+分頁相結合的記憶體管理方式

首先要明確一個前提,這一點非常非常重要:無論是分段還是分頁,這都是x86架構CPU的記憶體管理機制,這倆是同時存在的(保護模式下),並不是讓作業系統二選一!

既然是同時存在的,那為什麼現在將記憶體地址翻譯時,都是講分頁,而很少談到分段呢?

這一切的一切,都是因為一個原因:作業系統通過巧妙的設置,『屏蔽』了段的存在。

作業系統怎麼做到這一點的,接下來我們就來分析一下,徹底弄清楚背後的貓膩!

段暫存器

讓我們從段暫存器出發,在Win7 32位系統上,使用調試器(我用的WinDbg)隨意調試一個程式,真的,隨意,記事本、瀏覽器、Word,你看上誰就調試誰。

在中斷的上下文中看一下,程式在執行時,段暫存器裡面到底裝了啥?

來看下幾個主要的段暫存器的內容:

cs: 001b
ds: 0023
ss: 0023
es: 0023

PS: 可能不同版本的Windows上面的結果不一樣,但這不重要,不影響我們分析問題。

只有0x001b和0x0023兩個值,前面我們說了,這不是一個地址,而是一個段選擇子,按照段選擇子的格式展開來看一下這兩個值指向的是哪個段描述符:

十六進位:001b
二進位:0000000000011 0 11 – 段序號:3 – 表類型:GDT – 特權級:Ring3
十六進位:0023
二進位:0000000000100 0 11 – 段序號:4 – 表類型:GDT – 特權級:Ring3

也就是說,cs段指向的是GDT中的第3個表項,其他三個暫存器指向的是GDT中的第4個表項。

接下來,我們來看一下這個神秘的GDT裡面的內容到底是什麼?很多人學了記憶體管理,可能還從來沒看過真實的GDT裡面到底是什麼數據吧。

GDT是位於作業系統內核地址空間中的,在Windows上有兩種查看方式,一種是通過Windbg,一種是通過一些ARK工具,我這裡選擇使用PChunter這個神器進行查看。

前面提到過,GDT中的表項是段描述符,這是一個比較複雜的數據格式,好在,這個神器對段描述符進行了解析,使用表格欄位的方式進行了展示,讓我們看起來輕鬆多了。

廢話不多說了,來看一下這個神秘的GDT吧:

注意看第3個表項和第4個表項哦,看看它們的基地址,都是0x00000000

再看它們的界限值,都是0x000FFFFF,注意看這個界限的單位,不是位元組,而是Page——頁,把這個值乘以頁面的大小4KB,就是0xFFFFF000。也就說這個段的上限到了0xFFFFF000這個頁面,再把這一個頁面的大小加進去,就是0xFFFFFFFF了!

所以,重點來了!看到了嗎,GDT中的第3個和第4個表項所描述的這兩個段,它們的基地址都是0x00000000,整個段的大小都是0xFFFFFFFF,這意味著什麼?這意味著整個進程的地址空間實際上就是一個段!

也就是說:進程的程式碼段、數據段、棧段、擴展段這四個段全部重合了,而且是整個進程地址空間共計4GB成為了一個段。

說起來是分段,實際上等於沒分了,再加上段的基地址全部是0,那進行地址翻譯的時候,有沒有段都沒什麼區別了。

總結一句話:作業系統這樣分段,實際上是相當於把段給架空了!

以上是Windows的情況,我們再來看一下Linux情況呢。

使用GDB隨意調試一個ELF32的可執行文件,使用info r命令查看一下暫存器情況:

段暫存器有0x23和0x2b兩種情況:

十六進位:0023
二進位:0000000000100 0 11 – 段序號:4 – 表類型:GDT – 特權級:Ring3
十六進位:002B
二進位:0000000000101 0 11 – 段序號:5 – 表類型:GDT – 特權級:Ring3

Linux下我沒有找到可以直接用什麼命令或者工具查看GDT的方式(如果你知道記得一定告訴我哦),於是去源程式碼中尋找答案:

看到了嗎,這兩項所描述的段和Windows一樣,基地址為0,大小為4GB。

Windows和Linux都選擇了通過這種方式架空了CPU的分段記憶體管理機制。

但需要說明一下的時,雖然兩個作業系統都是這種情況,但並不意味著段機制徹底沒用到,CPU的任務管理TSS還是需要用到,這一點大家知道就行了。

64位情況

看到作業系統們都不待見這個分段式記憶體管理,Intel似乎也感受到了這玩意確實很雞肋,於是到了64位平台,徹底把段暫存器給打入了冷宮!

在Intel的指令手冊中,關於64位下的段暫存器是這樣描述的:

不管你的段暫存器中指向的段基址是什麼內容,都會被當成0來對待。

這一下,分段記憶體管理,徹底涼涼了···

總結

好了,最後來總結一下。

無論是分段還是分頁,這是CPU自身的機制,作業系統在管理記憶體時繞不過去,但通過巧妙的分段記憶體設計,相當於把分段的概念給屏蔽了,由此造成了我們平時在談論虛擬地址翻譯時,忘記了段的存在,但不代表它真的不存在。

CPU硬體層面的工作必須是結合分段+分頁的記憶體管理機制,作業系統是軟體繞不過去,所以採取了上面的方式應付CPU了事。

從16位到32位再到如今普遍的64位,不同的時代,分段管理的實際情況都不一樣,大家在學習作業系統的時候一定不要死記硬背,而要結合實際情況哦。

現在分段和分頁,你弄清楚了嗎?

覺得有收穫的話,幫忙給軒轅分享轉發支援一下啊~