Socket与系统调用深度分析
Posted zaihua
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Socket与系统调用深度分析相关的知识,希望对你有一定的参考价值。
1. 前言
本文主要阐述C语言socket api追踪至系统调用的详细过程。追踪过程分为用户态的追踪和内核态的追踪。
- 目录
- 用户态追踪
- 系统调用定义
- 系统调用初始化的过程
- 系统调用的执行过程(以socket为例的证明过程)
- 内核态追踪
- 分析replyhi和hello程序
- gdb跟踪
- sys_socket()调用栈
2. 用户态追踪
2.1 系统调用定义
操作系统通过系统调用为运行于其上的进程提供服务。
当用户态进程发起一个系统调用, CPU 将切换到内核态并开始执行一个内核函数 。 内核函数负责响应应用程序的要求,例如操作文件、进行网络通讯或者申请内存资源等。
2.2 系统调用的初始化
- 实验环境:内核Linux-5.0.1,架构x86_32
- 在x86-32位系统下,系统调用初始化过程为:start_kernel --> trap_init --> idt_setup_traps
验证过程:分别在以上函数处打断点,启动内核
- start_kernel是Linux内核的起点,位于init/main.c,功能是对内核的主要模块进行初始化工作。其中有一个trap_init函数调用。
537 asmlinkage __visible void __init start_kernel(void)
538 {
....
595 trap_init();
596 mm_init();
....
740 }
- trap_init()在arch/x86/kernel/traps.c中。可以看到idt_setup_traps()被调用
929 void __init trap_init(void)
930 {
931 /* Init cpu_entry_area before IST entries are set up */
932 setup_cpu_entry_areas();
933
934 idt_setup_traps();
....
955 }
- idt_setup_traps()在arch/x86/kernel/idt.c中。在这里设置各种中断门。
操作系统通过“门”机制向用户态程序提供必要的服务。在x86种有四种门:中断门、陷阱门、调用门、任务门,这些是cpu从硬件层提供的支持。
这四个门就是让CPU找到到哪里去执行异常或中断的处理代码,是中断和异常处理机制。
根据处理异常或中断的区别,选择合适的门来处理。
/* Interrupt gate 中断门*/
#define INTG(_vector, _addr) G(_vector, _addr, DEFAULT_STACK, GATE_INTERRUPT, DPL0, __KERNEL_CS)
/* System interrupt gate 系统中断门 */
#define SYSG(_vector, _addr) G(_vector, _addr, DEFAULT_STACK, GATE_INTERRUPT, DPL3, __KERNEL_CS)
/* Task gate 任务门*/
#define TSKG(_vector, _gdt) G(_vector, NULL, DEFAULT_STACK, GATE_TASK, DPL0, _gdt << 3)
// def_idt的定义
// 可以看到int 0x80对应的中断服务例程是entry_INT80_32。这就是系统调用的中断门
static const __initconst struct idt_data def_idts[] = {
INTG(X86_TRAP_DE, divide_error),
INTG(X86_TRAP_NMI, nmi),
INTG(X86_TRAP_BR, bounds),
INTG(X86_TRAP_UD, invalid_op),
INTG(X86_TRAP_NM, device_not_available),
INTG(X86_TRAP_OLD_MF, coprocessor_segment_overrun),
INTG(X86_TRAP_TS, invalid_TSS),
INTG(X86_TRAP_NP, segment_not_present),
INTG(X86_TRAP_SS, stack_segment),
INTG(X86_TRAP_GP, general_protection),
INTG(X86_TRAP_SPURIOUS, spurious_interrupt_bug),
INTG(X86_TRAP_MF, coprocessor_error),
INTG(X86_TRAP_AC, alignment_check),
INTG(X86_TRAP_XF, simd_coprocessor_error),
#ifdef CONFIG_X86_32
TSKG(X86_TRAP_DF, GDT_ENTRY_DOUBLEFAULT_TSS),
#else
INTG(X86_TRAP_DF, double_fault),
#endif
INTG(X86_TRAP_DB, debug),
#ifdef CONFIG_X86_MCE
INTG(X86_TRAP_MC, &machine_check),
#endif
SYSG(X86_TRAP_OF, overflow),
#if defined(CONFIG_IA32_EMULATION)
SYSG(IA32_SYSCALL_VECTOR, entry_INT80_compat),
#elif defined(CONFIG_X86_32)
SYSG(IA32_SYSCALL_VECTOR, entry_INT80_32),
#endif
};
/**
* idt_setup_traps - Initialize the idt table with default traps
*/
void __init idt_setup_traps(void)
{
idt_setup_from_table(idt_table, def_idts, ARRAY_SIZE(def_idts), true);
}
static void
idt_setup_from_table(gate_desc *idt, const struct idt_data *t, int size, bool sys)
{
gate_desc desc;
for (; size > 0; t++, size--) {
idt_init_desc(&desc, t);
write_idt_entry(idt, t->vector, &desc);
if (sys)
set_bit(t->vector, system_vectors);
}
}
1.3 系统调用的执行流程
- 应用程序代码调用系统调用,该函数是一个包装系统调用的库函数 ;
- 库函数负责准备向内核传递的参数,并触发软中断以切换到内核;
- CPU被软中断打断后,执行中断处理函数,即系统调用处理函数(system_call);
- 系统调用处理函数调用系统调用服务例程sys_XXX,真正开始处理该系统调用;
其中,第2步的从用户态到内核态的切换比较复杂,又分为以下几个步骤
- 在用户态把参数放到对应的寄存器,其中eax存放系统调用号。执行int 0x80指令触发软中断。(参数通过ebx/ecx/edx/est/edi传递)
- CPU 被软中断打断后,执行对应的中断处理函数,这时便已进入内核态 ;
- 系统调用处理函数准备内核执行栈,并保存所有寄存器
- 系统调用处理函数根据系统调用号调用对应的 C 函数—— 系统调用服务例程 ;
- 系统调用处理函数准备返回值并从内核栈中恢复寄存器 ;
- 系统调用处理函数执行ret指令切换回用户态 ;
证明过程如下:
因为我们无法在menuOS里使用gdb,意味着我们无法在socket api打断点来进行追踪。
但从上面的步骤我们可知,程序是通过int 0x80来实现软中断,进而实现系统调用的。
以socket()函数为例。如果我们可以通过软中断的方式实现创建socket,则可证明以上系统调用执行的步骤是正确的。
在menu/test.c里增加menuOS命令和实现。
实现一个sockettest函数,用最简单的socket()函数创建一个socket,判断是否成功并打印。
然后再写一个sockettestASM函数。这里我们不再用socket函数了,而是写入汇编代码,通过寄存器传参,通过"int 0x80来实现软中断"。
其中,%ebx存放PF_INET=2,表示用IP协议。%ecx存放SOCK_STRAEM=1,表示用TCP协议。%edx传0。%eax存放sys_socket系统调用号,为0x167=359。
//系统调用号:arch/x86/include/generated/uapi/asm/unistd_32.h
...
#define __NR_socketcall 102
...
#define __NR_socket 359
#define __NR_socketpair 360
#define __NR_bind 361
#define __NR_connect 362
#define __NR_listen 363
#define __NR_accept4 364
#define __NR_getsockopt 365
#define __NR_setsockopt 366
#define __NR_getsockname 367
#define __NR_getpeername 368
#define __NR_sendto 369
#define __NR_sendmsg 370
#define __NR_recvfrom 371
#define __NR_recvmsg 372
#define __NR_shutdown 373
在menuOS中添加sockettest和sockettestasm命令。
分别运行这两个命令。比较运行结果。
可以看到两种方式都成功创建了socket。可以证明用户态下是通过软中断的方式
3. socket api系统调用分析
3.1 调用socket api的程序
用上次实验的replyhi和hello来跟踪socket api的系统调用
在/lab3/main.c中找到replyhi和hello的实现,并在syswarpper.h里找到每个函数具体调用哪个socket api
#include"syswrapper.h"
#define MAX_CONNECT_QUEUE 1024
// StartReplyhi创建了一个子进程来执行Replyhi
int Replyhi()
{
char szBuf[MAX_BUF_LEN] = "