基于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
![](https://img2018.cnblogs.com/blog/1627594/201903/1627594-20190319121550871-1135050984.png)