Linux 修改 ELF 解決 glibc 兼容性問題

Linux glibc 問題

相信有很多 Linux 用戶都碰到過運行第三方（非系統自帶軟件源）發佈的程序時的 glibc 兼容性問題，這通常是因爲當前 Linux 系統上的 GNU C 庫（glibc）版本比較老致使的，例如我在 CentOS 6 64 位系統上運行某第三方閉源軟件時會報：

[root@centos6-dev ~]# ldd tester./tester: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by ./tester)./tester: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./tester)        linux-vdso.so.1 =>  (0x00007ffe795fe000)        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc7d4c73000)        libOpenCL.so.1 => /usr/lib64/libOpenCL.so.1 (0x00007fc7d4a55000)        libdl.so.2 => /lib64/libdl.so.2 (0x00007fc7d4851000)        libm.so.6 => /lib64/libm.so.6 (0x00007fc7d45cd000)        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc7d43b7000)        libc.so.6 => /lib64/libc.so.6 (0x00007fc7d4023000)        /lib64/ld-linux-x86-64.so.2 (0x00007fc7d4e90000)

CentOS 6 自帶的 glibc 仍是很老的 2.12 版本，而下載的第三方程序依賴 glibc 2.17 版本，這種狀況要麼本身從新編譯程序，要麼只能升級系統的 glibc 版本。因爲我使用的程序是第三方編寫而且是閉源軟件沒法本身編譯，升級 glibc 當然可能能解決問題，可是 glibc 作爲最核心的基礎庫，在生產環境上直接升級畢竟動做仍是太大，所以但願仍是能有更好的解決途徑。

問題分析

**
**

首先咱們能夠檢查一下程序使用了新版本 glibc 的哪些符號，使用 objdump 命令能夠查看 ELF 文件的動態符號信息：

[root@centos6-dev ~]# objdump -T tester | grep GLIBC_2.1.*0000000000000000      DF *UND*  0000000000000000  GLIBC_2.14  memcpy0000000000000000      DF *UND*  0000000000000000  GLIBC_2.17  clock_gettime

從上面的輸出能夠看到程序使用了 glibc 2.14 版本的 memcpy 函數和 glibc 2.17 版本的 clock_gettime 函數，而這兩個經常使用的函數按說應該是 glibc 很早就已經支持了的，咱們能夠確認一下當前系統 glibc 提供的符號版本：

[root@centos6-dev ~]# objdump -T /lib64/libc.so.6 | grep memcpy0000000000091300  w   DF .text  0000000000000009  GLIBC_2.2.5 wmemcpy0000000000101070 g    DF .text  000000000000001b  GLIBC_2.4   __wmemcpy_chk00000000000896b0 g    DF .text  0000000000000465  GLIBC_2.2.5 memcpy00000000000896a0 g    DF .text  0000000000000009  GLIBC_2.3.4 __memcpy_chk[root@centos6-dev ~]# objdump -T /lib64/libc.so.6 | grep clock_gettime000000000038f800 g    DO .bss   0000000000000008  GLIBC_PRIVATE __vdso_clock_gettime

這裏能夠看出 CentOS 6 的 glibc 庫提供的 memcpy 實現是 2.2.5 版本的，另外 libc 沒有直接實現 clock_gettime 函數，由於老版本 glibc 裏 clock_gettime 是由 librt 庫提供 clock_gettime 支持的，並且一樣也是 2.2.5 版本：

[root@centos6-dev ~]# objdump -T /lib64/librt.so.1 | grep clock_gettime0000000000000000      DO *UND*  0000000000000000  GLIBC_PRIVATE __vdso_clock_gettime0000000000003e70 g    DF .text  000000000000008b  GLIBC_2.2.5 clock_gettime

看過這裏就基本明白了，第三方程序的開發者是在自帶新版本 glibc 的 Linux 系統上編譯的，memcpy 和 clock_gettime 的實現默認使用了該系統上 glibc 所提供的最新版本，這樣在低版本 glibc 系統中就沒法正常運行。

解決方法

**
**

雖然咱們沒法從新編譯第三方程序，但若是能夠修改 ELF 文件強制讓 LD 庫加載程序時使用老版本的 memcpy 和 clock_gettime 實現，應該就能夠避免升級 glibc。

分析 ELF

**
**

首先用 readelf 命令查看 ELF 的符號表，因爲該命令輸出很是多，這裏只貼出咱們關心的信息：

[root@centos6-dev ~]# readelf -sV testerSymbol table '.dynsym' contains 4583 entries:   Num:    Value          Size Type    Bind   Vis      Ndx Name     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND    ......    11: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memcpy@GLIBC_2.14 (5)    ......    67: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND clock_gettime@GLIBC_2.17 (16)    ......  4582: 0000000000794260    70 FUNC    WEAK   DEFAULT   12 _ZNSt15basic_streambufIwSVersion symbols section '.gnu.version' contains 4583 entries: Addr: 000000000045b508  Offset: 0x05b508  Link: 4 (.dynsym)  000:   0 (*local*)       0 (*local*)       2 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)  004:   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)  008:   4 (GLIBC_2.3.2)   3 (GLIBC_2.2.5)   0 (*local*)       5 (GLIBC_2.14)  ......  040:   2 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)  10 (GLIBC_2.17)  ......  11e0:   1 (*global*)      1 (*global*)      1 (*global*)      1 (*global*)  11e4:   1 (*global*)      1 (*global*)      1 (*global*)Version needs section '.gnu.version_r' contains 6 entries: Addr: 0x000000000045d8d8  Offset: 0x05d8d8  Link: 5 (.dynstr)  000000: Version: 1  File: ld-linux-x86-64.so.2  Cnt: 1  0x0010:   Name: GLIBC_2.3  Flags: none  Version: 17  0x0020: Version: 1  File: libgcc_s.so.1  Cnt: 3  0x0030:   Name: GCC_3.0  Flags: none  Version: 13  0x0040:   Name: GCC_3.3  Flags: none  Version: 11  0x0050:   Name: GCC_4.2.0  Flags: none  Version: 10  0x0060: Version: 1  File: libm.so.6  Cnt: 1  0x0070:   Name: GLIBC_2.2.5  Flags: none  Version: 8  0x0080: Version: 1  File: libpthread.so.0  Cnt: 2  0x0090:   Name: GLIBC_2.3.2  Flags: none  Version: 15  0x00a0:   Name: GLIBC_2.2.5  Flags: none  Version: 7  0x00b0: Version: 1  File: libc.so.6  Cnt: 10  0x00c0:   Name: GLIBC_2.8  Flags: none  Version: 19  0x00d0:   Name: GLIBC_2.9  Flags: none  Version: 18  0x00e0:   Name: GLIBC_2.17  Flags: none  Version: 16  0x00f0:   Name: GLIBC_2.4  Flags: none  Version: 14  0x0100:   Name: GLIBC_2.3.4  Flags: none  Version: 12  0x0110:   Name: GLIBC_2.3  Flags: none  Version: 9  0x0120:   Name: GLIBC_2.7  Flags: none  Version: 6  0x0130:   Name: GLIBC_2.14  Flags: none  Version: 5  0x0140:   Name: GLIBC_2.3.2  Flags: none  Version: 4  0x0150:   Name: GLIBC_2.2.5  Flags: none  Version: 3  0x0160: Version: 1  File: libdl.so.2  Cnt: 1  0x0170:   Name: GLIBC_2.2.5  Flags: none  Version: 2

咱們能夠在 ELF 的 .dynsym 動態符號表中看到程序用於動態連接的全部導入導出符號，memcpy 和 clock_gettime 後面括號裏的數字就是十進制的版本號（分別爲 5 和 16），而咱們須要格外關注的是下面的 .gnu.version 和 .gnu.version_r 符號版本信息段。

.gnu.version 表包含全部動態符號的版本信息，.dynsym 動態符號表中的每一個符號均可以在 .gnu.version 中看到對應的條目（.dynsym 中一共 4583 個符號恰好與 .gnu.version 的結束位置 0x11e7 相等）。

從上面的輸出能夠看到 .gnu.version 表從 0x05b508 偏移量開始，咱們能夠看看對應偏移量的十六進制數據：

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F0005B500                          00 00 00 00 02 00 03 00          ........0005B510  03 00 03 00 03 00 03 00 04 00 03 00 00 00 05 00  ................0005B520  03 00 03 00 06 00 00 00 03 00 07 00 08 00 08 00  ................0005B530  03 00 09 00 03 00 03 00 0A 00 07 00 03 00 00 00  ................0005B540  03 00 03 00 0B 00 07 00 03 00 03 00 00 00 07 00  ................0005B550  00 00 03 00 03 00 03 00 03 00 0C 00 09 00 00 00  ................0005B560  07 00 03 00 03 00 07 00 03 00 07 00 0C 00 00 00  ................0005B570  0D 00 03 00 07 00 07 00 0E 00 0F 00 03 00 0D 00  ................0005B580  03 00 03 00 03 00 03 00 02 00 03 00 03 00 10 00  ................0005B590  03 00 00 00 03 00 07 00 08 00 07 00 07 00 03 00  ................0005B5A0  03 00 0D 00 03 00 00 00 03 00 03 00 03 00 00 00  ................

.gnu.version 中的每一個條目佔用兩個字節，其值爲符號的版本，由此能夠看到其中第 0x0b 個符號（也就是 .dynsym 表中的 memcpy@GLIBC_2.14 符號）的偏移量即爲 0x05b51e（0x05b508 + 0x0b x 2），該偏移量的值 0x0005 也恰好和 .dynsym 表中的值對應，固然 clock_gettime 符號對應的偏移量 0x05b58e 的值 0x0010 一樣也是如此。

下面關鍵的 .gnu.version_r 表示二進制程序實際依賴的庫文件版本，從輸出中也能看到 .gnu.version_r 表是按照不一樣的庫文件進行分段顯示的，每一個條目佔用 0x10 也就是 16 個字節，該表是從 0x05d8d8 偏移量開始，咱們看看 GLIBC_2.17 也就是 0x05d9b8 處的十六進制數據：

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F0005D9B0  B0 70 03 00 10 00 00 00 97 91 96 06 00 00 10 00  °p......—‘–.....0005D9C0  BA 70 03 00 10 00 00 00 14 69 69 0D 00 00 0E 00  ºp.......ii.....0005D9D0  C5 70 03 00 10 00 00 00 74 19 69 09 00 00 0C 00  Åp......t.i.....0005D9E0  CF 70 03 00 10 00 00 00 13 69 69 0D 00 00 09 00  Ïp.......ii.....0005D9F0  6A 70 03 00 10 00 00 00 17 69 69 0D 00 00 06 00  jp.......ii.....0005DA00  DB 70 03 00 10 00 00 00 94 91 96 06 00 00 05 00  Ûp......」‘–.....0005DA10  E5 70 03 00 10 00 00 00 72 19 69 09 00 00 04 00  åp......r.i.....0005DA20  9A 70 03 00 10 00 00 00 75 1A 69 09 00 00 03 00  šp......u.i.....0005DA30  8E 70 03 00 00 00 00 00 01 00 01 00 D8 03 00 00  Žp..........Ø...

.gnu.version_r 表中每一個條目是 16 個字節的 Elfxx_Vernaux 結構體，其聲明以下（Elfxx_Half 佔用 2 個字節，Elfxx_Word 佔用 4 個字節）：

typedef struct {    Elfxx_Word    vna_hash;    Elfxx_Half    vna_flags;    Elfxx_Half    vna_other;    Elfxx_Word    vna_name;    Elfxx_Word    vna_next;} Elfxx_Vernaux;

vna_hash 爲 4 個字節的庫名稱（也就是上面的 GLIBC_2.17 字符串）的 hash 值，vna_other 爲對應的 .gnu.version 表中符號的版本值，vna_name 指向庫名稱字符串的偏移量（也能夠在 ELF 頭中找到），vna_next 爲下一個條目的位置（通常固定爲 0x00000010）。

由上面的輸出咱們能夠看到 GLIBC_2.17 對應的 0x05d9b8 處的開始的 4 個字節 vna_hash hash 值爲 0x06969197，而 vna_other 的值 0x0010（輸出裏的 Version: 16）也與 .gnu.version 中 clock_gettime 符號的值一致。一樣 GLIBC_2.14 也與 memcpy 符號的值相符。

修改 ELF 符號表

**
**

因爲 Linux 系統中的 LD 庫（也就是 /lib64/ld-linux-x86-64.so.2 庫）加載 ELF 時檢查 .gnu.version_r 表中的符號，咱們可使用任何一款十六進制編輯器來修改 .gnu.version_r 表中的符號值來強制使用老版本的函數實現。

首先咱們發現 .gnu.version_r 的 libc.so.6 段下面有 10 個條目，最後一個則是咱們須要的 GLIBC_2.2.5 版本的符號（從上面的十六進制輸出中咱們能夠看到該符號的偏移量爲 0x05da28，vna_hash 值爲 0x09691A75，vna_other 版本值爲 0x0003，vna_name 字符串名稱指向 0003708E 地址），由於這樣咱們才能夠在不修改 ELF 文件大小的前提下直接將 libc.so.6 段下的其它高版本條目指向老版本條目的值。

例如 GLIBC_2.17 對應的 0x05d9b8 偏移量，咱們能夠直接將 vna_hash 值改成 GLIBC_2.2.5 的 0x09691A75 值，將 vna_other 改成 0003708E 值，爲了保持和 .gnu.version 表中的版本值一致，這裏咱們就不修改 vna_other 值了。

對於 GLIBC_2.14 偏移量咱們也修改爲一樣的值，修改保存以後的 ELF 文件再使用 readelf 命令檢查就能看到變化了（只列出了修改的 .gnu.version-r 表）：

[root@centos6-dev ~]# readelf -sV tester......Version needs section '.gnu.version_r' contains 6 entries: Addr: 0x000000000045d8d8  Offset: 0x05e8d8  Link: 2 (.dynstr)  000000: Version: 1  File: ld-linux-x86-64.so.2  Cnt: 1  0x0010:   Name: GLIBC_2.3  Flags: none  Version: 17  0x0020: Version: 1  File: libgcc_s.so.1  Cnt: 3  0x0030:   Name: GCC_3.0  Flags: none  Version: 13  0x0040:   Name: GCC_3.3  Flags: none  Version: 11  0x0050:   Name: GCC_4.2.0  Flags: none  Version: 10  0x0060: Version: 1  File: libm.so.6  Cnt: 1  0x0070:   Name: GLIBC_2.2.5  Flags: none  Version: 8  0x0080: Version: 1  File: libpthread.so.0  Cnt: 2  0x0090:   Name: GLIBC_2.3.2  Flags: none  Version: 15  0x00a0:   Name: GLIBC_2.2.5  Flags: none  Version: 7  0x00b0: Version: 1  File: libc.so.6  Cnt: 10  0x00c0:   Name: GLIBC_2.8  Flags: none  Version: 19  0x00d0:   Name: GLIBC_2.9  Flags: none  Version: 18  0x00e0:   Name: GLIBC_2.2.5  Flags: none  Version: 16  0x00f0:   Name: GLIBC_2.4  Flags: none  Version: 14  0x0100:   Name: GLIBC_2.3.4  Flags: none  Version: 12  0x0110:   Name: GLIBC_2.3  Flags: none  Version: 9  0x0120:   Name: GLIBC_2.7  Flags: none  Version: 6  0x0130:   Name: GLIBC_2.2.5  Flags: none  Version: 5  0x0140:   Name: GLIBC_2.3.2  Flags: none  Version: 4  0x0150:   Name: GLIBC_2.2.5  Flags: none  Version: 3  0x0160: Version: 1  File: libdl.so.2  Cnt: 1  0x0170:   Name: GLIBC_2.2.5  Flags: none  Version: 2

patchelf 修改 ELF 文件

**
**

通常的程序若是隻使用了高版本 memcpy 的話，通常這樣修改以後程序就能夠運行了。但不巧我使用的第三方程序還使用了高版本 glibc 中的 clock_gettime，只是這樣修改的話因爲 CentOS 6 的 libc 2.12 庫並無提供 clock_gettime，運行時仍是會報錯。

這個時候咱們就須要請出大殺器 PatchELF 了，這個小工具由 NixOS 團隊開發，能夠直接增長、刪除、替換 ELF 文件依賴的庫文件，使用起來也很是簡單。

檢出 PatchELF 的源代碼，按照 GitHub 倉庫上介紹的步驟編譯安裝就可使用了（通常發行版自帶的 patchelf 工具版本較老不支持一些新的功能）。

雖然 CentOS 6 的 libc 庫沒有提供 clock_gettime 實現，但好在 glibc 自帶的 librt 庫裏仍是提供了的，所以咱們可使用 patchelf 工具修改原版的程序文件，讓程序優先加載 librt 庫，這樣程序就能正確加載 clock_gettime 符號了：

[root@centos6-dev ~]# patchelf --add-needed librt.so.1 tester

而後按照上面介紹的方法用十六進制編輯器修改新生成的 ELF 文件的 .gnu.version_r 表（由於 patchelf 運行以後新 ELF 文件的符號表就和以前的不同了），將 GLIBC_2.17 和 GLIBC_2.14 統一改成 GLIBC_2.2.5 符號，保存 ELF 文件以後就能夠看到效果了：

[root@centos6-dev ~]# ldd tester        linux-vdso.so.1 =>  (0x00007fffc17ee000)        librt.so.1 => /lib64/librt.so.1 (0x00007f7f84dca000)        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7f84bad000)        libOpenCL.so.1 => /usr/lib64/libOpenCL.so.1 (0x00007f7f8498f000)        libdl.so.2 => /lib64/libdl.so.2 (0x00007f7f8478b000)        libm.so.6 => /lib64/libm.so.6 (0x00007f7f84507000)        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f7f842f1000)        libc.so.6 => /lib64/libc.so.6 (0x00007f7f83f5d000)        /lib64/ld-linux-x86-64.so.2 (0x00007f7f84fd2000)

從 ldd 命令的輸出中能夠看到修改後的程序會加載 librt 庫，並且也沒有 glibc 版本的報錯了，通過測試程序運行起來也沒有問題了。

以上就是良許教程網爲各位朋友分享的Linux 修改 ELF 解決 glibc 兼容性問題。

本文由博客一文多發平臺 OpenWrite 發佈！