linux pic指的是什么

這篇“l(fā)inux pic指的是什么”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“l(fā)inux pic指的是什么”文章吧。

在linux中，pic的中文意思為“位置無關代碼”，是指代碼無論被加載到哪個地址上都可以正常執(zhí)行。PIC用于生成位置無關的共享庫，所謂位置無關，指的是共享庫的代碼斷是只讀的，存放在代碼段，多個進程可同時公用這份代碼段而不需要拷貝副本。

本教程操作環(huán)境：linux7.3系統(tǒng)、Dell G3電腦。

在linux中，pic全稱“Position Independent Code”，中文意思為“位置無關代碼”。

一、程序虛擬地址空間及位置有關代碼概述

Linux進程從磁盤加載到內存中運行的過程中，內核會為進程分配虛擬地址空間，虛擬地址空間被劃分為一塊塊的區(qū)域(Segment)，其中最重要的幾個區(qū)域如下：

圖1 - 應用程序虛擬地址空間說明

內核地址空間，對所有應用來說都是相同的，這部分地址空間應用無法直接訪問。內核地址空間不是本文關注的重點，我們重點關注應用程序的重要的一些SEGMENT。

表1 - 應用程序重要segment描述

如果系統(tǒng)沒有開啟地址隨機化(ASLR - Address Space Layout Randomization，地址隨機化，后文會介紹)，則Linux會將上面表格中的各個segment的地址空間放到一個固定的地址上面。

我們寫一個實際的程序來看看在一個Linux X86_64的機器上各個segment的地址是如何排布的，程序如下，覆蓋了我們關心的segment。

圖2 - 虛擬地址空間演示程序

編譯

gcc -o addr_test addr_test.c -static

（此處使用靜態(tài)鏈接，以便演示位置相關代碼的特征）

我們運行這個程序3次，會發(fā)現(xiàn)所有的地址都是一個固定值。這是因為在沒有開ASLR特性時，系統(tǒng)不會隨機化分配程序的虛擬地址空間，程序所有的地址都是按照固定的規(guī)則來生成。

圖3 - 固定segment地址分布

通過objdump命令反匯編后可以看到，對于全局變量和函數(shù)調用的訪問，匯編指令跟的地址都是固定的，這樣的代碼我們就稱它為位置相關的。

圖4 - 位置相關代碼匯編語句實例

這種代碼，由于地址是寫死的，只能加載到指定地址上運行，一旦加載地址有變化，由于代碼里訪問的變量、函數(shù)地址是固定的,加載地址變化后程序無法正常執(zhí)行。

固定地址的方式雖然簡單，但是無法實現(xiàn)一些高級特性比如動態(tài)庫支持。動態(tài)庫的代碼會通過mmap()系統(tǒng)調用來映射到進程的虛擬地址空間，不同的進程中，同一個動態(tài)庫映射的虛擬地址是不確定的。如果動態(tài)庫的實現(xiàn)上使用位置相關的代碼，則無法達到其任意地址運行的目的，這種情況下我們就需要引入位置無關代碼PIC的概念了。

另外，我們可以看到，在沒有開啟地址隨機化特性的系統(tǒng)上，由于程序各個segment的地址是固定的，黑客在攻擊時會更加簡單(感興趣的同學可以搜索一下Ret2shellcode或Ret2libc攻擊)，此時需要引入PIE的概念搭配ASLR一起來防護。

二、位置無關代碼PIC和動態(tài)庫的實現(xiàn)

PIC位置無關代碼是指代碼無論被加載到哪個地址上都可以正常執(zhí)行。gcc選項中添加-fPIC會產生相關代碼。

PIC用于生成位置無關的共享庫，所謂位置無關，指的是共享庫的代碼斷是只讀的，存放在代碼段，多個進程可同時公用這份代碼段而不需要拷貝副本。庫中的變量（全局變量和靜態(tài)變量）通過GOT表訪問，而庫中的函數(shù)，通過PLT->GOT->函數(shù)位置進行訪問。Linux下編譯共享庫時，必須加上-fPIC參數(shù),否則在鏈接時會有錯誤提示(有資料說AMD64的機器才會出現(xiàn)這種錯誤,但我在Inter的機器上也出現(xiàn)了)。

關鍵點#1 - 代碼段和數(shù)據(jù)段的偏移

代碼段和數(shù)據(jù)段之間的偏移，在鏈接的時候由鏈接器給出，對于PIC來說非常重要。當鏈接器將各個目標文件的所有p組合到一起的時候，鏈接器完全知道每個p的大小和它們之間的相對位置。

圖5 - 代碼段和數(shù)據(jù)段偏移示例

如上圖所示，示例中這里TEXT和DATA時緊緊挨著的，其實無論DATA和TEXT是否是相鄰的，鏈接器都能知道這兩個段的偏移。根據(jù)這個偏移，可以計算出在TEXT段內任意一條指令相對于DATA段起始地址的相對偏移量。如上圖，無論TEXT段被放到了哪個虛擬地址上，假設一條mov指令在TEXT內部的0xe0偏移處，那么我們可以知道，DATA段的相對偏移位置就是:TEXT段的大小 - mov指令在TEXT內部的偏移 = 0xXXXXE000 - 0xXXXX00E0 = 0xDF20

關鍵點#2 - X86上指令相對偏移的計算

如果使用相對位置進行處理，可以看到代碼能夠做到位置無關。但在X86平臺上mov指令對于數(shù)據(jù)的引用需要一個絕對地址，那應該怎么辦呢？

從“關鍵點1”里的描述來看，我們如果知道了當前指令的地址，那么就可以計算出數(shù)據(jù)段的地址。X86平臺上沒有獲取當前指令指針寄存器IP的值的指令（X64上可以直接訪問RIP），但可以通過一個小技巧來獲取。來看一段偽代碼：

圖6 - X86平臺獲取指令地址匯編

這段代碼在實際運行時，會有以下的事情發(fā)生：

• 當cpu執(zhí)行 call STUB的時候，會將下一條指令的地址保存到stack上，然后跳到標簽STUB處執(zhí)行。

• STUB處的指令是pop ebx,這樣就將 "pop ebx"這條指令所在的地址從stack彈出放到了ebx寄存器中，這樣就得到了IP寄存器的值。

1.全局偏移表GOT

在理解了前面的幾點后，來看看在X86上是如何實現(xiàn)位置無關的數(shù)據(jù)引用的，此特性是通過全局偏移表global offset table（GOT）來實現(xiàn)的。

GOT是一張在data p中保存的一張表，里面記錄了很多地址字段 (entry)。假設一條指令想要引用一個變量，并不是直接去用絕對地址，而是去引用GOT里的一個entry。GOT表在data p中的地址是明確的，GOT的entry包含了變量的絕對地址。

圖7 - 代碼地址和GOT表entry關系

如上圖，根據(jù)"關鍵點1"和“關鍵點2”，我們可以先獲取到當前IP的值，然后計算得到GOT表的絕對地址，由于變量的地址entry在GOT表中的偏移也是已知的，因此可以實現(xiàn)位置無關的數(shù)據(jù)訪問。

以一條絕對地址的mov指令的偽代碼為例（X86平臺）：

圖8 - 位置相關mov指令示例

如果要變成位置無關的代碼，則要多幾個步驟

圖9 - 結合GOT實現(xiàn)位置無關的mov指令示例

通過上面的步驟，就可以實現(xiàn)代碼訪問變量的地址無關化。但是還有一個問題，這個GOT表里存儲的VAR_ADDR值又是怎么變成實際的絕對地址的呢？

假設有一個libtest.so,有一個全局變量g_var,我們通過readelf -r libtest.so后，會看到如下的輸出

圖10 - rel.dyn段全局變量重定向描述字段

動態(tài)加載器會解析rel.dyn段，當它看到重定向類型為R_386_GLOB_DAT的時候，會做如下操作：將符號g_var實際的地址值替換到偏移0x1fe4處（也就是將Sym.Value的值替換為實際地址值）

2.函數(shù)調用的位置無關化實現(xiàn)

從理論上講，函數(shù)的PIC實現(xiàn)也可以通過和數(shù)據(jù)引用GOT表相同的方式實現(xiàn)位置無關。不直接使用函數(shù)的地址，而是通過查GOT來找到實際的函數(shù)絕對地址。但實際上函數(shù)的PIC特性并不是這么做的，實際情況會復雜一些。為什么不按照和數(shù)據(jù)引用一樣的方式，先來看一個概念：延遲綁定。

對于動態(tài)庫的函數(shù)來說，在沒有加載到程序的地址空間前，函數(shù)的實際地址都是未知的，動態(tài)加載器會處理這些問題，解析出實際地址的過程,這個過程稱之為綁定。綁定的動作會消耗一些時間，因為加載器要通過特殊的查表、替換操作。

如果動態(tài)庫有成百上千個函數(shù)接口，而實際的進程只用到了其中的幾十個接口，如果全部都在加載的時候進行綁定操作，沒有意義并且非常耗時。因此提出了延遲綁定的概念，程序只有在使用到對應接口時才實時地綁定接口地址。

因為有了延遲綁定的需求，所以函數(shù)的PIC實現(xiàn)和數(shù)據(jù)訪問的PIC有所區(qū)別。為了實現(xiàn)延遲綁定，就額外增加了一個間接表PLT（過程鏈接表）。

PLT搭配GOT實現(xiàn)延遲綁定的過程如下：

第一次調用函數(shù)

圖11 - 首次調用PIC函數(shù)時PLT,GOT關系

首先跳到PLT表對應函數(shù)地址PLT[n],然后取出GOT中對應的entry。GOT[n]里保存了實際要跳轉的函數(shù)的地址，首次執(zhí)行時此值為PLT[n]的prepare resolver的地址，這里準備了要解析的函數(shù)的相關參數(shù)，然后到PLT[0]處調用resolver進行解析。

resolver函數(shù)會做幾件事情：

（1）解析出代碼想要調用的func函數(shù)的實際地址A

（2）用實際地址A覆蓋GOT[n]保存的plt_resolve_addr的值

（3）調用func函數(shù)

首次調用后，上圖的鏈接關系會變成下圖所示：

圖12 - 首次調用PIC函數(shù)后PLT,GOT關系

隨后的調用函數(shù)過程，就不需要再走resolver過程了

三、位置無關可執(zhí)行程序PIE

PIE，全稱Position Independent Executable。2000年早期及以前，PIC用于動態(tài)庫。對于可執(zhí)行程序來講，仍然是使用絕對地址鏈接，它可以使用動態(tài)庫，但程序本身的各個segment地址仍然是固定的。隨著ASLR的出現(xiàn)，可執(zhí)行程序運行時各個segment的虛擬地址能夠隨機分布，這樣就讓攻擊者難以預測程序運行地址，讓緩存溢出攻擊變得更困難。OS在使能ASLR的時候，會檢查可執(zhí)行程序是否是PIE的可執(zhí)行程序。gcc選項中添加-fPIE會產生相關代碼。

四、Linux ASLR機制和PIE的關系

ASLR的全稱為 Address Space Layout Randomization。在Linux 2.6.12 中被引入到 Linux 系統(tǒng)，它將進程的某些虛擬地址進行隨機化，增大了入侵者預測目的地址的難度，降低應用程序被攻擊成功的風險。

在Linux系統(tǒng)上，ASLR有三個級別

表2 - ASLR級別描述

ASLR的級別通過兩種方式配置：

echo level > /proc/sys/kernel/randomize_va_space

或

sysctl -w kernel.randomize_va_space=level

例子:

echo 0 > /proc/sys/kernel/randomize_va_space 關閉地址隨機化

或

sysctl -w kernel.randomize_va_space=2 最大級別的地址隨機化

我們還是以文章開頭的那個程序來說明ASLR在不同級別下時如何表現(xiàn)的，首先在ASLR關閉的情況下，相關地址不變，輸出如下：

圖13 - ASLR=0時虛擬地址空間分配情況

我們把ASLR級別設置為1，運行兩次，看看結果：

圖14 - ASLR=1時虛擬地址空間分配情況

可以看到STACK和MMAP的地址發(fā)生了變化。堆、數(shù)據(jù)段、代碼段仍然是固定地址。

接下來我們把ASLR級別設置為2，運行兩次，看看結果:

圖15 - ASLR=2,PIE不啟用時虛擬地址空間分配情況

可以看到此時堆的地址也發(fā)生了變化，但是我們發(fā)現(xiàn)BSS,DATA,TEXT段的地址仍然是固定的，不是說ASLR=2的時候，是完全隨機化嗎？

這里就引出了PIE和ASLR的關系了。從上面的實驗可以看出，如果不對可執(zhí)行文件做一些特殊處理，ASLR即使在設置為完全隨機化的時候，也僅能對STACK,HEAP，MMAP等運行時才分配的地址空間進行隨機化，而可執(zhí)行文件本身的BSS,DATA,TEXT等沒有辦法隨機化。結合文章前面講到的PIE相關知識，我們也很容易理解這一點，因為編譯和鏈接過程中，如果沒有PIE的選項，生成的可執(zhí)行文件里都是位置相關的代碼。如果OS不管這一點，ASLR=2時也將BSS,DATA,TEXT等隨意排布，可想而知程序根本不能正常運行起來。

明白了原因，我們在編譯時加入PIE選項，然后在ASLR=2時重新運行一下看看結果如何

圖16 - ASLR=2,PIE啟用時虛擬地址空間分配情況

可以看到在PIE打開的情況下，搭配ASLR=2，可以實現(xiàn)各個段的虛擬地址完全隨機化分布。

以上就是關于“l(fā)inux pic指的是什么”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業(yè)資訊頻道。