跳到主要內容

中文試譯：Position Independent Code (PIC) in shared libraries on x64

原文作者：Eli Bendersky
原文連結：http://eli.thegreenplace.net/2011/11/11/position-independent-code-pic-in-shared-libraries-on-x64/

前一篇文章解釋過與位址無關程式碼（position independent code, PIC）如何運作，並使用在 x86 上編譯過的程式作為範例。我承諾過在另一篇文章中涵蓋 x64 上的 PIC ，也就是現在這篇。既然大家都已經了解 PIC 的基本原理，這篇文章將不會牽扯太多細節。一般情況下，概念在不同平台下都是相似的，但細節會因為機器架構而有所不同。

RIP-relative 定址

 在 x86 上，函式的呼叫（使用 call 指令）使用與目前指令相對位移的方式定址，資料的取用（使用 mov 指令）只支援絕對定址。既然 PIC 無可避免地需要利用 IP-relative 的定址方式，絕對位址就不容易與 PIC 同時存在，而這也造成我們在前一篇文章看到 PIC 會比較沒有效率的原因。

x64 透過一個新的"RIP-relative 定址模式"修正了這點，這是 64 位元的 mov 指令去存去記憶體的預設模式（此模式也在其他指令中使用，像 lea ）。根據"英特爾架構手冊第二冊"中的說明： 
一個新的定址模式，RIP-relative（相對於 instruction-pointer），在64 位元模式中被實作。一種有效率的方式去增加相對於指向下一個指令的 64 位元 RIP 的位移 

在 RIP-relative 模式中的位移長度為 32 位元。由於正負值的位移都有需要，所以在 RIP 中的此種模式，支援的最大位移大概有最多 +/- 2GB 的位移。

 在 x64 PIC 中取用資料 – 一個例子

 作為一個簡單的對照，我會使用跟前篇文章同樣的 C 代碼作為取用資料的例子： 
int myglob = 42;

int ml_func(int a, int b)
{
    return myglob + a + b;
}
讓我們看看 ml_func 的反組譯：  
00000000000005ec <ml_func>:
 5ec:   55                      push   rbp
 5ed:   48 89 e5                mov    rbp,rsp
 5f0:   89 7d fc                mov    DWORD PTR [rbp-0x4],edi
 5f3:   89 75 f8                mov    DWORD PTR [rbp-0x8],esi
 5f6:   48 8b 05 db 09 20 00    mov    rax,QWORD PTR [rip+0x2009db]
 5fd:   8b 00                   mov    eax,DWORD PTR [rax]
 5ff:   03 45 fc                add    eax,DWORD PTR [rbp-0x4]
 602:   03 45 f8                add    eax,DWORD PTR [rbp-0x8]
 605:   c9                      leave
 606:   c3                      ret
最令人感興趣的是在 0x5f6 的指令：它透過取用 GOT 中的 entry ，將 myglobal 的位址放進 rax 。我們可以看到，它使用了 RIP-relative 定址。由於是相對於下一個指令的相對位址，我們實際上是拿到 0x5fd + 0x2009db = 0x200fd8 。所以存有 myglob 的 GOT entry 的位址是 0x200fd8。讓我們確認一下：
$ readelf -S libmlpic_dataonly.so
There are 35 section headers, starting at offset 0x13a8:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align

[...]
  [20] .got              PROGBITS         0000000000200fc8  00000fc8
       0000000000000020  0000000000000008  WA       0     0     8
[...]
GOT 從 0x200fc8 開始，所以 myglob 在第三個 entry。我們也可以查看為 GOT 中的 myglob 所產出的重定位項目：
$ readelf -r libmlpic_dataonly.so

Relocation section '.rela.dyn' at offset 0x450 contains 5 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
[...]
000000200fd8  000500000006 R_X86_64_GLOB_DAT 0000000000201010 myglob + 0
[...]
確實，有一個修正 0x200fd8 的重定位項目會告知動態連結器，一旦將 myglob 的最終位址決議後，要將其放進 0x200fd8。所以 myglob 的位址是如何獲得的就很清楚了。在反組譯中下一道指令（0x5fd）接著透過該位址去獲取 myglob 的值，並放進 eax[2] 。

在 x64 PIC 中的函式呼叫 – 一個例子

現在讓我們來看函式呼叫時如何在 x64 的 PIC 中運作。一樣，我們將會使用與前篇文章同樣的例子： 
int myglob = 42;

int ml_util_func(int a)
{
    return a + 1;
}

int ml_func(int a, int b)
{
    int c = b + ml_util_func(a);
    myglob += c;
    return b + myglob;
}
反組譯 ml_func，我們獲得：
000000000000064b <ml_func>:
 64b:   55                      push   rbp
 64c:   48 89 e5                mov    rbp,rsp
 64f:   48 83 ec 20             sub    rsp,0x20
 653:   89 7d ec                mov    DWORD PTR [rbp-0x14],edi
 656:   89 75 e8                mov    DWORD PTR [rbp-0x18],esi
 659:   8b 45 ec                mov    eax,DWORD PTR [rbp-0x14]
 65c:   89 c7                   mov    edi,eax
 65e:   e8 fd fe ff ff          call   560 <ml_util_func@plt>
 [... snip more code ...]
函式呼叫部份如同以往，會呼叫 m;_util_func@plt。讓我們看看那邊有什麼：
0000000000000560 <ml_util_func@plt>:
 560:   ff 25 a2 0a 20 00       jmp    QWORD PTR [rip+0x200aa2]
 566:   68 01 00 00 00          push   0x1
 56b:   e9 d0 ff ff ff          jmp    540 <_init+0x18>
所以某個 GOT entry 存有 ml_util_func 的實際位址，該 GOT entry 在 0x200aa2 + 0x566 = 0x201008。如預期的，同樣有一個對應的重定位項目存在：
$ readelf -r libmlpic.so

Relocation section '.rela.dyn' at offset 0x480 contains 5 entries:
[...]

Relocation section '.rela.plt' at offset 0x4f8 contains 2 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
[...]
000000201008  000600000007 R_X86_64_JUMP_SLO 000000000000063c ml_util_func + 0

可能的效能提昇

在這兩個例子中，我們可以看到在 x64 中運作的 PIC 需要的指令比 x86 要少。在 x86 上，GOT 的位址是藉由兩個步驟載入某個基底暫存器（通常是 ebx） - 首先，指令的位址是透過某個特殊的函式去獲得，接著將 GOT 的位移與之相加。這兩個步驟在 x64 上都不需要，因為 linker 知道相對 GOT 的位移，並且能夠輕易地以 RIP-relative 定址模式編碼。

當呼叫一個函式時，就不必要像 x86 那樣，在 ebx 中準備 GOT 的位址來實現 trampoline 了。因為 trmapoline 可以透過 RIP-relative 定址來直接存取 GOT entry。

在 x64 上，與非 PIC 程式相比，PIC 依然需要額外的指令，但代價變小了。間接多使用一個暫存器來作為 GOT 的指標也不再需要了（在 x86 中非常痛苦才能作到這點），因為對於 RIP-relative 定址來說，不需要此類暫存器[3]。總而言之，x64 PIC 將 x86 上的效能損失減少了許多，使得這種作法更具吸引力了。它是如此有吸引力，變成此架構下的共享程式庫的預設建構方式。

 額外紅利：在 x64 上的非 PIC 程式

gcc 不只鼓勵你在 x64 上建構共享庫時使用 PIC ，它也將其設定為預設行為。舉例來說，如果我們讓第一個例子編譯時不加入-fpic[4]，然後將其連結成共享庫（透過 -shared），我們會發現 linker 在報錯，大概像這樣：
/usr/bin/ld: ml_nopic_dataonly.o: relocation R_X86_64_PC32 against symbol `myglob' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
發生了什麼事？我們看看 ml_nopic_dataonly.o 的反組譯碼[5]：

0000000000000000 <ml_func>:
   0:   55                      push   rbp
   1:   48 89 e5                mov    rbp,rsp
   4:   89 7d fc                mov    DWORD PTR [rbp-0x4],edi
   7:   89 75 f8                mov    DWORD PTR [rbp-0x8],esi
   a:   8b 05 00 00 00 00       mov    eax,DWORD PTR [rip+0x0]
  10:   03 45 fc                add    eax,DWORD PTR [rbp-0x4]
  13:   03 45 f8                add    eax,DWORD PTR [rbp-0x8]
  16:   c9                      leave
  17:   c3                      ret
注意到此處 myglob 的存取方式，在位址 0xa 的指令。它預期 linker 會以重定位實際 myglob 位址的方式修補此處的運算元（所以不需要 GOT ）：

$ readelf -r ml_nopic_dataonly.o

Relocation section '.rela.text' at offset 0xb38 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
00000000000c  000f00000002 R_X86_64_PC32     0000000000000000 myglob - 4
[...]
Linker 會抱怨此處的重定位 R_X86_64_PC32 。它就是無法將此連結進共享庫。為何？因為 mov 指令的位移必須是 32 位元（並且會與 rip 相加），而且當一段代碼成為共享庫，我們無法提前知道 32 位元是否足夠（譯註：如果你開始看不懂，請回頭看這篇文章）。但是，這是完整的 64 位元架構，有著廣大的位址空間。在某個共享庫的符號最終可能被發現在遠大於 32 位元的位址沒有辦法被引用。這使得 R_X86_64_PC32 在 x64 共享庫中是一種無效的的重定位方式。

我們有辦法在 x64 上產出非 PIC 的程式嗎？是的！我們必須指導編譯器使用 "large code model"。透過 -mcmodel=large 旗標。code model 的主題很有趣，但是解釋這件事會讓我們的討論離此篇文章的目標太遠[6]。所以我只會簡單的說：code model 是一種程式設計師與編譯器之間的協議，程式設計師作出某種承諾，讓編譯器知道程式將會使用何種程度的位移。作為回報，編譯器就可以產出更好的代碼。

結果就是，要在 x64 上讓編譯器產出可以使 linker 開心的非 PIC 代碼，只有 large code model 是合適的，因為它是限制最少的。記住我如何解釋簡單的重定位為何無法滿足 x64，因為 linker 擔心在連結時無法獲得高於 32 位元的位址？嗯，large code model 基本上放棄所有的假設，並且對所有的資料取用採用最大的 64 位元位移。這讓 load-time relocation 總是安全的，並且可在 x64 上產生非 PIC 程式。讓我們看看第一個採用 -mcmodel=large 並且沒有 -fpic 的反組譯例子：

0000000000000000 <ml_func>:
   0:   55                      push   rbp
   1:   48 89 e5                mov    rbp,rsp
   4:   89 7d fc                mov    DWORD PTR [rbp-0x4],edi
   7:   89 75 f8                mov    DWORD PTR [rbp-0x8],esi
   a:   48 b8 00 00 00 00 00    mov    rax,0x0
  11:   00 00 00
  14:   8b 00                   mov    eax,DWORD PTR [rax]
  16:   03 45 fc                add    eax,DWORD PTR [rbp-0x4]
  19:   03 45 f8                add    eax,DWORD PTR [rbp-0x8]
  1c:   c9                      leave
  1d:   c3                      ret

在位址 0xa 的指令將 myglob 的位址放進 eax。注意，它的值是 0，也就是預期一個重定位。同時也要注意，這是一個 64 位元的位址參數。並且，此參數是絕對的，不是 RIP-relative[7]。再注意，需要兩個指令才能讓 myglob 的值放進 eax 。這是為何 large code model 會比較沒有效率的一個原因。

現在來看看重定位：
$ readelf -r ml_nopic_dataonly.o

Relocation section '.rela.text' at offset 0xb40 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
00000000000c  000f00000001 R_X86_64_64       0000000000000000 myglob + 0
[...]
注意到重定位的形式變為 R_X86_64_64 ，是一種有著 64 位元的絕對重定位。這就能夠令 linker 接受，它現在會愉悅地同意將 object file 連結成共享庫。

一些批判性的思考或許會令你懷疑，為何編譯器不將 load-time 重定位的代碼產生方式以合適的方式作為預設值。這個問題的答案很簡單。別忘了，這段代碼同時也有可能是要直接連結進一個執行檔，也就完全不要求 load-time 重定位。因此，編譯器預設會以 small code model 作為預設方式以產生較有效率的代碼。如果你知道你的代碼會進入到共享庫，並且你不想要 PIC ，那就明確告知使用 large code model 。我認為 gcc 此處的行為頗有道理的。

另一件值得思考的事，為何 small code model 對於 PIC 代碼不會有問題。理由是， 當代碼要取用符號時，GOT 總是在同一個共享庫中，所以除非單一共享庫大到超過 32 位元的位址空間，不然對於 PIC 採用 32 位元的 RIP-relative offsets就不會有問題。這樣的超大共享庫是不太可能的，但是萬一你在這樣的例外中，AMD64 ABI 有一個 "large PIC code model" 作為解決方案。

結論
透過展示 x64 上 PIC 如何運作，這篇文章補充了之前的說明。這個架構下有新的定址模式來幫助 讓 PIC 代碼更有效率，因此使得這種作法會比在 x86 下更適合作為共享庫的方式，因為 x86 的 PIC 會需要較高的執行代價。既然 x64 目前是在伺服器、桌上機以及筆電上最流行的架構，這變成了重要須知。因此，我試著聚焦在不同的的共享庫建構方式，比如說非 PIC 代碼。如果你對於未來想探索的方向有任何疑問以及（或）建議，請透過回應或 email 讓我知道。

 http://eli.thegreenplace.net/wp-content/uploads/hline.jpg
[1]  如同過去，我使用 x64 作為x86-64, AMD64 或 Intel 64 的方便的簡稱。
[2] 使用 eax 而不是 rax ，因為 myglob 的型別是 int ，在 x64 上還是 32 位元。
[3] 對了，在 x64 上，對於暫存器的使用也比較不那麼痛苦，因為有比 x86 多兩倍的通用暫存器。
[4] 也同時會發生在我們透過 -fno-pic 明確告知 gcc 我們不需要 PIC。
[5] 注意，不同於此篇與過往文章的反組譯例子，這是一個 object file，不是共享庫或執行檔。所以會帶有一些給 linker 的重定位。
[6] 看看 AMD64 ABI，那邊有一些針對此議題的有用資訊，然後也 man gcc。
[7] 一些組譯器將這個指令稱作 movabs ，用來區分其他的接受相對參數的 mov 指令。然而，在英特爾手冊中，依然使用 mov 作為命名。它的 opcode 形式為 REX.W + B8 +rd 。 
標籤：

留言

張貼留言

這個網誌中的熱門文章

誰在呼叫我？不同的backtrace實作說明好文章

今天下班前一個同事問到：如何在Linux kernel的function中主動印出backtrace以方便除錯？ 寫過kernel module的人都知道，基本上就是用dump_stack()之類的function就可以作到了。但是dump_stack()的功能是如何作到的呢？概念上其實並不難，慣用手法就是先觀察stack在function call時的變化(一般OS或計組教科書都有很好的說明，如果不想翻書，可以參考 這篇 )，然後將對應的return address一層一層找出來後，再將對應的function名稱印出即可(透過執行檔中的section去讀取函式名稱即可，所以要將KALLSYM選項打開)。在userspace的實作可參考Jserv介紹過的 whocallme 或對岸好手實作過的 backtrace() ，都是針對x86架構的很好說明文章。 不過從前面兩篇文章可以知道，只要知道編譯器的calling convention，就可以實作出backtrace，所以是否GCC有提供現成的機制呢？Yes, that is what __builtin_return_address() for!! 可以參考這篇 文章 。該篇文章還提到了其他可以拿來實作功能更齊全的backtrace的 程式庫 ，在了解了運作原理後，用那些東西還蠻方便的。 OK，那Linux kernel是怎麼做的呢？就是用頭兩篇文章的方式啦~ 每個不同的CPU架構各自手工實作一份dump_stack()。 為啥不用GCC的機制？畢竟...嗯，我猜想，除了backtrace以外，開發者還會想看其他register的值，還有一些有的沒的，所以光是GCC提供的介面是很難印出全部所要的資訊，與其用半套GCC的機制，不如全都自己來~ arm的實作 大致上長這樣，可以看到基本上就只是透過迭代fp, lr, pc來完成： 352 void unwind_backtrace (struct pt_regs * regs , struct task_struct *tsk) 353 { 354 struct stackframe frame ; 355 register unsigned long current_sp asm ( "...
13 則留言
閱讀完整內容

淺讀Linux root file system初始化流程

在Unix的世界中，file system佔據一個極重要的抽象化地位。其中，/ 所代表的rootfs更是所有後續新增file system所必須依賴前提條件。以Linux為例，黑客 Jserv 就曾經詳細說明過 initramfs的背後設計考量 。本篇文章不再重複背景知識，主要將追蹤rootfs初始化的流程作點整理，免得自己日後忘記。 :-) file system與特定CPU架構無關，所以我觀察的起點從init/main.c的start_kernel()開始，這是Linux作完基本CPU初始化後首先跳進的C function(我閱讀的版本為 3.12 )。跟root file system有關的流程羅列如下： start_kernel()         -> vfs_caches_init_early()         -> vfs_caches_init()                 -> mnt_init()                         -> init_rootfs()                         -> init_mount_tree()         -> rest_init()                 -> kernel_thread(kernel_init,...) 其中比較重要的是mnt_int()中的init_rootfs()與init_mout_tree()。init_rootfs()實作如下： int __init init_root...
張貼留言
閱讀完整內容

kernel panic之後怎麼辦？

今天同事在處理一個陌生的模組時遇到kernel panic，Linux印出了backtrace，同事大致上可以知道是在哪個function中，但該function的長度頗長，短時間無法定位在哪個位置，在這種情況下，要如何收斂除錯範圍呢？更糟的是，由於加入printk會改變模組行為，所以printk基本上無法拿來檢查參數的值是否正常。 一般這樣的問題會backtrace的資訊來著手。從這個資訊我們可以知道在function中的多少offset發生錯誤，以x86為例(從 LDD3 借來的例子)： Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: d083a064 Oops: 0002 [#1] SMP CPU:    0 EIP:    0060:[<d083a064>]    Not tainted EFLAGS: 00010246   (2.6.6) EIP is at faulty_write+0x4/0x10 [faulty] eax: 00000000   ebx: 00000000   ecx: 00000000   edx: 00000000 esi: cf8b2460   edi: cf8b2480   ebp: 00000005   esp: c31c5f74 ds: 007b   es: 007b   ss: 0068 Process bash (pid: 2086, threadinfo=c31c4000 task=cfa0a6c0) Stack: c0150558 cf8b2460 080e9408 00000005 cf8b2480 00000000 cf8b2460 cf8b2460        fffffff7 080e9408 c31c4000 c0150682 cf8b2460 080e9408 00000005 cf8b2480       ...
張貼留言
閱讀完整內容