在 Linux 系统调用中，系统调用完成后（在 sys_exit 跟踪点处），系统调用参数是否保存在寄存器中？

Question

是否保证能够读取sys_exittracepoint处的所有系统调用参数？

sysdig driver 是一个使用内核静态跟踪点捕获系统调用的内核模块。在这个项目中，一些系统调用参数在sys_entertracepoint 处读取，其他一些参数在sys_exit 处读取（当然是返回值，以及用户空间中的内容以避免页面错误）。

为什么不读取sys_exit 的所有参数？是不是因为sys_exit有些参数可能不可用？

Answer 1

是否保证能够读取sys_exittracepoint处的所有系统调用参数？

是的...不，我们需要将参数与寄存器区分开来。 Linux 系统调用应该保留所有通用用户空间寄存器，除了用于返回值的寄存器（在某些架构上还有第二个寄存器来指示是否发生错误）。然而，这并不意味着系统调用的输入参数不能在进入和退出之间改变：如果一个寄存器保存了指向某些数据的指针的值，而寄存器本身没有改变，则数据它指出可能会发生很大的变化。

查看静态跟踪点sys_exit 的the code，您可以看到仅跟踪系统调用号（id）及其返回值（ret）。有关更多信息，请参阅我的答案底部的注释。

为什么不读取sys_exit 的所有参数？是不是因为sys_exit有些参数可能不可用？

是的，我会说确保跟踪参数的正确性是为什么只在出口处跟踪是一个坏主意的主要原因。即使你得到了寄存器的值，你也无法知道系统调用退出时的真实参数。即使系统调用本身保证保存和恢复用户寄存器的状态，系统调用本身也可以改变作为参数传递的数据。例如，recvmsg 系统调用将指针指向内存中的struct msghdr，该指针既用作输入参数，也用作输出参数； poll 系统调用对指向struct pollfd 的指针执行相同的操作。此外，另一个线程或程序可能在进行系统调用时很好地修改了程序的内存，从而改变了数据。

在特定情况下，系统调用也可能需要很长时间才能返回（例如，考虑sleep，或终端上的阻塞read，侦听套接字上的accept，等等）。如果仅在出口处进行跟踪，您将获得非常不正确的时间信息，最重要的是，您必须等待很长时间才能捕获任何有意义的信息，即使该信息已经在入口点可用。

---

注意sys_exittracepoint

尽管您可以从计算机上提取当前任务的已保存寄存器的值，但我并不完全确定在 sys_exit 跟踪点中这样做的语义。我搜索了一些关于这个特定案例的文档，但没有运气，内核代码很好......很复杂。

到达退出钩子的调用链应该是：

• Arch 特定入口点（例如，entry_INT80_32 for x86 int 0x80）
  • Arch 特定入口处理程序（例如，do_int80_syscall_32() for x86 int 0x80）
    • syscall_exit_to_user_code()
      • syscall_exit_to_user_mode_prepare()
        • syscall_exit_work()
          • trace_sys_exit()

如果在系统调用期间向进程传递了致命信号，而实际进程永远不会到达系统调用的出口（即没有任何值返回到用户空间），跟踪点仍然会被命中。当发生这种类型的信号传递时，会使用一个特殊的内部返回值，例如-ERESTARTSYS (see here)。这个值不是一个实际的系统调用返回值（它不返回到用户空间），而是只打算被内核使用。因此，如果进程接收到致命信号，则看起来sys_exit 跟踪点正在被特殊的-ERESTARTSYS 命中。例如在SIGSTOP + SIGCONT 的情况下不会发生这种情况。不过，对此持保留态度，因为我找不到合适的文档。