百度360必应搜狗淘宝本站头条
当前位置:网站首页 > IT知识 > 正文

「内核知识」Linux下的系统调用write

liuian 2025-04-29 02:07 14 浏览

本文以x86_64平台为例,分析linux下的系统调用是如何被执行的。

假设目标系统调用是,其对应的内核源码为:

// fs/read_write.c
SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf,
                size_t, count)
{
        return ksys_write(fd, buf, count);
}

这里主要看下SYSCALL_DEFINE3这个宏定义:

// 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_DEFINEx(x, sname, ...)                          \
        ...
        __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)

该宏又引用了__SYSCALL_DEFINEx,继续看下:

// arch/x86/include/asm/syscall_wrapper.h
#define __SYSCALL_DEFINEx(x, name, ...)                                 \
        asmlinkage long __x64_sys##name(const struct pt_regs *regs);    \
        ...                                                             \
        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 __x64_sys##name(const struct pt_regs *regs)     \
        {                                                               \
                return __se_sys##name(SC_X86_64_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__));\
                ...                                                     \
                return ret;                                             \
        }                                                               \
        static inline long __do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))

该宏的参数中,x为3,name为_write,...代表的__VA_ARGS__为unsigned int, fd, const char __user *, buf, size_t, count。

接着,在宏的定义中,先声明了三个函数,分别为__x64_sys_write、_se_sys_write、__do_sys_write,紧接着,定义了__x64_sys_write和_se_sys_write的实现,__x64_sys_write内调用_se_sys_write,_se_sys_write内调用__do_sys_write。

__do_sys_write只是一个方法头,它和最开始的write系统调用的方法体构成完整的方法。

由上可以看到,三个方法中,只有__x64_sys_write方法没有static,即只有它是外部可调用的,所以我们看下哪里引用了__x64_sys_write。

// arch/x86/entry/syscalls/syscall_64.tbl
#
# 64-bit system call numbers and entry vectors
#
# The format is:
# <number> <abi> <name> <entry point>
#
# The __x64_sys_*() stubs are created on-the-fly for sys_*() system calls
#
# The abi is "common", "64" or "x32" for this file.
#
0       common  read                    __x64_sys_read
1       common  write                   __x64_sys_write
...

我们会在一个非c文件中,找到了对__x64_sys_write方法的引用,但这个文件又是怎么被使用的呢?

根据
arch/x86/entry/syscalls/Makefile我们可以知道,是有对应的shell脚本,根据上面的文件来生成c版的头文件,比如下面两个。

kernel内部使用的:

// arch/x86/include/generated/asm/syscalls_64.h
#ifdef CONFIG_X86
__SYSCALL_64(0, __x64_sys_read, )
#else /* CONFIG_UML */
__SYSCALL_64(0, sys_read, )
#endif
#ifdef CONFIG_X86
__SYSCALL_64(1, __x64_sys_write, )
#else /* CONFIG_UML */
__SYSCALL_64(1, sys_write, )
#endif
...

给用户使用的:

// arch/x86/include/generated/uapi/asm/unistd_64.h
#define __NR_read 0
#define __NR_write 1
...

那生成的这两个头文件又是给谁使用的呢?看下下面这个文件:

// arch/x86/entry/syscall_64.c
#define __SYSCALL_64(nr, sym, qual) [nr] = sym,

asmlinkage const sys_call_ptr_t sys_call_table[__NR_syscall_max+1] = {
        /*
         * Smells like a compiler bug -- it doesn't work
         * when the & below is removed.
         */
        [0 ... __NR_syscall_max] = &sys_ni_syscall,
#include <asm/syscalls_64.h>
};

该文件中定义了一个const的数组变量sys_call_table,数组下标为系统调用的编号,值为该编号对应的系统调用方法。

最开始整个数组都初始化为sys_ni_syscall,该方法内会返回错误码ENOSYS,表示对应的方法未实现。

接着用#include <asm/syscalls_64.h>的方式再初始化存在的系统调用。

该include的文件就是上面生成的
arch/x86/include/generated/asm/syscalls_64.h,syscalls_64.h文件里调用__SYSCALL_64,为对应的系统下标赋值。

最后,sys_call_table[1] = __x64_sys_write。

到这里,我们基本可以猜测,肯定有个地方是根据系统调用的编号,到数组sys_call_table中找到对应方法,然后调用。

让我们来看下这段代码在哪里

// arch/x86/entry/common.c
__visible void do_syscall_64(unsigned long nr, struct pt_regs *regs)
{
        ...
        if (likely(nr < NR_syscalls)) {
                nr = array_index_nospec(nr, NR_syscalls);
                regs->ax = sys_call_table[nr](regs);
        }
        ...
}

上面的方法就是我们要找的方法。

我们再看下这个方法是在哪里被调用的。

// arch/x86/entry/entry_64.S
ENTRY(entry_SYSCALL_64)
        ...
        call    do_syscall_64           /* returns with IRQs disabled */
        ...

上面的就是对应的汇编代码了,这里为了简单,省略掉了该汇编方法的其他部分。

那这段汇编代码又是在哪里调用的呢?

// arch/x86/kernel/cpu/common.c
void syscall_init(void)
{
        ...
        wrmsrl(MSR_LSTAR, (unsigned long)entry_SYSCALL_64);
        ...
}

在上面的方法中,我们可以看到,汇编代码entry_SYSCALL_64被写到了MSR_LSTAR表示的寄存器中。

该寄存器的作用就是,当我们执行syscall机器指令时,MSR_LSTAR寄存器中存放的对应方法就会被执行,即在user space,我们只要执行syscall机器指令,给它对应的系统调用编号和参数,kernel space里对应的系统调用就会被执行了。

有兴趣的可以分析并执行下下面的汇编代码,好好体会下整个系统调用的流程。

# ----------------------------------------------------------------------------------------
# Writes "Hello, World" to the console using only system calls. Runs on 64-bit Linux only.
# To assemble and run:
#
#     gcc -c hello.s && ld hello.o && ./a.out
#
# or
#
#     gcc -nostdlib hello.s && ./a.out
# ----------------------------------------------------------------------------------------

        .global _start

        .text
_start:
        # write(1, message, 13)
        mov     $1, %rax                # system call 1 is write
        mov     $1, %rdi                # file handle 1 is stdout
        mov     $message, %rsi          # address of string to output
        mov     $13, %rdx               # number of bytes
        syscall                         # invoke operating system to do the write

        # exit(0)
        mov     $60, %rax               # system call 60 is exit
        xor     %rdi, %rdi              # we want return code 0
        syscall                         # invoke operating system to exit
message:
        .ascii  "Hello, world\n"

到这里,系统调用对应的kernel space部分就已经分析完毕了,下篇文章我们结合对应的c源码,看下user space的部分是如何实现的。

简而言之就是通过一定的约定来实现指定系统调用编号和传递参数及返回值。

比如x86_64平台,在执行syscall机器码之前,系统调用的编号要先放到rax寄存器,参数要分别放到rdi、rsi、rdx、r10、r8、r9寄存器中,这样kernel中的代码就会从这些地方取值,然后继续执行逻辑,当kernel部分的逻辑完成之后,结果会再放到rax寄存器中,这样user space的部分就可以从rax寄存器中拿到返回值。

下面我们再来看下上篇文章最后的例子:

# ----------------------------------------------------------------------------------------
# Writes "Hello, World" to the console using only system calls. Runs on 64-bit Linux only.
# To assemble and run:
#
#     gcc -c hello.s && ld hello.o && ./a.out
#
# or
#
#     gcc -nostdlib hello.s && ./a.out
# ----------------------------------------------------------------------------------------

        .global _start

        .text
_start:
        # write(1, message, 13)
        mov     $1, %rax                # system call 1 is write
        mov     $1, %rdi                # file handle 1 is stdout
        mov     $message, %rsi          # address of string to output
        mov     $13, %rdx               # number of bytes
        syscall                         # invoke operating system to do the write

        # exit(0)
        mov     $60, %rax               # system call 60 is exit
        xor     %rdi, %rdi              # we want return code 0
        syscall                         # invoke operating system to exit
message:
        .ascii  "Hello, world\n"

现在就非常明白了吧,比如第一个write系统调用,因为其编号为1,所以先将1放到rax里,之后将标准输出文件描述符到到rdi里,再之后将message地址放到rsi里,再之后将message的长度13放到rdx里,最后调用syscall机器码,这样就会转到对应kernel space部分的代码。

从汇编角度我们已经讲明白了,那在c语言中我们又是如何调用呢?总不能在c中嵌入汇编代码吧?

其实本质上就是在c中嵌入汇编代码,只是不是我们来做,而是glibc来帮我做。

再来看个例子:

#include <unistd.h>

int main(int argc, char *argv[]) {
  write(STDOUT_FILENO, "Hello, World\n", 13);
  return 60;
}

这个例子就是上面汇编代码对应的c实现,编译执行之后也是会输出同样的内容。

注意,这里的write并不是kernel内部的系统调用write,而是glibc中的一个wrapper,这个wrapper里面再帮我们调用真正的系统调用write。

我们再来看下对应的glibc的代码:

// sysdeps/unix/sysv/linux/write.c
/* Write NBYTES of BUF to FD.  Return the number written, or -1.  */
ssize_t
__libc_write (int fd, const void *buf, size_t nbytes)
{
  return SYSCALL_CANCEL (write, fd, buf, nbytes);
}
...
weak_alias (__libc_write, write)
...

这里需要注意的是,write方法其实是__lib_write的一个weak alias,当我们调用write时,其实相当于我们在调用__lib_write。

继续看下SYSCALL_CANCEL宏:

// sysdeps/unix/sysdep.h
#define SYSCALL_CANCEL(...) \
  ({                                                                         \
    long int sc_ret;                                                         \
    if (SINGLE_THREAD_P)                                                     \
      sc_ret = INLINE_SYSCALL_CALL (__VA_ARGS__);                            \
    else                                                                     \
      {
        ...                                                                  \
      }                                                                      \
    sc_ret;                                                                  \
  })

这个宏里面又调用了INLINE_SYSCALL_CALL,INLINE_SYSCALL_CALL里又调用了很多其他的宏,这里就不一一展开了,有兴趣的朋友可以留言,我们再一起交流。

最终,会调用下面的宏。

// sysdeps/unix/sysv/linux/x86_64/sysdep.h
#define internal_syscall3(number, err, arg1, arg2, arg3)                \
({                                                                      \
    unsigned long int resultvar;                                        \
    TYPEFY (arg3, __arg3) = ARGIFY (arg3);                              \
    TYPEFY (arg2, __arg2) = ARGIFY (arg2);                              \
    TYPEFY (arg1, __arg1) = ARGIFY (arg1);                              \
    register TYPEFY (arg3, _a3) asm ("rdx") = __arg3;                   \
    register TYPEFY (arg2, _a2) asm ("rsi") = __arg2;                   \
    register TYPEFY (arg1, _a1) asm ("rdi") = __arg1;                   \
    asm volatile (                                                      \
    "syscall\n\t"                                                       \
    : "=a" (resultvar)                                                  \
    : "0" (number), "r" (_a1), "r" (_a2), "r" (_a3)                     \
    : "memory", REGISTERS_CLOBBERED_BY_SYSCALL);                        \
    (long int) resultvar;                                               \
})

是不是很熟悉,这就是我们上面手写的汇编代码啊。

到此,整个流程就全部通了。

我们在写c时(其他语言也一样),调用的其实是glibc里的wrapper,glibc里的wrapper再帮我们调用对应的系统调用,之后再将结果从rax中取出,返回给我们,这样我们使用起来就非常方便了。

- - 内核技术中文网 - 构建全国最权威的内核技术交流分享论坛

「内核知识」Linux下的系统调用write - 论坛 - 内核技术中文网 - 构建全国最权威的内核技术交流分享论坛

相关推荐

MySQL合集-mysql5.7及mysql8的一些特性

1、Json支持及虚拟列1.1jsonJson在5.7.8原生支持,在8.0引入了json字段的部分更新(jsonpartialupdate)以及两个聚合函数,JSON_OBJECTAGG,JS...

MySQL 双表架构在房产中介房源管理中的深度实践

MySQL房源与价格双表封神:降价提醒实时推送客户房产中介实战:MySQL空间函数精准定位学区房MySQL狠招:JSON字段实现房源标签自由组合筛选房源信息与价格变更联动:MySQL黄金搭档解决客户看...

MySQL 5.7 JSON 数据类型使用总结

从MySQL5.7.8开始,MySQL支持原生的JSON数据类型。MySQL支持RFC7159定义的全部json数据类型,具体的包含四种基本类型(strings,numbers,boolea...

MySQL 8.0 SQL优化黑科技,面试官都不一定知道!

前言提到SQL优化,大多数人想到的还是那些经典套路:建索引、避免全表扫描、优化JOIN顺序…这些确实是基础,但如果你还停留在MySQL5.7时代的优化思维,那就out了。MySQL8.0已经发布好...

如何在 MySQL 中使用 JSON 数据(mysql的json函数与实例)

在MySQL中学习“NoSQL”MySQL从5.7版本开始就支持JSON格式的数据类型,该数据类型支持JSON文档的自动验证和优化存储和访问。尽管JSON数据最好存储在MongoDB等...

MySQL中JSON的存储原理(mysql中json字段操作)

前言:表中有json字段后,非索引查询性能变得非常糟糕起因是我有一张表,里面有json字段后,而当mysql表中有200w数据的时候,走非索引查询性能变得非常糟糕需要3到5s。因此对mysql的jso...

mysql 之json字段详解(多层复杂检索)

MySQL5.7.8开始支持JSON数据类型。MySQL8.0版本中增加了对JSON类型的索引支持。示例表CREATETABLE`users`(`id`intNOTNULLAU...

VMware vCenter Server 8.0U3b 发布下载,新增功能概览

VMwarevCenterServer8.0U3b发布下载,新增功能概览ServerManagementSoftware|vCenter请访问原文链接:https://sysin.or...

Spring Boot 3.x 新特性详解:从基础到高级实战

1.SpringBoot3.x简介与核心特性1.1SpringBoot3.x新特性概览SpringBoot3.x是建立在SpringFramework6.0基础上的重大版...

如何设计Agent的记忆系统(agent记忆方法)

最近看了一张画Agent记忆分类的图我觉得分类分的还可以,但是太浅了,于是就着它的逻辑,仔细得写了一下在不同的记忆层,该如何设计和选型先从流程,作用,实力和持续时间的这4个维度来解释一下这几种记忆:1...

Spring Boot整合MyBatis全面指南:从基础到高级应用(全网最全)

一、基础概念与配置1.1SpringBoot与MyBatis简介技术描述优点SpringBoot简化Spring应用开发的框架,提供自动配置、快速启动等特性快速开发、内嵌服务器、自动配置、无需X...

5大主流方案对比:MySQL千亿级数据线上平滑扩容实战

一、扩容方案剖析1、扩容问题在项目初期,我们部署了三个数据库A、B、C,此时数据库的规模可以满足我们的业务需求。为了将数据做到平均分配,我们在Service服务层使用uid%3进行取模分片,从而将数据...

PostgreSQL 技术内幕(五)Greenplum-Interconnect模块

Greenplum是在开源PostgreSQL的基础上,采用MPP架构的关系型分布式数据库。Greenplum被业界认为是最快最具性价比的数据库,具有强大的大规模数据分析任务处理能力。Greenplu...

在实际操作过程中如何避免出现SQL注入漏洞

一前言本文将针对开发过程中依旧经常出现的SQL编码缺陷,讲解其背后原理及形成原因。并以几个常见漏洞存在形式,提醒技术同学注意相关问题。最后会根据原理,提供解决或缓解方案。二SQL注入漏洞的原理、形...

运维从头到尾安装日志服务器,看这一篇就够了

一、rsyslog部署1.1)rsyslog介绍Linux的日志记录了用户在系统上一切操作,看日志去分析系统的状态是运维人员必须掌握的基本功。rsyslog日志服务器的优势:1、日志统一,集中式管理...