OpenHarmony—Linux之系统调用

Linux之系统调用

这里我们只讨论：

硬件： Arm64
系统： Linux系统 (Kernel-5.15-rc1)
高级语言： C （glibc-2.34）
模式： 64位（即未定义CONFIG_COMPAT）

2、什么是系统调用

Linux系统分为内核态和用户态，两者是相互隔离的。为了防止各种应用程序可能对系统资源的破坏，用户态的应用程序是没有权限直接去访问系统资源的，当需要访问时，就需要通过系统调用。

系统调用是内核提供给用户态应用程序的一系列统一接口，标准库或API在系统调用的基础上做了进一步抽象和封装。用户态的应用程序可以直接进行系统调用，也可以通过标准库或API来调用

一个系统调用有很多个步骤，其中一个很重要的就是用户态和内核态相互切换，包括CPU模式的切换，内核栈、用户栈的保护与处理等

大致的流程为：

-----------------------------------------
                |
    用户态       |           内核态 
                |
标准库或API -> 模式切换 -> 调用准备
                |               \    
                |                 ->  处理
                |                 <-  函数
                |               /
标准库或API <- 模式切换 <- 调用善后   
                |
-----------------------------------------

下面我们就分别讨论用户态、内核态下的一些关键处理

3、用户态的处理

那么如何陷入内核态呢？主要是通过同步异常来实现。ARM64专门定义了svc指令，用于进入同步异常，也就是说，一旦执行了svc指令，cpu立即跳转到同步异常入口地址处，从这个地址进入内核态

下面已glic里面的系统调用为例，简单看看过程：

ARM64相关的代码主要在：sysdeps/unix/sysv/linux/aarch64

比如我们常用的glibc库函数ioctl(), 在arm64下，glibc的实现：

ENTRY(__ioctl)
	mov	x8, #__NR_ioctl
	sxtw	x0, w0
	svc	#0x0
	cmn	x0, #4095
	b.cs	.Lsyscall_error
	ret
PSEUDO_END (__ioctl)

其中#__NR_ioctl就对应的ioctl的系统调用号，其定义是在sysdeps/unix/sysv/linux/aarch64/arch-syscall.h，如下：

...

#define __NR_io_uring_setup 425
#define __NR_ioctl 29   //
#define __NR_ioprio_get 31

...

这个系统调用号(29)就是上层标准库（API）与内核联系的桥梁，和内核中的定义是对应的(arm64: include/uapi/asm-generic/unistd.h)：

...

/* fs/ioctl.c */
#define __NR_ioctl 29
__SC_COMP(__NR_ioctl, sys_ioctl, compat_sys_ioctl)

...

所以相关用户态的基本流程大致为：

1.将系统调用号存放在x8寄存器中

2.执行svc指令，陷入异常，并且从el0切换到el1

4、内核态的处理

当用户态进入同步异常，便会跳转到同步异常入口地址，从而触发内核相应的处理动作。

在内核中，arm64对应的异常向量表为(arch/arm64/kernel/entry.S)：

/*
 * Exception vectors.
 */
	.pushsection ".entry.text", "ax"

	.align	11
SYM_CODE_START(vectors)
	kernel_ventry	1, t, 64, sync		// Synchronous EL1t
	kernel_ventry	1, t, 64, irq		// IRQ EL1t
	kernel_ventry	1, t, 64, fiq		// FIQ EL1h
	kernel_ventry	1, t, 64, error		// Error EL1t

	kernel_ventry	1, h, 64, sync		// Synchronous EL1h
	kernel_ventry	1, h, 64, irq		// IRQ EL1h
	kernel_ventry	1, h, 64, fiq		// FIQ EL1h
	kernel_ventry	1, h, 64, error		// Error EL1h

	kernel_ventry	0, t, 64, sync		// Synchronous 64-bit EL0
	kernel_ventry	0, t, 64, irq		// IRQ 64-bit EL0
	kernel_ventry	0, t, 64, fiq		// FIQ 64-bit EL0
	kernel_ventry	0, t, 64, error		// Error 64-bit EL0

	kernel_ventry	0, t, 32, sync		// Synchronous 32-bit EL0
	kernel_ventry	0, t, 32, irq		// IRQ 32-bit EL0
	kernel_ventry	0, t, 32, fiq		// FIQ 32-bit EL0
	kernel_ventry	0, t, 32, error		// Error 32-bit EL0
SYM_CODE_END(vectors)

SYM_CODE_START 其实就是将其后面()里面的字符展开而已，并在这个展开之前加上一些属性（比如对齐规则），展开后就相当于”vectors:”，表示定义vectors函数，“:”后面就是vectors的具体实现.

设置不同mode下的异常向量表，异常可以分为4组，每组异常有4个，所以这里一共会设置16个entry。4组异常分别对应4种情况下发生异常时的处理。上面的4组，按照顺序分别对应如下4中情况：

（1）运行级别不发生切换，从ELx变化到ELx，使用SP_EL0，这种情况在Linux kernel都是不处理的，使用invalid entry。

（2）运行级别不发生切换，从ELx变化到ELx，使用SP_ELx。这种情况下在Linux中比较常见。

（3）异常需要进行级别切换来进行处理，并且使用aarch64模式处理，比如64位用户态程序发生系统调用，CPU会从EL0切换到EL1，并且使用aarch64模式处理异常。

（4）异常需要进行级别切换来进行处理，并且使用aarch32模式处理。比如32位用户态程序发生系统调用，CPU会从EL0切换到EL1，并且使用aarch32模式进行处理。

这里我们只讨论64位模式，所以系统调用是第3种情况

继续往下看，

展开kernel_ventry, kernel_ventry(arch/arm64/kernel/entry.S)是一个宏，通过.macro和.endm组合定义

.macro kernel_ventry, el:req, ht:req, regsize:req, label:req

...

b	el\el\ht\()_\regsize\()_\label
.endm

里面会跳转到el\el\ht\()_\regsize\()_\label:

SYM_CODE_START_LOCAL(el\el\ht\()_\regsize\()_\label)
	kernel_entry \el, \regsize
	mov	x0, sp
	bl	el\el\ht\()_\regsize\()_\label\()_handler
	.if \el == 0
	b	ret_to_user
	.else
	b	ret_to_kernel
	.endif
SYM_CODE_END(el\el\ht\()_\regsize\()_\label)

其中便会调用对应的el\el\ht\()_\regsize\()_\label\()_handler函数

通过解析，sync的处理对应的就是el0t_64_sync_handler()函数，跟踪代码，该函数的处理流程：

el0t_64_sync_handler() [arch/arm64/kernel/entry-common.c]
    -> el0_svc() 
        -> do_el0_svc() [arch/arm64/kernel/syscall.c]
            -> el0_svc_common()
                -> invoke_syscall() 
                    -> __invoke_syscall()

其中最主要的流程在el0_svc()函数：

static void noinstr el0_svc(struct pt_regs *regs)
{
	enter_from_user_mode(regs);
	cortex_a76_erratum_1463225_svc_handler();
	do_el0_svc(regs);
	exit_to_user_mode(regs);
}

最终会调用到invoke_syscall()，该函数会根据传入的系统调用号，在sys_call_table中找到对应的系统调用函数，并执行

static void invoke_syscall(struct pt_regs *regs, unsigned int scno,
			   unsigned int sc_nr,
			   const syscall_fn_t syscall_table[])
{
	long ret;

	add_random_kstack_offset();

	if (scno < sc_nr) {
		syscall_fn_t syscall_fn;
		syscall_fn = syscall_table[array_index_nospec(scno, sc_nr)];
		ret = __invoke_syscall(regs, syscall_fn);
	} else {
		ret = do_ni_syscall(regs, scno);
	}

	syscall_set_return_value(current, regs, 0, ret);

	/*
	 * Ultimately, this value will get limited by KSTACK_OFFSET_MAX(),
	 * but not enough for arm64 stack utilization comfort. To keep
	 * reasonable stack head room, reduce the maximum offset to 9 bits.
	 *
	 * The actual entropy will be further reduced by the compiler when
	 * applying stack alignment constraints: the AAPCS mandates a
	 * 16-byte (i.e. 4-bit) aligned SP at function boundaries.
	 *
	 * The resulting 5 bits of entropy is seen in SP[8:4].
	 */
	choose_random_kstack_offset(get_random_int() & 0x1FF);
}

4.1、sys_call_table

sys_call_table的定义：

/// arch/arm64/kernel/sys.c

asmlinkage long __arm64_sys_ni_syscall(const struct pt_regs *__unused)
{
	return sys_ni_syscall();
}

/*
 * Wrappers to pass the pt_regs argument.
 */
#define __arm64_sys_personality		__arm64_sys_arm64_personality

#undef __SYSCALL
#define __SYSCALL(nr, sym)	asmlinkage long __arm64_##sym(const struct pt_regs *);
#include <asm/unistd.h>

#undef __SYSCALL
#define __SYSCALL(nr, sym)	[nr] = __arm64_##sym,

const syscall_fn_t sys_call_table[__NR_syscalls] = {
	[0 ... __NR_syscalls - 1] = __arm64_sys_ni_syscall,
#include <asm/unistd.h>
};

首先会将sys_call_table都初始化为sys_ni_syscall()，这里使用了GCC的扩展语法：指定初始化

sys_ni_syscall()为一个空函数，未做任何操作：

/// kernel/sys_ni.c

asmlinkage long sys_ni_syscall(void)
{
	return -ENOSYS;
}

然后包含asm/unistd.h的进行逐项初始化，asm/unistd.h最终会包含到uapi/asm-generic/unistd.h头文件：

...

#ifdef __SYSCALL_COMPAT
#define __SC_COMP(_nr, _sys, _comp) __SYSCALL(_nr, _comp)
#define __SC_COMP_3264(_nr, _32, _64, _comp) __SYSCALL(_nr, _comp)
#else
#define __SC_COMP(_nr, _sys, _comp) __SYSCALL(_nr, _sys)
#define __SC_COMP_3264(_nr, _32, _64, _comp) __SC_3264(_nr, _32, _64)
#endif

#define __NR_io_setup 0
__SC_COMP(__NR_io_setup, sys_io_setup, compat_sys_io_setup)
#define __NR_io_destroy 1
__SYSCALL(__NR_io_destroy, sys_io_destroy)
#define __NR_io_submit 2
__SC_COMP(__NR_io_submit, sys_io_submit, compat_sys_io_submit)
#define __NR_io_cancel 3
__SYSCALL(__NR_io_cancel, sys_io_cancel)

...

4.2 SYSCALL_DEFINEx

内核中具体的系统调用实现使用SYSCALL_DEFINEx来定义，其中x代表传入参数的个数，

SYSCALL_DEFINEx相关代码:

/// include/linux/syscalls.h

#define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
#define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
#define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)
#define SYSCALL_DEFINE5(name, ...) SYSCALL_DEFINEx(5, _##name, __VA_ARGS__)
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)

#define SYSCALL_DEFINE_MAXARGS	6

#define SYSCALL_DEFINEx(x, sname, ...)				\
	SYSCALL_METADATA(sname, x, __VA_ARGS__)			\
	__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)

而对于ARM64，__SYSCALL_DEFINEx的定义为：

/// arch/arm64/include/asm/syscall_wrapper.h

#define __SYSCALL_DEFINEx(x, name, ...)						\
	asmlinkage long __arm64_sys##name(const struct pt_regs *regs);		\
	ALLOW_ERROR_INJECTION(__arm64_sys##name, ERRNO);			\
	static long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__));		\
	static inline long __do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));	\
	asmlinkage long __arm64_sys##name(const struct pt_regs *regs)		\
	{									\
		return __se_sys##name(SC_ARM64_REGS_TO_ARGS(x,__VA_ARGS__));	\
	}									\
	static long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))		\
	{									\
		long ret = __do_sys##name(__MAP(x,__SC_CAST,__VA_ARGS__));	\
		__MAP(x,__SC_TEST,__VA_ARGS__);					\
		__PROTECT(x, ret,__MAP(x,__SC_ARGS,__VA_ARGS__));		\
		return ret;							\
	}									\
	static inline long __do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))

由上面可以看出，SYSCALL_DEFINEx来定义的函数就和sys_call_table中由__SYSCALL确定的函数对应了，即__arm64_sys##name

例如ioctl()内核态的实现为：

SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
{
	struct fd f = fdget(fd);
	int error;

	if (!f.file)
		return -EBADF;

	error = security_file_ioctl(f.file, cmd, arg);
	if (error)
		goto out;

	error = do_vfs_ioctl(f.file, fd, cmd, arg);
	if (error == -ENOIOCTLCMD)
		error = vfs_ioctl(f.file, cmd, arg);

out:
	fdput(f);
	return error;
}

想学习更多华为鸿蒙HarmonyOS开发知识，在这里我为大家准备了华为鸿蒙HarmonyOS开发者资料大全，大家可以自行点击链接领取：《做鸿蒙应用开发到底学习些啥？》