最近因為一個很有意思的段錯誤學習了一些新的東西。
當時現象是這樣的，程序正在運行，系統升級，此時某些so已經被該程序所使用，現在把這些so文件覆蓋了，導致了該程序崩潰。
調試dump文件可以發現是崩潰在了ld解析函數符號的時候，然後查看libc的源碼，發現崩潰的函數checkmatch傳入的參數是空指針，所以導致了崩潰。因為受到以前寫裸機代碼的影響，裸機是這樣的，如果前2M stepstorm不夠用，那麼在stepstorm中的代碼就把nandflash中的代碼拷貝到內存中，然後跳轉到內存中去運行，所以此時就算源文件再怎麼被修改也不會受到nandflash中的內容影響。下面先講兩個需要用到的知識點。
Linux下很重要的一點是，一個文件可以被很多應用程序打開，同一時間的確只有一個應用程序可以對該文件讀寫，但是在不同時刻，所有應用程序對文件的操作都會影響到其他已打開該文件的應用程序，因為在每次讀寫前，系統調用read和write會對內存中的內容進行有效性判斷。
再講一個有關mmap或者mmap2的事情，
void *mmap(void *addr, size_t len, int prot, int flags, int fd, off_t offset);
addr是要映射到的內存地址，返回值也是被映射到的內存地址，因為一般指定為0，有內核選擇一段可用的內存空間。
len表示要映射的內存大小。
prot表示這段內存的訪問權限。
flags表示映射後內存的類型，主要是對該內存的寫是否會影響到原文件。
fd表示文件描述符，
offset表示需要映射的文件內容相對文件頭偏移量。
映射完了之後，對這個內存的訪問就是對文件的訪問。
下面看栗子：
源碼:
共享庫：
#include <stdio.h>
int fun1()
{
printf("fun1\n");
}
main函數
int fun1();
int main()
{
while(1){
sleep(10);
fun1();
}
}
這個代碼很簡單，下面先用strace跟蹤下test的運行:
strace ./test
execve("./test", ["./test"], [/* 22 vars */]) = 0
brk(0) = 0x9653000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7731000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("tls/i686/sse2/cmov/lib1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("tls/i686/sse2/lib1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("tls/i686/cmov/lib1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("tls/i686/lib1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("tls/sse2/cmov/lib1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("tls/sse2/lib1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("tls/cmov/lib1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("tls/lib1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("i686/sse2/cmov/lib1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("i686/sse2/lib1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("i686/cmov/lib1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("i686/lib1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("sse2/cmov/lib1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("sse2/lib1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("cmov/lib1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("lib1.so", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\3\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=6732, ...}) = 0
getcwd("/home/keda/caozhenhua/test/updateso", 128) = 36
mmap2(NULL, 8212, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb772e000
mmap2(0xb772f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0xb772f000
close(3) = 0
open("tls/i686/sse2/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("tls/i686/sse2/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("tls/i686/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("tls/i686/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("tls/sse2/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("tls/sse2/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("tls/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("i686/sse2/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("i686/sse2/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("i686/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("i686/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("sse2/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("sse2/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/keda/caozhenhua/test/updateso/tls/i686/sse2/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/keda/caozhenhua/test/updateso/tls/i686/sse2/cmov", 0xbf9bd320) = -1 ENOENT (No such file or directory)
open("/home/keda/caozhenhua/test/updateso/tls/i686/sse2/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/keda/caozhenhua/test/updateso/tls/i686/sse2", 0xbf9bd320) = -1 ENOENT (No such file or directory)
open("/home/keda/caozhenhua/test/updateso/tls/i686/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/keda/caozhenhua/test/updateso/tls/i686/cmov", 0xbf9bd320) = -1 ENOENT (No such file or directory)
open("/home/keda/caozhenhua/test/updateso/tls/i686/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/keda/caozhenhua/test/updateso/tls/i686", 0xbf9bd320) = -1 ENOENT (No such file or directory)
open("/home/keda/caozhenhua/test/updateso/tls/sse2/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/keda/caozhenhua/test/updateso/tls/sse2/cmov", 0xbf9bd320) = -1 ENOENT (No such file or directory)
open("/home/keda/caozhenhua/test/updateso/tls/sse2/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/keda/caozhenhua/test/updateso/tls/sse2", 0xbf9bd320) = -1 ENOENT (No such file or directory)
open("/home/keda/caozhenhua/test/updateso/tls/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/keda/caozhenhua/test/updateso/tls/cmov", 0xbf9bd320) = -1 ENOENT (No such file or directory)
open("/home/keda/caozhenhua/test/updateso/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/keda/caozhenhua/test/updateso/tls", 0xbf9bd320) = -1 ENOENT (No such file or directory)
open("/home/keda/caozhenhua/test/updateso/i686/sse2/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/keda/caozhenhua/test/updateso/i686/sse2/cmov", 0xbf9bd320) = -1 ENOENT (No such file or directory)
open("/home/keda/caozhenhua/test/updateso/i686/sse2/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/keda/caozhenhua/test/updateso/i686/sse2", 0xbf9bd320) = -1 ENOENT (No such file or directory)
open("/home/keda/caozhenhua/test/updateso/i686/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/keda/caozhenhua/test/updateso/i686/cmov", 0xbf9bd320) = -1 ENOENT (No such file or directory)
open("/home/keda/caozhenhua/test/updateso/i686/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/keda/caozhenhua/test/updateso/i686", 0xbf9bd320) = -1 ENOENT (No such file or directory)
open("/home/keda/caozhenhua/test/updateso/sse2/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/keda/caozhenhua/test/updateso/sse2/cmov", 0xbf9bd320) = -1 ENOENT (No such file or directory)
open("/home/keda/caozhenhua/test/updateso/sse2/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/keda/caozhenhua/test/updateso/sse2", 0xbf9bd320) = -1 ENOENT (No such file or directory)
open("/home/keda/caozhenhua/test/updateso/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/keda/caozhenhua/test/updateso/cmov", 0xbf9bd320) = -1 ENOENT (No such file or directory)
open("/home/keda/caozhenhua/test/updateso/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/keda/caozhenhua/test/updateso", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=83733, ...}) = 0
mmap2(NULL, 83733, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7719000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\226\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1713640, ...}) = 0
mmap2(NULL, 1723100, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7574000
mmap2(0xb7713000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19f) = 0xb7713000
mmap2(0xb7716000, 10972, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7716000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7573000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7572000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb75726c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7713000, 8192, PROT_READ) = 0
mprotect(0xb772e000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0xb772e000, 4096, PROT_READ|PROT_EXEC) = 0
mprotect(0xb772f000, 4096, PROT_READ) = 0
mprotect(0x8049000, 4096, PROT_READ) = 0
mprotect(0xb7754000, 4096, PROT_READ) = 0
munmap(0xb7719000, 83733) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({10, 0},
0xbf9bd958) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb772d000
write(1, "fun1\n", 5fun1
) = 5
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({10, 0},
可以看到每打開一個共享庫，linux利用的是mmap2，而不是像裸機一樣的read和write。
所以這樣的話，比如需要跳轉到共享庫中的某個函數，如果是第一次的話，那麼需要從文件中把內容加載到內存，然後再運行。
那麼如果在程序運行時，出現缺頁，那麼就需要從內存中重新讀取該文件的該段內容，而如果該文件被修改了而且該段是第一次被訪問，那麼讀取到的內容將會導致不可預知的錯誤。
接下來再對mmap實驗。
源碼：
#include <sys/mman.h>
#include <fcntl.h>
int main()
{
int fd;
int i = 0;
char *buf;
fd = open("./libvsipstack.a",O_RDONLY);
buf = mmap(0,10,PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,fd,0);
while(1)
{
i++;
sleep(10);
printf("%c\n",buf[i]);
}
}
mmap的映射方式和加載庫的方式一致，
然後在程序運行時我用vi修改了libvsipstack.a，修改之後可以看到libvsipstack.a是有一個備份文件的。此時是可以保證數據是正確的。
-rwxrwxrwx 1 root root 886056 2016-07-22 12:15 \ -rwxrwxrwx 1 root root 7249 2016-07-22 12:12 a.out -rwxrwxrwx 1 root root 12 2016-07-22 12:12 hello.c -rwxrwxrwx 1 root root 886056 2016-07-22 12:16 libvsipstack.a -????????? ? ? ? ? ? libvsipstack.a~ -rwxrwxrwx 1 root root 263 2016-07-22 12:12 test.c
而當我們在上面的實驗中，用libvsipstack.a覆蓋lib1.so，並沒有導致lib1.so有一個備份，而是變成了libvsipstack.a一樣的文件。所以下一次讀取將會和源文件不一致。
-rwxrwxrwx 1 root root 0 2016-07-22 09:08 core -rwxrwxrwx 1 root root 54 2016-07-21 13:37 lib1.c -rwxrwxrwx 1 root root 886022 2016-07-22 12:21 lib1.so -rwxrwxrwx 1 root root 6732 2016-07-22 09:22 lib2.so -rwxrwxrwx 1 root root 886022 2016-07-21 15:39 libvsipstack.a -rwxrwxrwx 1 root root 7164 2016-07-22 09:16 test -rwxrwxrwx 1 root root 65 2016-07-22 09:10 test.c
需要知道當源文件更新時，使用mmap到的內存，系統會去重新讀取文件中的內容。
所以當庫被更新時，同時會更新內存中的內容。
總結一下,
是否崩在ld中，是由是否是第一次調用該函數決定的，因為只有第一次調用才會需要去解析plt表中的內容。
首先內存的布局是根據elf文件頭來部署的。所以替換前後的文件不是同一個那麼就會導致非法指令之類的錯誤，根本無法確定錯誤來源。
但如果替換前後庫是一致的，那麼差別就在於，重定向表的內容變的無效了。
重定向表有兩種一種是在程序啟動時就完成符號解析的，看栗子
Dump of assembler code for function fun1: 0xb7fd846c <+0>: 55 push %ebp 0xb7fd846d <+1>: 89 e5 mov %esp,%ebp 0xb7fd846f <+3>: 83 ec 18 sub $0x18,%esp 0xb7fd8472 <+6>: c7 04 24 d4 04 00 00 movl $0x4d4,(%esp) 0xb7fd8479 <+13>: e8 fc ff ff ff call 0xb7fd847a <fun1+14> 0xb7fd847e <+18>: c9 leave 0xb7fd847f <+19>: c3 ret
本來+13位置處的代碼已經完成了重定向，但是重新讀取之後呢，恢復了重定向之前的情況，結果崩潰。
另一種是懶惰式的加載，是先跳到plt表的情況，看栗子
0xb7fd845c <+0>: push %ebp 0xb7fd845d <+1>: mov %esp,%ebp 0xb7fd845f <+3>: push %ebx 0xb7fd8460 <+4>: sub $0x14,%esp 0xb7fd8463 <+7>: call 0xb7fd8457 <__i686.get_pc_thunk.bx> 0xb7fd8468 <+12>: add $0x1b8c,%ebx 0xb7fd846e <+18>: lea -0x1b12(%ebx),%eax 0xb7fd8474 <+24>: mov %eax,(%esp) 0xb7fd8477 <+27>: call 0xb7fd8380 <puts@plt> 0xb7fd847c <+32>: add $0x14,%esp 0xb7fd847f <+35>: pop %ebx 0xb7fd8480 <+36>: pop %ebp 0xb7fd8481 <+37>: ret End of assembler dump. (gdb) disassemble 0xb7fd8380 Dump of assembler code for function puts@plt: 0xb7fd8380 <+0>: jmp *0x10(%ebx) 0xb7fd8386 <+6>: push $0x8 0xb7fd838b <+11>: jmp 0xb7fd8360 End of assembler dump. (gdb) i r eax 0xb7fd84e2 -1208122142 ecx 0xbffff6a8 -1073744216 edx 0xb7fbeff4 -1208225804 ebx 0xb7fd9ff4 -1208115212 esp 0xbffff6ac 0xbffff6ac ebp 0xbffff6c8 0xbffff6c8 esi 0x0 0 edi 0x0 0 eip 0x386 0x386 eflags 0x210292 [ AF SF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) disassemble 0x00000386 No function contains specified address. (gdb) x/x 0xb7fd9ff4+0x10 0xb7fda004: 0x00000386
可以看到先跳到了plt表，因為是重新讀入，相當於還沒有重定位，所以跳轉到下一句話，可以反匯編看到0x386就是原反匯編沒有偏移地址的地址大小。
00000380 <puts@plt>: 380: ff a3 10 00 00 00 jmp *0x10(%ebx) 386: 68 08 00 00 00 push $0x8 38b: e9 d0 ff ff ff jmp 360 <_init+0x3c>
所以這裡面的情況相當於基地址被初始為了0，導致崩潰。
因為mmap被調用時指明的是private，所以內存的修改不會影響到文件的內容，但是文件的修改會影響到內存的內容，所以導致了崩潰的產生。
說這個是系統的bug也可以，說是自己的使用不當也可以。
還有一個是權限問題，除了擁有root權限的用戶，是不可以這樣隨意覆蓋文件的。
本文永久更新鏈接地址：
http://xxxxxx/Linuxjc/1145141.html TechArticle
