Linux之x86 處理器如何進行層層的內存保護?
實模式:bootloader 為程序計算段的基地址
保護模式:bootloader 為自己創(chuàng)建段描述符
確定 GDT 的地址
創(chuàng)建代碼段的描述符
創(chuàng)建數據段的描述符
創(chuàng)建棧段的描述符
段描述符是如何確保段的安全的?
段寄存器高速緩存
對段寄存器本身的保護
對段界限的檢查
在上一篇文章中,我們已經順利的從實模式,過渡到了保護模式。
保護模式與實模式最本質的區(qū)別就是:保護模式使用了全局描述符表,用來保存每一個程序(bootloader,操作系統,應用程序)使用到的每個段信息:開始地址,長度,以及其他一些保護參數。
這篇文章,我們來看一下 bootloader 是如何來進行自我進化到保護模式的,然后深入看一下保護模式是如何對內存進行安全保護的。
作為背景知識,我們先來看一下 x86 中的地址變換過程:
x86 處理器中的分頁機制是可以被關閉的,此時線性地址就等于物理地址,這也是我們一直討論的情況。
下一篇文章,我們就把 x86 中的分頁機制打開,并與 Linux 中的分段和分頁機制進行對比。
實模式:bootloader 為程序計算段的基地址
在之前的文章:Linux從頭學06:16張結構圖,徹底理解【代碼重定位】的底層原理中,我們討論了 bootloader 是如何把應用程序讀取到內存中,最后跳入到程序的入口地址的。
這里所說的程序,可以是操作系統,也可以是應用程序。
下面這張圖,是程序被加載到內存中之后,header 中的信息:
因為程序是被 bootloader 動態(tài)讀取到內存中的,它是不知道自己被放在內存中的什么位置,因此它也不知道自己代碼段、數據段、棧的開始地址。
但是,程序要想能夠正常執(zhí)行,就必須要知道這些信息,那怎么辦?
只有 bootloader 才能解決問題,因為是它來把程序從硬盤加載到內存中的。
因此,bootloader 在跳入程序的入口地址之前,必須把其中的代碼段、數據段、棧段的基地址計算出來,然后寫入到程序的 header 中,如下圖所示:
這樣的話,程序開始執(zhí)行時,就可以從自己的 header 中獲取到這 3 個段基地址,并且賦值給相應的寄存器,從而順利的執(zhí)行程序。
也就是說:程序的 header 空間,充當了 bootloader 與它進行信息交互的媒介,用來傳遞 3 個段寄存器的基地址。
以上的這個過程,一直工作在實模式,因此就沒有段描述符什么事情。
在以后文章中,我們還會看到在保護模式下,bootloader 仍然會利用 OS 的 header 空間,來傳遞段的索引號。然后 OS 利用這個段索引號,去查找 GDT 表,從而找到每一個段的基地址以及其他一些保護信息。
保護模式:bootloader 為自己創(chuàng)建段描述符
bootloader 從 BIOS 接管系統之后,剛開始是運行在實模式下的。
當它完成一些準備工作之后,就可以進入保護模式了,也就是把 CR0 寄存器的 bit0 設置為 1。
這個準備工作中,最重要的就是:建立 GDT 這個表,并且把 GDT 的開始地址,存儲到寄存器 GDTR 中。
下面這張圖,是 bootloader 被加載到內存中的布局圖:
bootloader 被加載到 0x0000_7C00 地址處。
它最少需要創(chuàng)建 3 個段描述符:代碼段、數據段和棧段。
確定 GDT 的地址
在創(chuàng)建段描述符之前,需要先確定: 把 GDT 表放在內存中的什么位置?
暫且就把它放在 0x0001_0000 這個地址吧,距離零地址 64K 的位置。
按照處理器的要求,在第 1 個表項(稱之為 item 或者 entry,每本書上都不一樣)必須為空描述符(index = 0)。
創(chuàng)建代碼段描述符
bootloader 的代碼放在 0x0000_7C00 開始的地址,長度是 512B。
根據這些信息,就可以構造出代碼段的描述符了:
創(chuàng)建數據段描述符
bootloader 待會需要把操作系統或其他應用程序,從硬盤讀取到內存中,例如:讀取到 0x0002_0000 的位置。
那么 bootloader 就必須能夠訪問到這個位置,并且是以數據段的讀寫方式。
為了利用全部的 4G 內存空間,bootloader 可以把這 4G 空間,作為一個數據段來定義它的描述符,如下:
創(chuàng)建棧段描述符
理論上,bootloader 可以使用內存中的任意一塊空閑空間,來作為自己的棧。
因為棧在 push 操作的時候,是向低地址方向增長的。
因此很多書籍都會把棧頂基地址設置為 bootloader 的開始地址,也就是 0x0000_7C00 地址處,并且把棧的空間大小限制在 4K 的范圍。
根據以上這些信息,就可以創(chuàng)建出棧的段描述符,如下:
當以上這幾個段的描述符都創(chuàng)建好之后,就可以把 GDT 的地址(0x0001_0000),設置到 GDTR 寄存器中了。
最后,再把 CR0 寄存器的 bit0 設置為 1,就正式的進入保護模式來執(zhí)行 bootloader 中后面的代碼了。
段描述符是如何確保段的安全訪問的? 段寄存器高速緩存
進入保護模式之后,雖然對段寄存器中內容的解釋改變了,但是執(zhí)行每一條指令,還是需要使用到這些段寄存器的: cs, ds, ss等等。
想象一下:每執(zhí)行一條指令,都會從邏輯地址中,獲取到段索引號,然后去查找 GDT 表,從而定位到段的基地址。
大家都知道程序有個“局部性”原理,也就是連續(xù)執(zhí)行的代碼,都是集中在一段連續(xù)的程序空間中的。
這個連續(xù)的程序空間,它們都是在同一個代碼段中,因此段的基地址都是相同的,那么它們都屬于 GDT 中同一個代碼段描述符所代表的段空間。
如果每一條指令都去查表,就會影響到程序的執(zhí)行效率。
所以,處理器內部就為每一個段寄存器,安排了一個高速緩存。
拿代碼段寄存器 cs 來說:當執(zhí)行一條指令的時候,如果它與上一條指令中的段索引號不同,才會根據新的段索引號到 GDT 中查找相應的段描述符表項。
查找到之后,就把這個表項的內容復制到 cs 寄存器的高速緩存中。
當繼續(xù)執(zhí)行后面的指令時,如果邏輯地址中的段索引號沒有變化,處理器就直接從高速緩存中讀取段描述,從而避免了查表操作,提升了系統效率。
對段寄存器本身的保護
當邏輯地址中段寄存器的索引號改變時,就會根據新的索引號,到 GDT 中去查表。
當然了,這個索引號不能超過 GDT 的界限。
當定位到某一個描述符表項之后,就開始進行一系列檢查。
再來看一下每一個段描述符中 8 個字節(jié)的內容:
bit8 ~ bit11 定義了當前這個段的類型。
假如: 我們在切換代碼段空間的時候,不小心犯錯,定位到了 GDT 中的一個數據段描述符表項,那么處理器就能夠及時發(fā)現:
“當前這個段描述符的類型是數據段,你卻把它當做代碼段來使用,禁止,殺無赦!”
因此,處理器就會拒絕把這個段描述符復制到代碼段的高速緩存中,從而對代碼段寄存器進行了保護。
對段界限的檢查
在通過了第一層的段類型保護之后,還會繼續(xù)對段的界限進行檢查,這就要使用到邏輯地址中的偏移地址( EIP )了。
如果偏移地址超過了描述符中規(guī)定的界限,那么就說明發(fā)生錯誤了。
例如:在 bootloader 的代碼段描述符中,最大的界限是 512B,如果把 EIP 設置為 0x0000_1000,那就肯定錯誤了。
因為這個地址壓根就不屬于代碼段的空間范圍。
對于數據段來說比較有意思,因為我們把數據段描述符的基地址設置為 0x0000_0000,段的界限是整個 4G 的空間,所以它可以對整個內存進行操作。
多想一步:
代碼段也是屬于這 4G 空間,因此可以通過數據段,來改寫代碼段空間中的指令內容。
也就是說:如果你想修改代碼段的指令,直接通過代碼段來操作是不可以的。
因為代碼段描述符中規(guī)定了:代碼段的內容只能被讀取、執(zhí)行,但是不能被寫入。
此時,就可以另辟蹊徑:代碼段也放在 4G 的空間,那么就可以通過數據段的可寫特性,來改寫代碼段中的指令。
想一想 gdb 的調試過程,是不是就利用了這個道理?
在文末的推薦閱讀中,就有一篇文章來介紹 gdb 的調試原理,有興趣的小伙伴可以看一下。
------ End ------
至此,我們對保護模式下,段描述符的相關內容,就全部討論結束了,不知道對你是否有幫助。
在準備這篇文章的時候,我特意看了一下 《深入理解 Linux 內核》這部書的第二章:"內存尋址"部分的內容。
書中直接把 x86 處理器中實模式和保護模式的尋址方式作為結論告訴我們了,但是并沒有具體的講解其中的原理。
如果把之前的這幾篇文章都理解了,再去看 Linux 內核的相關書籍,就不會那么吃力了。
Linux 雖然很復雜,但是它也是建立在處理器所提供的基本功能上的。
就像頂尖的乒乓球運動員許昕,打出那么多匪夷所思的神仙球,并不總是妙手偶得,而是建立在他們平時嚴格、機械、枯燥的日常訓練,所練就的扎實的基本功。
如果沒有這些堅實的基本功作為支撐,任何高級的花式技巧都只能是曇花一現。
學習也是一樣!
請輸入評論內容...
請輸入評論/評論長度6~500個字
最新活動更多
-
即日-10.29立即報名>> 2024德州儀器嵌入式技術創(chuàng)新發(fā)展研討會
-
10月31日立即下載>> 【限時免費下載】TE暖通空調系統高效可靠的組件解決方案
-
即日-11.13立即報名>>> 【在線會議】多物理場仿真助跑新能源汽車
-
11月14日立即報名>> 2024工程師系列—工業(yè)電子技術在線會議
-
12月19日立即報名>> 【線下會議】OFweek 2024(第九屆)物聯網產業(yè)大會
-
即日-12.26火熱報名中>> OFweek2024中國智造CIO在線峰會
推薦專題
- 高級軟件工程師 廣東省/深圳市
- 自動化高級工程師 廣東省/深圳市
- 光器件研發(fā)工程師 福建省/福州市
- 銷售總監(jiān)(光器件) 北京市/海淀區(qū)
- 激光器高級銷售經理 上海市/虹口區(qū)
- 光器件物理工程師 北京市/海淀區(qū)
- 激光研發(fā)工程師 北京市/昌平區(qū)
- 技術專家 廣東省/江門市
- 封裝工程師 北京市/海淀區(qū)
- 結構工程師 廣東省/深圳市