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

本教程操作環境：linux7.3系統、Dell G3電腦。

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

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

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

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

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

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

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

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

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

編譯

gcc -o addr_test addr_test.c -static

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

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

圖3 – 固定segment地址分布

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

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

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

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

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

二、位置無關代碼PIC和動態庫的實現

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

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

關鍵點#1 – 代碼段和數據段的偏移

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

圖5 – 代碼段和數據段偏移示例

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

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

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

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

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

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

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

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

1.全局偏移表GOT

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

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

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

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

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

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

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

圖9 – 結合GOT實現位置無關的mov指令示例

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

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

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

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

2.函數調用的位置無關化實現

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

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

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

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

PLT搭配GOT實現延遲綁定的過程如下：

第一次調用函數

圖11 – 首次調用PIC函數時PLT,GOT關系

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

resolver函數會做幾件事情：

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

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

（3）調用func函數

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

圖12 – 首次調用PIC函數后PLT,GOT關系

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

三、位置無關可執行程序PIE

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

四、Linux ASLR機制和PIE的關系

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

在Linux系統上，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在不同級別下時如何表現的，首先在ASLR關閉的情況下，相關地址不變，輸出如下：

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

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

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

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

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

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

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

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

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

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

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