動態連結的相關結構

yooooooo發表於2019-03-16

在瞭解了共享物件的絕對地址的引用問題後，我們基本上對動態連結的原理有了初步的瞭解，接下來的問題是整個動態連結具體的實現過程了。動態連結在不同的系統上有不同的實現方式。ELF的動態連結的實現方式會比PE的簡單一點，在這裡我們先介紹ELF的動態連結過程在LINUX下的實現，最後我們會專門的章節中介紹PE在Windows下的動態連結過程和它們的區別

我們在前面的章節已經看到,動態連結情況下,可執行檔案的裝載與靜態連結情況基本樣。首先作業系統會讀取可執行檔案的頭部檢查檔案的合法性,然後從頭部中的“ Program Header”中讀取每個“Segment”的虛擬地址、檔案地址和屬性,並將它們對映到程式虛擬空間的相應位置,這些步驟跟前面的靜態連結情況下的裝載基本無異。在靜態連結情況下,作業系統接著就可以把控制權轉交給可執行檔案的入口地址,然後程式開始執行,一切看起來非常直觀。

但是在動態連結情況下,作業系統還不能在裝載完可執行檔案之後就把控制權交給可執行檔案,因為我們知道可執行檔案依賴於很多共享物件。這時候,可執行檔案裡對於很多外部符號的引用還處於無效地址的狀態,即還沒有跟相應的共享物件中的實際位置連結起來。所以在對映完可執行檔案之後,作業系統會先啟動個動態連結器( Dynamic Linker)

在 Linux下,動態連結器ld.so實際上是一個共享物件,作業系統同樣通過對映的方式將它載入到程式的地址空間中。作業系統在載入完動態連結器之後,就將控制權交給動態連結器的入口地址(與可執行檔案一樣,共享物件也有入口地址)。當動態連結器得到控制權之後,它開始執行一系列自身的初始化操作,然後根據當前的環境引數,開始對可執行檔案進行動態連結工作。當所有動態連結工作完成以後,動態連結器會將控制權轉交到可執行檔案的入口地址,程式開始正式執行

1. ".interp"段

那麼系統中哪個才是動態連結器呢,它的位置由誰決定?是不是所有的*NX系統的動態連結器都位於 /lib/ld.so呢?實際上,動態連結器的位置既不是由系統配置指定,也不是由環境引數決定,而是由ELF可執行檔案決定。在動態連結的ELF可執行檔案中,有一個專門的段叫做“ Interp”段(“ Interp”是“ Interpreter”(直譯器)的縮寫)。如果我們使用 objdump工具來檢視,可以看到“ .interp”內容:

動態連結的相關結構

".interp"的內容很簡單，裡面儲存的就是一個字串，這個字串就是可執行的所需要的動態連結器的路徑。在LINUX下，可執行檔案所需要的動態連結器的路徑幾乎都是 “/lib/ld-linux.so.2”，其他的*.nix作業系統可能會有不同路徑。我們在後面還會介紹到各種環境下的動態連結器的路徑。在LINUX系統中，/lib/ld-linux.so.2通常是一個軟連結，比如在我的機器中，它指向/lib/ld-linux.so.2，這個才是真正的動態連結器，在linux中，作業系統在對可執行檔案所需要的相應動態聯結器，即“.interp”段指定的路徑的共享物件；

動態連結器在linux下是glibc的一部分，也就是屬於系統庫級別的，它的版本號往往跟系統的Glibc庫版本號是一樣的，比如我的系統中安裝的是glibc 2.6.1，那麼相應的動態連結庫就是/lib/ld-2.6.1.so。當系統中的Glibc庫更新或者安裝其他版本的時候，/lib/ld-linux.so.2 這個軟連結就會指向新的動態連結器，而可執行檔案本身不需要修改 ".interp" 中的動態連結器路徑來適應系統的升級

我們往往可以用這個命令來檢視一個可執行檔案所需要的動態連結器的路徑，在linux下，往往是這個結果：

readelf -l a.out | grep interpreter
[Requeseting program interpreter: /lib/ld-linux.so.2]

而當我們在FreeBSD 4.6.2 下執行這個命令時，結果是：

readelf -l a.out | grep interpreter

64 位的linux下的可執行檔案是：

readelf -l a.out | grep interpreter

2. “.dynamic”段

類似於“.interp”這樣的段，ELF中還有幾個段也是專門用於動態連結的，比如 ".dynamic" 段和 ".dynsym"段等。要了解動態連結器如何完成連結過程，跟前面一樣，從瞭解ELF檔案中跟動態連結相關的結構入手將會是一個很好的途徑。ELF檔案中跟動態連結相關的段有好幾個，相互之間的關係也比較複雜，我們先從 ".dynamic" 段入手

動態連結ELF中最重要的結構應該是“ .dynamic”段,這個段裡面儲存了動態連結器所需要的基本資訊,比如依賴於哪些共享物件、動態連結符號表的位置、動態連結重定位表的位置、共享物件初始化程式碼的地址等。“ .dynamic”段的結構很經典,就是我們已經碰到過的ELF中眼熟的結構陣列,結構定義在“elf.h”中:

typedef struct {
    Elf32_Sword d_tag;
    union {
        Elf32_Word d_val;
        Elf32_Addr d_ptr;
    } d_un;
} Elf32_Dyn;

Elf32_Dyn 結構由一個型別值加上一個附加的數值或指標，對於不同型別，後面附加的數值或者指標有著不同含義。我們這裡列舉幾個比較常見的型別值（這些值都是定義在“elf.h”裡面的巨集），如表7-2所示：

動態連結的相關結構

表7-2中只列出了一部分定義，還有一些不太常用的定義我們就暫且忽略，具體可以參考LSB手冊和elf.h的定義。從上面給出的定義來看，“.dynamic”段裡面儲存的資訊有點像elf檔案頭，只是我們看到的elf檔案頭中儲存的是靜態連結時的相關資訊，比如靜態連結時使用到的符號表、重定位表等，這裡換成了動態連結下所使用的相應資訊了。所以，“.dynamic”段可以看成動態連結下的ELF檔案的“檔案頭”。使用readelf工具可以檢視 ".dynamic" 段的內容

$ readelf -d lib.so

動態連結的相關結構

另外linux還提供了一個命令用來檢視一個程式主模組或一個共享庫依賴於哪些共享庫：

動態連結的相關結構

動態符號表

為了完成動態連結,最關鍵的還是所依賴的符號和相關檔案的資訊。我們知道在靜態連結中,有一個專門的段叫做符號表“.symtab”( Symbol Table),裡面儲存了所有關於該目標檔案的符號的定義和引用。動態連結的符號表示實際上它跟靜態連結十分相似,比如前面例子中的 Program1程式依賴於 Lib.so,引用到了裡面的 foobar()函式。那麼對於 Program1來說,我們往往稱 ProgramI匯入( Import)了 foobar函式, foobar是 Program1的匯入函式(import Function):而站在Lib.so的角度來看,它實際上定義了 foobar函式,並且提供給其他模組使用,我們往往稱Lib.so匯出( Export)了 foobar函式, foobar是Lbso的匯出函式(Export Function)。把這種匯入匯出關係放到靜態連結的情形下,我們可以把它們看作普通的函式定義和引用。

為了表示動態連結這些模組之間的符號匯入匯出關係，ELF專門有一個叫做動態符號表（Dynamic symbol table）的段用來儲存這些資訊，這個段的段名通常叫做“.dynsym”(Dynamic Symbol)。與 “.sysmtab”不同的是，".dynsym" 只儲存了與動態連結相關的符號，對於那些模組內部的符號，比如模組私有變數則不儲存。很多時候動態連結的模組同時擁有“.dynsym” 和 ".sysmtab"中往往儲存了所有符號，包括 “.dynsym” 中的符號

與 “.sysmtab” 類似，動態符號表也需要一些輔助的表，比如用於儲存符號名的字串表。靜態連結的時候叫做符號字串“.strtab” (Striing Table)，在這裡就是動態符號字串表“.dynstr” (Dynamic String Table)；由於動態連結下，我們需要在程式執行時查詢符號，為了加快符號的查詢過程，往往還有輔助的符號雜湊表（“.hash”）。我們可以用readelf工具來檢視elf檔案的動態符號表及雜湊表：

readelf -sD lib.so

動態連結的相關結構

動態連結符號表的結構與靜態連結的符號表幾乎一樣，我們可以簡單的將匯入韓式看作是對其他目標檔案中函式的引用：把匯出函式看作是在本目標檔案定義的函式就可以了；

3. 動態連結重定位表

共享物件需要重定位的主要原因是匯入符號的存在。在動態連結下，無論是可執行檔案或共享物件，一旦它依賴於其他共享物件，也就是說有匯入的符號時，那麼它的程式碼或資料中就會有對於匯入符號的引用。在編譯時這些匯入符號的地址未知，在靜態連結中，這些未知的地址引用在最終連結時被修正。但是在動態連結中，匯入符號的地址在執行時才確定，所以需要在執行時將這些匯入符號的引用修正，即需要重定位；

我們在前面地址無關章節中也提到過，動態連結的可執行檔案使用的是PIC方法，但這不能改變它需要重定位的本質。對於動態連結來說，如果一個共享物件不是以PIC模式編譯的，那麼毫無疑問，它是需要在裝載時被重定位的：如果一個共享物件是PIC模式編譯的，那麼它還需要再裝載時進行重定位嗎？是的，PIC的共享物件也是需要重定位的；

對於使用PIC技術的可執行檔案或共享物件來說,雖然它們的程式碼段不需要重定位(因為地址無關),但是資料段還包含了絕對地址的引用,因為程式碼段中絕對地址相關的部分被分離了出來,變成了GOT,而GOT實際上是資料段的一部分。除了GOT以外,資料段還可能包含絕對地址引用,我們在前面的章節中已經舉例過了。

動態連結重定位的相關結構

共享物件的重定位與我們在前面“靜態連結”中分析過的目標檔案的重定位十分類似,唯一有區別的是目標檔案的重定位是在靜態連結時完成的,而共享物件的重定位是在裝載時完成的。在靜態連結中,目標檔案裡面包含有專門用於表示重定位資訊的重定位表,比如“rel.text”表示是程式碼段的重定位表,“rel.data”是資料段的重定位表。

動態連結的檔案中,也有類似的重定位表分別叫做“ .rel.dyn”和“.rel. plt”,它們分別相當於“.rel.text”和“.rel.data”“.rel .dyn”實際上是對資料引用的修正,它所修正的位置位於“.got”以及資料段;而“ .rel.plt”是對函式引用的修正,它所修正的位置位於“.got.plt”。我們可以使用 readelf來檢視一個動態連結的檔案的重定位表

動態連結的相關結構

可以看到Lib.c中兩個匯入函式“printf” 和“sleep” 從“.rel.plt”到了“.rel.dyn”，並且型別也從R_386_JUMP_SLOT變成了R_386_PC32

而R_386_RELATIVE型別多出了一個偏移為0x0000042c的入口，這個入口是什麼呢？通過對Lib.so 的反彙編可以知道，這個入口用來修正給printf的第一個引數，即我們的字串常量“Printing from Lib.so %d\n”的地址。為什麼這個字串常量的地址在PIC時不需要重定位而在非PIC時需要重定位呢？很明顯，PIC時，這個字串可以看做是普通的全域性變數，它的地址是可以通過PIC中的相對當前指令的位置加上一個固定偏移計算出來的：而在非PIC中，程式碼段不再使用這種相對於當前指令的PIC方法，而是採用絕對地址定址，所以它需要重定位；

動態連結時程式堆疊初始化資訊

站在動態連結器的角度看,當作業系統把控制權交給它的時候,它將開始做連結丁作,那麼至少它需要知道關於可執行檔案和本程式的一些資訊,比如可執行檔案有幾個段(“ Segment”)、每個段的屬性、程式的入口地址(因為動態連結器到時候需要把控制權交給可執行檔案)等。這些資訊往往由作業系統傳遞給動態連結器,儲存在程式的堆疊裡面。我們在前面提到過,程式初始化的時候,堆疊裡面儲存了關於程式執行環境和命令列引數等資訊。事實上,堆疊裡面還儲存了動態連結器所需要的一些輔助資訊陣列( Auxiliary Vector)。輔助資訊的格式也是一個結構陣列,它的結構被定義在“elf.h”

typedf struct
{
    uint32_t a_type;
    union {
        uint32_t a_val;
    } a_un;
} Elf32_auxv_t;

是不是已經對這種結構很熟悉了？沒錯，跟前面的“.dynamic”段裡面的結構如出一轍。先是一個32位型別的值，後面是一個32位的數值部分，你很可能很奇怪為什麼要用一個union把後面的32位數值包裝起來，事實上，這個union沒啥用，只是歷史遺留而已，可以當做不存在。我們摘錄幾個比較重要的型別值，這幾個型別值都是比較常見的，而且是動態連結器在啟動時所需要的，如表7-3所示：

動態連結的相關結構