openharmony源码静态分析

放原子开源基金会（简称“基金会”）于 2020 年 9 月接受华为捐赠的智能终端操作系统基础能力相关代码，随后进行开源，并根据命名规则为该开源项目命名为 OpenAtom OpenHarmony（简称“OpenHarmony”）。

OpenHarmony是自主研发、不兼容安卓的全领域下一代开源操作系统。OpenHarmony内核主要包括进程和线程调度、内存管理、IPC机制、timer管理等内核基本功能。

#ifndef __scc

#define __scc（X） （（long） （X）） // 转为long类型

typedef long syscall_arg_t;

#endif

#define __syscall1（n，a） __syscall1（n，__scc（a））

#define __syscall2（n，a，b） __syscall2（n，__scc（a），__scc（b））

#define __syscall3（n，a，b，c） __syscall3（n，__scc（a），__scc（b），__scc（c）） //

继续搜索发现有多出匹配，我们关注arch/arm目录下的文件，因为ARM Cortext A7是Armv7-A指令集的32位CPU（如果是Armv8-A指令集的64位CPU则对应arch/aarch64下的文件）：

static inline long __syscall3（long n， long a， long b， long c）

{

register long r7 __ASM____R7__ = n;

register long r0 __asm__（“r0”） = a;

register long r1 __asm__（“r1”） = b;

register long r2 __asm__（“r2”） = c;

__asm_syscall（R7_OPERAND， “0”（r0）， “r”（r1）， “r”（r2））;

}

这段代码中还有三个宏，__ASM____R7__、__asm_syscall和R7_OPERAND：

#ifdef __thumb__

#define __ASM____R7__

#define __asm_syscall（。。.） do { \

__asm__ __volatile__ （ “mov %1，r7 ; mov r7，%2 ; svc 0 ; mov r7，%1” \

： “=r”（r0）， “=&r”（（int）{0}） ： __VA_ARGS__ ： “memory”）; \

return r0; \

} while （0）

#else // __thumb__

#define __ASM____R7__ __asm__（“r7”）

#define __asm_syscall（。。.） do { \

__asm__ __volatile__ （ “svc 0” \

： “=r”（r0） ： __VA_ARGS__ ： “memory”）; \

return r0; \

} while （0）

#endif // __thumb__

#ifdef __thumb2__

#define R7_OPERAND “rI”（r7）

#else

#define R7_OPERAND “r”（r7）

#endif

它们有两个实现版，分别对应于编译器THUMB选项的开启和关闭。这两种选项条件下的代码流程基本一致，以下仅以未开启THUMB选项为例进行分析。这两个宏展开后的__syscall3函数内容为：

static inline long __syscall3（long n， long a， long b， long c）

{

register long r7 __asm__（“r7”） = n; // 系统调用号

register long r0 __asm__（“r0”） = a; // 参数0

register long r1 __asm__（“r1”） = b; // 参数1

register long r2 __asm__（“r2”） = c; // 参数2

do { \

__asm__ __volatile__ （ “svc 0” \

： “=r”（r0） ： “r”（r7）， “0”（r0）， “r”（r1）， “r”（r2） ： “memory”）; \

return r0; \

} while （0）;

}

这里最后的一个内嵌汇编比较复杂，它符合如下格式（具体细节可以查阅gcc内嵌汇编文档的扩展汇编说明）：

asm asm-qualifiers （ AssemblerTemplate

： OutputOperands

［ ： InputOperands

［ ： Clobbers ］ ］）

汇编模板为：“svc 0”， 输出参数部分为：“=r”（r0），输出寄存器为r0输入参数部分为：“r”（r7）， “0”（r0）， “r”（r1）， “r”（r2），输入寄存器为r7，r0，r1，r2，（“0”的含义是，这个输入寄存器必须和输出寄存器第0个位置一样） Clobber部分为：“memory”

这里我们只需要记住：系统调用号存放在r7寄存器，参数存放在r0，r1，r2，返回值最终会存放在r0中；

SVC指令，ARM Cortex A7手册 的解释为：

The SVC instruction causes a Supervisor Call exception. This provides a mechanism for unprivileged software to make a call to the operating system， or other system component that is accessible only at PL1.

翻译过来就是说

SVC指令会触发一个“特权调用”异常。这为非特权软件调用操作系统或其他只能在PL1级别访问的系统组件提供了一种机制。

详细的指令说明在

到这里，我们分析了鸿蒙系统上应用程序如何进入内核态，主要分析的是musl libc的实现。

liteos-a内核的系统调用实现分析

既然SVC能够触发一个异常，那么我们就要看看liteos-a内核是如何处理这个异常的。

ARM Cortex A7中断向量表

在ARM架构参考手册中，可以找到中断向量表的说明：

可以看到SVC中断向量的便宜地址是0x08，我们可以在kernel/liteos_a/arch/arm/arm/src/startup目录的reset_vector_mp.S文件和reset_vector_up.S文件中找到相关汇编代码：

__exception_handlers：

/*

*Assumption： ROM code has these vectors at the hardware reset address.

*A simple jump removes any address-space dependencies ［i.e. safer］

*/

b reset_vector

b _osExceptUndefInstrHdl

b _osExceptSwiHdl

b _osExceptPrefetchAbortHdl

b _osExceptDataAbortHdl

b _osExceptAddrAbortHdl

b OsIrqHandler

b _osExceptFiqHdl

PS:kernel/liteos_a/arch/arm/arm/src/startup目录有两个文件reset_vector_mp.S文件和reset_vector_up.S文件分别对应多核和单核编译选项：

ifeq （$（LOSCFG_KERNEL_SMP）， y）

LOCAL_SRCS += src/startup/reset_vector_mp.S

else

LOCAL_SRCS += src/startup/reset_vector_up.S

endif

SVC中断处理函数

上面的汇编代码中可以看到，_osExceptSwiHdl函数就是SVC异常处理函数，具体实现在kernel/liteos_a/arch/arm/arm/src/los_hw_exc.S文件中：

@ Description： Software interrupt exception handler

_osExceptSwiHdl：

SUB SP， SP， #（4 * 16） @ 栈增长

STMIA SP， {R0-R12} @ 保存R0-R12寄存器到栈上

MRS R3， SPSR @ 移动SPSR寄存器的值到R3

MOV R4， LR

AND R1， R3， #CPSR_MASK_MODE @ Interrupted mode

CMP R1， #CPSR_USER_MODE @ User mode

BNE OsKernelSVCHandler @ Branch if not user mode

@ we enter from user mode， we need get the values of USER mode r13（sp） and r14（lr）。

@ stmia with ^ will return the user mode registers （provided that r15 is not in the register list）。

MOV R0， SP

STMFD SP！， {R3} @ Save the CPSR

ADD R3， SP， #（4 * 17） @ Offset to pc/cpsr storage

STMFD R3！， {R4} @ Save the CPSR and r15（pc）

STMFD R3， {R13， R14}^ @ Save user mode r13（sp） and r14（lr）

SUB SP， SP， #4

PUSH_FPU_REGS R1

MOV FP， #0 @ Init frame pointer

CPSIE I @ Interrupt Enable

BLX OsArmA32SyscallHandle

CPSID I @ Interrupt Disable

POP_FPU_REGS R1

ADD SP， SP，#4

LDMFD SP！， {R3} @ Fetch the return SPSR

MSR SPSR_cxsf， R3 @ Set the return mode SPSR

@ we are leaving to user mode， we need to restore the values of USER mode r13（sp） and r14（lr）。

@ ldmia with ^ will return the user mode registers （provided that r15 is not in the register list）

LDMFD SP！， {R0-R12}

LDMFD SP， {R13， R14}^ @ Restore user mode R13/R14

ADD SP， SP， #（2 * 4）

LDMFD SP！， {PC}^ @ Return to user

这段代码的注释较为清楚，可以看到，内核模式会继续调用OsKernelSVCHandler，用户模式会继续调用OsArmA32SyscallHandle函数；

OsArmA32SyscallHandle函数

我们这里分析的流程是从用户模式进入的，所以调用的是OsArmA32SyscallHandle，它的实现位于kernel/liteos_a/syscall/los_syscall.c文件：

/* The SYSCALL ID is in R7 on entry. Parameters follow in R0..R6 */

LITE_OS_SEC_TEXT UINT32 *OsArmA32SyscallHandle（UINT32 *regs）

{

UINT32 ret;

UINT8 nArgs;

UINTPTR handle;

UINT32 cmd = regs［REG_R7］;

if （cmd 》= SYS_CALL_NUM） {

PRINT_ERR（“Syscall ID： error %d ！！！\n”， cmd）;

return regs;

}

if （cmd == __NR_sigreturn） {

OsRestorSignalContext（regs）;

return regs;

}

handle = g_syscallHandle［cmd］; // 得到实际系统调用处理函数

nArgs = g_syscallNArgs［cmd / NARG_PER_BYTE］; /* 4bit per nargs */

nArgs = （cmd & 1） ？ （nArgs 》》 NARG_BITS） ： （nArgs & NARG_MASK）;

if （（handle == 0） || （nArgs 》 ARG_NUM_7）） {

PRINT_ERR（“Unsupport syscall ID： %d nArgs： %d\n”， cmd， nArgs）;

regs［REG_R0］ = -ENOSYS;

return regs;

}

switch （nArgs） { // 以下各个case是实际函数调用

case ARG_NUM_0：

case ARG_NUM_1：

ret = （*（SyscallFun1）handle）（regs［REG_R0］）;

break;

case ARG_NUM_2：

case ARG_NUM_3：

ret = （*（SyscallFun3）handle）（regs［REG_R0］， regs［REG_R1］， regs［REG_R2］）;

break;

case ARG_NUM_4：

case ARG_NUM_5：

ret = （*（SyscallFun5）handle）（regs［REG_R0］， regs［REG_R1］， regs［REG_R2］， regs［REG_R3］，

regs［REG_R4］）;

break;

default：

ret = （*（SyscallFun7）handle）（regs［REG_R0］， regs［REG_R1］， regs［REG_R2］， regs［REG_R3］，

regs［REG_R4］， regs［REG_R5］， regs［REG_R6］）;

}

regs［REG_R0］ = ret; // 返回值填入R0

OsSaveSignalContext（regs）;

/* Return the last value of curent_regs. This supports context switches on return from the exception.

* That capability is only used with theSYS_context_switch system call.

*/

return regs;

}

这个函数中用到了个全局数组g_syscallHandle和g_syscallNArgs，它们的定义以及初始化函数也在同一个文件中：

static UINTPTR g_syscallHandle［SYS_CALL_NUM］ = {0};

static UINT8 g_syscallNArgs［（SYS_CALL_NUM + 1） / NARG_PER_BYTE］ = {0};

void SyscallHandleInit（void）

{

#define SYSCALL_HAND_DEF（id， fun， rType， nArg） \

if （（id） 《 SYS_CALL_NUM） { \

g_syscallHandle［（id）］ = （UINTPTR）（fun）; \

g_syscallNArgs［（id） / NARG_PER_BYTE］ |= \

（（id） & 1） ？ （nArg） 《《 NARG_BITS ： （nArg）; \

}

#include “syscall_lookup.h”

#undef SYSCALL_HAND_DEF

}

其中SYSCALL_HAND_DEF宏的对齐格式我做了一点调整。

从g_syscallNArgs成员赋值以及定义的地方，能看出它的每个UINT8成员被用来存放两个系统调用的参数个数，从而实现更少的内存占用；

syscall_lookup.h文件和los_syscall.c位于同一目录，它记录了系统调用函数对照表，我们仅节取一部分：

SYSCALL_HAND_DEF（__NR_read， SysRead， ssize_t， ARG_NUM_3）

SYSCALL_HAND_DEF（__NR_write， SysWrite， ssize_t， ARG_NUM_3） //

看到这里，write系统调用的内核函数终于找到了——SysWrite。

到此，我们已经知道了liteos-a的系统调用机制是如何实现的。

liteos-a内核SysWrite的实现

SysWrite函数的实现位于kernel/liteos_a/syscall/fs_syscall.c文件：

ssize_t SysWrite（int fd， const void *buf， size_t nbytes）

{

int ret;

if （nbytes == 0） {

return 0;

}

if （！LOS_IsUserAddressRange（（vaddr_t）（UINTPTR）buf， nbytes）） {

return -EFAULT;

}

/* Process fd convert to system global fd */

fd = GetAssociatedSystemFd（fd）;

ret = write（fd， buf， nbytes）; //

它又调用了write？但是这一次是内核空间的write，不再是 musl libc，经过一番搜索，我们可以找到另一个文件third_party/NuttX/fs/vfs/fs_write.c中的write：

ssize_t write（int fd， FAR const void *buf， size_t nbytes） {

#if CONFIG_NFILE_DESCRIPTORS 》 0

FAR struct file *filep;

if （（unsigned int）fd 》= CONFIG_NFILE_DESCRIPTORS）

#endif

{ /* Write to a socket descriptor is equivalent to send with flags == 0 */

#if defined（LOSCFG_NET_LWIP_SACK）

FAR const void *bufbak = buf;

ssize_t ret;

if （LOS_IsUserAddress（（VADDR_T）（uintptr_t）buf）） {

if （buf ！= NULL && nbytes 》 0） {

buf = malloc（nbytes）;

if （buf == NULL） { /* 省略 错误处理 代码 */ }

if （LOS_ArchCopyFromUser（（void*）buf， bufbak， nbytes） ！= 0） {/* 省略 */}

}

}

ret = send（fd， buf， nbytes， 0）; // 这个分支是处理socket fd的

if （buf ！= bufbak） {

free（（void*）buf）;

}

return ret;

#else

set_errno（EBADF）;

return VFS_ERROR;

#endif

}

#if CONFIG_NFILE_DESCRIPTORS 》 0

/* The descriptor is in the right range to be a file descriptor.。。 write

* to the file.

*/

if （fd 《= STDERR_FILENO && fd 》= STDIN_FILENO） { /* fd ： ［0，2］ */

fd = ConsoleUpdateFd（）;

if （fd 《 0） {

set_errno（EBADF）;

return VFS_ERROR;

}

}

int ret = fs_getfilep（fd， &filep）;

if （ret 《 0） {

/* The errno value has already been set */

return VFS_ERROR;

}

if （filep-》f_oflags & O_DIRECTORY） {

set_errno（EBADF）;

return VFS_ERROR;

}

if （filep-》f_oflags & O_APPEND） {

if （file_seek64（filep， 0， SEEK_END） == -1） {

return VFS_ERROR;

}

}

/* Perform the write operation using the file descriptor as an index */

return file_write（filep， buf， nbytes）;

#endif

}

找到这段代码，我们知道了：

liteos-a的vfs是在NuttX基础上实现的，NuttX是一个开源RTOS项目；

liteos-a的TCP/IP协议栈是基于lwip的，lwip也是一个开源项目；

这段代码中的write分为两个分支，socket fd调用lwip的send，另一个分支调用file_write；

至于，file_write如何调用到存储设备驱动程序，则是更底层的实现了，本文不在继续分析。

补充说明

本文内容均是基于鸿蒙系统开源项目OpenHarmony源码静态分析所整理，没有进行实际的运行环境调试，实际执行过程可能有所差异，希望发现错误的读者及时指正。文中所有路径均为整个openharmony源码树上的相对路径（而非liteos源码相对路径）。

责任编辑：YYX