关于BSD与Linux专属必用系统调用及ELF中位置固定性的问询

问题背景 #

我正在做一个ELF格式可执行文件的操作系统检测项目，试过两种方法都不太靠谱：

• e_ident[EI_OSABI]值不可靠：Linux和OpenBSD的可执行文件常被识别为SysV，且该值会随编译器变化。
• PT_INTERP段不适用：无法覆盖共享库（.so），且部分链接器名称不含内核标识（比如/lib/ld-musl-x86_64.so.1）。

想换第三种思路：找仅某一内核独有、且所有对应OS的可执行文件/共享库都会调用的系统调用，通过检测这类syscall来识别操作系统。

问题解答 #

1. BSD系列与Linux是否存在此类系统调用？ #

存在。每个OS的C标准库在进程启动或运行时，都会依赖一些独有的系统调用来完成基础环境初始化，这类syscall几乎会出现在所有正常编译的ELF二进制（包括动态/静态链接的可执行文件、共享库）中：

• Linux：
  • set_tid_address（x86_64架构下syscall编号218）：glibc/musl等Linux libc在初始化线程环境时一定会调用，用于设置线程ID的存储地址，是Linux独有的syscall，BSD系列无对应实现。
  • prctl（x86_64编号157）：Linux独有的进程控制syscall，多数程序启动时会用它设置进程名、控制线程属性等。
• FreeBSD：
  • thr_self（x86_64编号437）：FreeBSD libc用于获取当前线程ID的独有syscall，Linux和OpenBSD均无此syscall。
• OpenBSD：
  • getthrid（x86_64编号263）：OpenBSD独有的线程ID获取syscall，其他OS无对应实现。

注：极端极简的静态链接程序（比如仅输出Hello World的极小二进制）可能会省略部分调用，但绝大多数生产环境的二进制都会包含上述syscall。

2. 它们在可执行文件中的位置是否固定？ #

位置不固定：

• 系统调用会以机器指令（比如x86_64的syscall指令）的形式，存储在ELF的可执行代码段中，常见的是.text段，少数可能在.init（初始化段）或.fini（终止段）中。
• 具体的偏移地址会因编译器版本、编译选项（比如优化等级）、libc版本不同而变化，没有固定的位置。你需要扫描ELF的所有可执行段，查找对应的syscall编号或指令序列来检测。

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