網易云課堂《Linux內核分析》作業
實驗目的：
使用gdb跟蹤分析一個系統調用中斷處理過程，分析系統調用從system_call開始到iret結束之間的整個過程。
實驗過程：
登陸實驗樓虛擬機http://www.shiyanlou.com/courses/195
打開shell終端，執行以下命令：
cd LinuxKernel
rm -rf menu
git clone https://github.com/mengning/menu.git
獲取到MenuOS源碼后修改test.c文件，加入getuid系統調用函數源碼，Getuid為調用C API版本，GetuidAsm為內嵌匯編語言版本
增加命令菜單
在menu目錄下執行
make rootfs
改造后的MenuOS系統會自動編譯并啟動運行
執行getuid和getuid-asm命令可以看到執行結果
結束qmeu，以調試方式啟動，在LinuxKernel目錄下執行
qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -s -S
打開另一個shell終端，進入gdb調試工具
gdb
讀入符號表
file linux-3.18.6/vmlinux
連接內核調試
target remote:1234
設置斷點
b sys_getuid16
繼續執行
c
列出代碼
list
繼續單步執行后續操作
s
實驗分析：
通過上述實驗過程可以分析出在Linux系統下發生一次系統調用后system_call中斷處理的整個過程。
當在應用程序中調用獲取當前用戶uid函數getuid()，將對應的系統調用號0x18送入eax寄存器，由于沒有其他參數，ebx寄存器賦值為0，執行init 0x80匯編語言指令，從用戶態切換到內核態，觸發系統調用中斷，在system_call的最后是iret匯編語言指令，從系統調用退出，從內核態切換回用戶態。
system_call()函數
首先把系統調用號和這個異常處理程序可以用到的所有CPU寄存器保存到相應的棧中，不包括由控制單元已自動保存的eflags、cs、eip、ss和esp寄存器。
pushl %eax
SAVE_ALL
movl $0xffffe000, %ebx /* or 0xfffff000 for 4-KB stacks */
andl %esp, %ebx
接下來檢查thread_info結構flag字段的TIF_SYSCALL_TRACE和TIF_SYSCALL_AUDIT標志之一是否被置為1，即檢查是否有某一調試程序正在跟蹤執行程序對系統調用的調用。
如果系統調用號無效則把-ENOSYS值存放在棧中曾保存eax寄存器的單元中，當進程恢復在用戶態的執行時會在eax中得到一個負的返回碼。
cmpl $NR_syscalls, %eax
jb nobadsys
movl $(-ENOSYS), 24(%esp)
jmp resume_userspaces
最后調用與eax中所包含的系統調用號對應的特定服務例程。
call *sys_call_table(0, %eax, 4)
從系統調用退出
當系統調用服務例程結束時，system_call()函數從eax獲得返回值，并保存在曾經保存用戶態eax寄存器值的棧單元位置上，用戶態進程將在eax中找到系統調用的返回碼。
movl %eax, 24(%esp)
system_call()函數關閉本地中斷并檢查當前進程的thread_info結構中的標志，如果所有的標志都沒有被設置函數就會跳轉到restore_all標記處，恢復保存在內核棧中的寄存器的值，并執行iret匯編語言指令以重新開始執行用戶態進程。
cli
movl 8(%ebp), %ecx
testw $0xffff, %cx
je restore_all
實驗總結：
Linux內核在啟動初始化期間會調用trap_init()函數設置向量128（十六進制0x80）對應的內核入口點。當初始化完畢后，程序需要執行系統調用時，只需執行init 0x80語句，發生一個向量128的中斷即可。
系統調用本質上是發生了一次軟件中斷。
部分資料參考《深入理解Linux內核》
aapu原創作品轉載請注明出處《Linux內核分析》MOOC課
