基于Linux-3.9.4内核的GDB跟踪系统调用实验
382 + 原创作品转载请注明出处 + https://github.com/mengning/linuxkernel/
一、实验环境
win10 -> VMware -> Ubuntu16.04 + GDB -> QEMU -> linux-3.9.4 + MenuOS
二、实验目的
1、了解glibc提供的系统调用函数API，int 0x80、系统调用号及参数传递过程
2、了解保现场和恢复现场的过程
3、使用库函数API和C代码中嵌入式汇编代码两种方式使用同一个系统调用
3、分析system_call中断处理过程
三、实验过程及结果
1、系统内核及系统调用函数的选取
按照实验要求，本次实验需要采用的内核为kernel-5.0版本，在本人实际的实验过程中，一直出现GDB添加断点成功，但是程序运行时并未在断点处停止的现象，经过多次尝试无果之后，决定暂且先使用kernel-3.9.4.的内核，详细问题需要之后解决。
按照实验要求，对于系统调用函数的选取，应该选取和学号末尾数字相同的系统调用，经过查询之后，基于kernel-3.9.4的系统调用中，未含系统调用号为382的系统调用（arch:x86），决定暂且先使用系统调用号为20的系统调用sys_getpid。
图 1 系统调用号最大为350
图 2 系统调用号为20的sys_getpid
2、库函数API和C代码中嵌入式汇编代码两种方式对系统调用的实现
2.1 库函数API的实现
图 3 基于库函数API对sys_getpid的调用实现
需要注意的是，在调用getpid()函数时，需要加上对头文件的引用申明"#include <unistd.h>"，不然可能编译阶段出现失败。
2.2 C代码中嵌入式汇编代码的实现
图 4 基于嵌入式汇编的方式对sys_getpid的调用实现
在上图中，立即数$0x14为sys_getpid在相应的系统调用表中的偏移量(20)，"int $0x80\n\t"，该语句的作用是触发系统调用中断，跳转至系统调用入口处。
3、对应两种方式的GDB跟踪
3.1 环境搭建的大致流程
在搭建实验环境的时候，需要准备的软件环境有：QEMU、GDB、内核的压缩镜像、根文件系统。
在内核镜像的make过程中，首先先执行“make i386_defconfig”，之后再使用"make menuconfig"，基于界面对编译进行配置，为了使得GDB能够跟踪到内核的调试信息，需要选中kernel hacking ->compile the kernel with debug info一栏。保存退出，执行make。
根文件系统的制作，过程相对比较容易理解，对着相关教程执行问题并不大，这里就不再赘述。
在QEMU模拟过程中，对于GDB的参数设置，具体为："file linux-3.9.4/vmlinux"、"target remote:1234"。
3.2 断点设置
图 5 设置的两个端点断点信息
图 6 MenuOS支持的命令
3.3 对基于库函数API方式实现过程的跟踪
在MenuOS命令行下输入mysyscall，会发现其在相应的断点处停止。
图 7 执行getpid()被中断
图 8 进入kernel/timer.c中的SYSCALL_DEFINE0(getpid)函数
图 9 进入arch/x86/include/asm/current.h
图 10 进入inlude/linux/sched.h，之后进入kernel/pid.c
图 11 SYSCALL_DEFINE0(getpid)函数返回
在这时候，GDB继续跟踪的话，效果不明显，经常性出现“Cannot find bounds of current function”，GDB对汇编指令的跟踪效果并不是很好。
3.4 对基于嵌入式汇编方式实现过程的跟踪
在MenuOS命令行下输入mysyscall_asm，会发现其在相应的断点处停止。
图 12 执行被断点1中断
图 13 断点1上下文
图 14 继续执行，停止在断点2，之后的过程与3.3小节内容相似
图 15 两次运行的结果
四、问题与总结
1、问题
在实际的实验过程中，对于mysyscall函数以及mysyscall_asm函数的执行，在第一次执行的时候均可以在断点处停止运行，之后的执行就会无视断点，直接运行结束。对于这个问题，目前的想法是可能对GDB的使用并不是很熟悉。
在实验kernel-5.0的时候，在使用GDB进行调试的过程中，出现一些问题，在解决大部分问题之后，卡在了其中的一个问题之上。
图 16 GDB连接失败（已按照提示解决）
图 17 GDB连接失败（未解决）
对于图17的错误，目前的想法是：可能是配套的python版本不对，在对应的./gdbinit文件中，多次尝试修改失败。
2、总结
对于system_call的过程，其源码如下。
RING0_INT_FRAME # can't unwind into user space anyway
ASM_CLAC
pushl_cfi %eax # save orig_eax
SAVE_ALL
GET_THREAD_INFO(%ebp)
# system call tracing in operation emulation
testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags(%ebp)
jnz syscall_trace_entry
cmpl $(NR_syscalls), %eax
jae syscall_badsys
syscall_call:
call *sys_call_table(,%eax,4)
movl %eax,PT_EAX(%esp) # store the return value
syscall_exit:
LOCKDEP_SYS_EXIT
DISABLE_INTERRUPTS(CLBR_ANY) # make sure we don't miss an interrupt
# setting need_resched or sigpending
# between sampling and the iret
TRACE_IRQS_OFF
movl TI_flags(%ebp), %ecx
testl $_TIF_ALLWORK_MASK, %ecx # current->work
jne syscall_exit_work
TRACE_IRQS_IRET
restore_all_notrace:
movl PT_EFLAGS(%esp), %eax # mix EFLAGS, SS and CS
# Warning: PT_OLDSS(%esp) contains the wrong/random values if we
# are returning to the kernel.
# See comments in process.c:copy_thread() for details.
movb PT_OLDSS(%esp), %ah
movb PT_CS(%esp), %al
andl $(X86_EFLAGS_VM | (SEGMENT_TI_MASK << 8) | SEGMENT_RPL_MASK), %eax
cmpl $((SEGMENT_LDT << 8) | USER_RPL), %eax
CFI_REMEMBER_STATE
je ldt_ss # returning to user-space with LDT SS
restore_nocheck:
INTERRUPT_RETURN
