为啥传统模式下的 syscall/sysret 被认为是“设计得很糟糕”？

Posted 2023-02-23

【中文标题】为啥传统模式下的 syscall/sysret 被认为是“设计得很糟糕”？

【英文标题】：Why syscall/sysret in legacy mode is considered "sufficiently poorly designed"?为什么传统模式下的 syscall/sysret 被认为是“设计得很糟糕”？

【发布时间】：2020-08-25 14:32:31

【问题描述】：

见https://github.com/torvalds/linux/blob/master/arch/x86/entry/entry_64_compat.S中的cmets

我了解由于 32 位系统调用/系统调用不保存/恢复 ESP，因此有必要在任务门中处理 NMI 以确保良好的堆栈指针。除此之外，操作系统采用它的其他障碍是什么？是否有操作系统支持它或所有操作系统都使用 sysenter/sysexit 在 32 位传统模式下进行快速系统调用？

【参考方案1】：

注意：我从未处理过旧版 syscall 是仅 AMD 指令。

旧版syscall 的主要问题是它需要某种形式的 per-cpu 空间来保存当前寄存器。 如您所知，操作系统无法将寄存器保存在堆栈中（因为ESP 不会被指令更改），也无法在保存当前堆栈之前设置不同的堆栈。

在单 CPU 系统（即单处理器系统，即无 SMP 有或没有超线程）中，操作系统可以将当前寄存器保存在内存中已知的固定位置。mov DWORD [0badf00dh], esp 之类的指令将地址编码为立即数，因此无需预先设置架构寄存器。 但是，这在 SMP 系统上不起作用，在这些系统中，所有 CPU 共享相同的代码，除非操作系统为所有 CPU 使用相同的内存区域（序列化对其的访问）。 请注意，您不能加载 per-cpu 指针，因为这必然会覆盖某些寄存器。

另一个重要的一点是旧版syscall 不会保存eflags，这使得编写它的处理程序就像在蛋壳上行走一样。 此外，该指令还将VM 和IF 任意设置为零，使得编写可重入代码变得更加困难。

一种解决方法是使用调用约定：操作系统可以在调用过程中将一个寄存器（或几个）标记为易失性（例如 ecx 已经是）。 问题是您最终可能会节省比您想象的更多的寄存器，从而使性能增益变薄。 另一个令人难以置信的解决方法可能是在运行时为每个 CPU 组装 syscall 的入口点（基本上，只是修补 moffsets 字段），但这非常hacky。

在 64 位模式下，操作系统可以依靠 swapgs 拥有一个 per-cpu 指针（或更准确地说，是一个 per-cpu 基地址）来存储当前寄存器。 由于swapgs 从 MSR 加载，因此可以在操作系统初始化期间提前设置。

请注意，在 64 位系统上，操作系统也可以使用上层 GPR，就像 Linux 一样，将esp 保存到例如r8d。 这在处理 32 位兼容模式程序时有效。

长话短说：旧版syscall 让操作系统很难将当前上下文保存在每个 CPU 的内存区域中。

【讨论】：

谢谢玛格丽特！非常全面的答案。还有一个问题：eflags 问题是否也适用于sysenter？

@Zuxy 如果堆栈是健全的，你可以简单地做一个pushf(d) 来解决这个问题:)