linux - 共有ライブラリはどのように GOT セクションを見つけますか?

Question

http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/#id1を読んでいるときに質問が来ました:

プロセスの仮想アドレス空間のどこかにロードされた後のPIC共有ライブラリは、外部変数を参照する方法をどのように知っていますか?

問題の共有ライブラリのコードは次のとおりです。

#include <stdio.h>

extern long var;

void
shara_func(void)
{
        printf("%ld\n", var);
}

オブジェクトコードを生成し、次に共有オブジェクト (ライブラリ) を生成します。

gcc -fPIC -c lib1.c                    # produce PIC lib1.o
gcc -fPIC -shared lib1.o -o liblib1.so # produce PIC shared library

shara_func共有ライブラリで逆アセンブル:

objdump -d liblib1.so
 ...
 00000000000006d0 <shara_func>:
 6d0:   55                      push   %rbp
 6d1:   48 89 e5                mov    %rsp,%rbp
 6d4:   48 8b 05 fd 08 20 00    mov    0x2008fd(%rip),%rax        # 200fd8 <_DYNAMIC+0x1c8>
 6db:   48 8b 00                mov    (%rax),%rax
 6de:   48 89 c6                mov    %rax,%rsi
 6e1:   48 8d 3d 19 00 00 00    lea    0x19(%rip),%rdi        # 701 <_fini+0x9>
 6e8:   b8 00 00 00 00          mov    $0x0,%eax
 6ed:   e8 be fe ff ff          callq  5b0 <printf@plt>
 6f2:   90                      nop
 6f3:   5d                      pop    %rbp
 6f4:   c3                      retq   
...

アドレス0x6d4の命令が、 PCに相対的なアドレスをに移動することがわかります。これは、実行時に外部変数のアドレスを取得するためにPCraxから相対的に参照される GOT のエントリであると思います (ロードされた場所に応じて実行時に解決されます) 。 . 次に、0x6dbで命令を実行した後、外部変数の実際の内容をraxに配置し、値をraxからrsi (レジスタに渡された 2 番目の関数パラメーター) に移動します。varvar

プロセスメモリには GOT が 1 つしかないと思っていましたが、ライブラリが GOT を参照していることがわかりますか? (PIC ライブラリ) がプロセスメモリのどこにロードされるかわからない場合、共有ライブラリはプロセスの GOT へのオフセットをどのように認識しますか? それとも、各共有ライブラリには、彼女と一緒に読み込まれる独自の GOT がありますか? 私の混乱を明確にしていただければ幸いです。

score 8 · Accepted Answer

プロセスメモリには GOT が 1 つしかないと思っていましたが、ライブラリが GOT を参照していることがわかりますか?

.gotセクションがライブラリの一部であることは明らかです。readelfライブラリのセクションとそのロード方法を見つけることができます。

readelf -e liblib1.so
...
Section Headers:
  [21] .got              PROGBITS         0000000000200fd0  00000fd0
       0000000000000030  0000000000000008  WA       0     0     8
...

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x000000000000078c 0x000000000000078c  R E    200000
  LOAD           0x0000000000000df8 0x0000000000200df8 0x0000000000200df8
                 0x0000000000000230 0x0000000000000238  RW     200000
...
 Section to Segment mapping:
  Segment Sections...
   00     ... .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame 
   01     .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss 
   02     .dynamic

したがって、セクション.gotがありますが、実行時リンカーld-linux.so.2(動的 ELF のインタープリターとして登録) はセクションをロードしません。LOADProgram header with typeで説明されているように、セグメントをロードします。.gotRW フラグを持つセグメント 01 LOAD の一部です。他のライブラリには独自の GOT があります (同様のソースから liblib2.so をコンパイルすることを考えてみてください。liblib1.so について何も認識せず、独自の GOT を持つことになります)。そのため、ライブラリに対してのみ「グローバル」です。ロード後のメモリ内のプログラムイメージ全体ではありません。

(PIC ライブラリ) がプロセスメモリのどこにロードされるかわからない場合、共有ライブラリはプロセスの GOT へのオフセットをどのように認識しますか?

これは、いくつかの ELF オブジェクトを取り、それらをすべて 1 つのライブラリに結合するときに、静的リンカによって行われます。リンカーは.gotセクションを生成し、ライブラリコードからの既知のオフセット (pc 相対、リップ相対) のある場所に配置します。命令をプログラムヘッダーに書き込むため、相対アドレスが既知であり、独自の GOT にアクセスするために必要な唯一のアドレスです。

を/フラグobjdumpとともに使用すると、ELF ファイルまたはライブラリに記録された再配置 (静的/動的) に関する情報が出力されます。-d フラグと組み合わせることができます。lib1.o オブジェクトはここに再配置されました。GOT への既知のオフセットはありません。mov はすべてゼロです:-r-R

$ objdump -dr lib1.o 
lib1.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <shara_func>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   48 8b 05 00 00 00 00    mov    0x0(%rip),%rax        # b <shara_func+0xb>
            7: R_X86_64_REX_GOTPCRELX   var-0x4
   b:   48 8b 00                mov    (%rax),%rax
   e:   48 89 c6                mov    %rax,%rsi

ライブラリファイルでは、これは相対アドレスに変換されました（内部でバリアントをgcc -shared呼び出します）：ldcollect2

$ objdump -d liblib1.so 

liblib1.so:     file format elf64-x86-64

00000000000006d0 <shara_func>:
 6d0:   55                      push   %rbp
 6d1:   48 89 e5                mov    %rsp,%rbp
 6d4:   48 8b 05 fd 08 20 00    mov    0x2008fd(%rip),%rax        # 200fd8 <_DYNAMIC+0x1c8>

そして最後に、ここに var の実際のアドレスを配置するための GOT への動的な再配置があります (rtld によって行われます - ld-linux.so.2):

$ objdump -R liblib1.so 

liblib1.so:     file format elf64-x86-64

DYNAMIC RELOCATION RECORDS
OFFSET           TYPE              VALUE 
...
0000000000200fd8 R_X86_64_GLOB_DAT  var

ライブラリを使用して、定義付きの実行可能ファイルを追加し、コンパイルして、rtld デバッグを有効にして実行します。

$ cat main.c 
long var;
int main(){
    shara_func();
    return 0;
}
$ gcc main.c -llib1 -L. -o main -Wl,-rpath=`pwd`
$ LD_DEBUG=all ./main 2>&1 |less
...
   311:     symbol=var;  lookup in file=./main [0]
   311:     binding file /test3/liblib1.so [0] to ./main [0]: normal symbol `var'

そのため、リンカーは再配置をvar定義されている「メイン」ELF ファイルにバインドできました。

$ gdb -q ./main 
Reading symbols from ./main...(no debugging symbols found)...done.
(gdb) b main
Breakpoint 1 at 0x4006da
(gdb) r
Starting program: /test3/main 

Breakpoint 1, 0x00000000004006da in main ()
(gdb) disassemble shara_func
Dump of assembler code for function shara_func:
   0x00007ffff7bd56d0 <+0>: push   %rbp
   0x00007ffff7bd56d1 <+1>: mov    %rsp,%rbp
   0x00007ffff7bd56d4 <+4>: mov    0x2008fd(%rip),%rax        # 0x7ffff7dd5fd8
   0x00007ffff7bd56db <+11>:    mov    (%rax),%rax
   0x00007ffff7bd56de <+14>:    mov    %rax,%rsi

func の mov に変更はありません。func+4 の後の rax は 0x601040 です。/proc/$pid/maps によると、これは ./main の 3 番目のマッピングです。

00601000-00602000 rw-p 00001000 08:07 6691394                            /test3/main

そして、このプログラムヘッダーの後にメインからロードされました（readelf -e ./main）

LOAD           0x0000000000000df0 0x0000000000600df0 0x0000000000600df0
               0x0000000000000248 0x0000000000000258  RW     200000

これは .bss セクションの一部です:

 [26] .bss              NOBITS           0000000000601038  00001038
      0000000000000010  0000000000000000  WA       0     0     8

func+11 にステップした後、GOT で値を確認できます。

(gdb) b shara_func
(gdb) r
(gdb) si
0x00007ffff7bd56db in shara_func () from /test3/liblib1.so
1: x/i $pc
=> 0x7ffff7bd56db <shara_func+11>:  mov    (%rax),%rax
(gdb) p $rip+0x2008fd
$6 = (void (*)()) 0x7ffff7dd5fd8
(gdb) x/2x 0x7ffff7dd5fd8
0x7ffff7dd5fd8: 0x00601040  0x00000000

この GOT エントリに正しい値を書き込んだのは誰ですか?

(gdb) watch *0x7ffff7dd5fd8
Hardware watchpoint 2: *0x7ffff7dd5fd8
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /test3/main 

Hardware watchpoint 2: *0x7ffff7dd5fd8

Old value = <unreadable>
New value = 6295616
0x00007ffff7de36bf in elf_machine_rela (..) at ../sysdeps/x86_64/dl-machine.h:435
(gdb) bt
#0  0x00007ffff7de36bf in elf_machine_rela (...) at ../sysdeps/x86_64/dl-machine.h:435
#1  elf_dynamic_do_Rela (...) at do-rel.h:137
#2  _dl_relocate_object (...) at dl-reloc.c:258
#3  0x00007ffff7ddaf5b in dl_main (...)        at rtld.c:2072
#4  0x00007ffff7df0462 in _dl_sysdep_start (start_argptr=start_argptr@entry=0x7fffffffde20, 
    dl_main=dl_main@entry=0x7ffff7dd89a0 <dl_main>) at ../elf/dl-sysdep.c:249
#5  0x00007ffff7ddbe7a in _dl_start_final (arg=0x7fffffffde20) at rtld.c:307
#6  _dl_start (arg=0x7fffffffde20) at rtld.c:413
#7  0x00007ffff7dd7cc8 in _start () from /lib64/ld-linux-x86-64.so.2

(gdb) x/2x 0x7ffff7dd5fd8
0x7ffff7dd5fd8: 0x00601040  0x00000000

glibc のランタイムリンカ (rtld.c) は、呼び出しの直前に行わmainれました - これがソースです (少し異なるバージョン) - http://code.metager.de/source/xref/gnu/glibc/sysdeps/x86_64/dl-machine .h

329 case R_X86_64_GLOB_DAT:
330 case R_X86_64_JUMP_SLOT:
331   *reloc_addr = value + reloc->r_addend;
332   break;

リバースステップを使用すると、コードの履歴と古い値 = 0 を取得できます。

(gdb) b _dl_relocate_object 
(gdb) r
(gdb) dis 3
(gdb) target record-full
(gdb) c
(gdb) disp/i $pc
(gdb) rsi
(gdb) rsi
(gdb) rsi
(gdb) x/2x 0x7ffff7dd5fd8
0x7ffff7dd5fd8: 0x00000000  0x00000000


=> 0x7ffff7de36b8 <_dl_relocate_object+1560>:   add    0x10(%rbx),%rax
=> 0x7ffff7de36bc <_dl_relocate_object+1564>:   mov    %rax,(%r10)
=> 0x7ffff7de36bf <_dl_relocate_object+1567>:   nop

linux - 共有ライブラリはどのように GOT セクションを見つけますか?

1 に答える 1

Related

Reference