在C程序中复制执行syscall源码会触发哪种操作系统安全机制

• 99%的场景下你连编译都过不了。内核中的系统调用实现是纯内核态代码，依赖大量仅内核编译环境才有的私有头文件、预定义宏、未导出的内核全局函数和数据结构，还大量使用内核态专属的固定偏移内存地址，普通用户态C程序用gcc等编译器编译时，会直接报头文件缺失、符号未定义、非法地址常量等错误，根本生成不了可执行文件。
• 如果你强行把所有内核专属依赖都删掉，裁剪出一段能在用户态编译通过的等价逻辑代码，那这段代码本质就是个普通的用户态自定义函数，不会触发特权级切换，只能访问当前进程用户态地址空间内的内存，根本碰不到内核管理的硬件、内核态内存等核心资源，完全达不到真正系统调用的效果。
• 如果你抠的不是内核里的系统调用实现，而是跳过标准库封装、直接把触发系统调用的底层汇编指令（比如x86_64下的syscall指令、32位下的int 0x80软中断指令）嵌到C代码里，又没有按照系统调用约定填对对应的系统调用号、参数寄存器，运行时会直接触发段错误，进程被操作系统强制杀死。

• 最底层的拦截逻辑是CPU硬件特权级（Ring）隔离：通用CPU架构（x86、ARM等）都设计了分层特权运行机制，以x86为例共分为4个特权环，操作系统内核运行在最高特权级Ring 0，拥有执行所有CPU指令、访问全部内存、直接操作所有外设的权限；普通用户态程序运行在最低特权级Ring 3，所有特权操作指令（包括修改页表、开关中断、操作外设IO端口、修改特权控制寄存器等）在Ring 3下执行时，会直接被CPU抛出硬件异常，操作系统捕获异常后会直接终止违规进程。
• 配套的保护是虚拟内存页表权限隔离：操作系统为每个用户态进程维护独立的虚拟地址页表，内核占用的高地址段在用户态页表中被统一标记为不可读、不可写、不可执行，用户态代码哪怕硬编码了内核态的内存地址，一旦尝试访问就会触发页错误，被系统直接终止。
• 现代操作系统还额外开启了SMEP（管理模式执行保护）、SMAP（管理模式访问保护）等加固机制，进一步阻断用户态和内核态之间的非法代码执行、内存访问路径，就算存在部分特权检查漏洞，也能拦住大部分直接跳转执行内核代码、篡改内核数据的尝试。

内容的提问来源于stack exchange，提问作者Bender