在阅读OSTEP这本书时,我有一个疑问。
摘自本书:
为了指定确切的系统调用,通常会为每个系统调用分配一个系统调用号。因此,用户代码负责将所需的系统调用号放在寄存器中或堆栈上的指定位置;操作系统在陷阱处理程序中处理系统调用时,会检查此号码,确保其有效,如果有效,则执行相应的代码。这种间接级别是一种保护形式;用户代码无法指定要跳转到的确切地址,而必须通过号码请求特定服务。
我试图更好地理解系统调用号在系统调用和陷阱处理上下文中的工作方式。以下是我目前所理解的内容:
- 系统调用号的作用类似于陷阱表中的键或索引,允许 CPU 跳转到正确的陷阱处理程序。
- 在陷阱处理程序内部,操作系统验证系统调用号。
- C 库的系统调用 API 在调用陷阱之前将系统调用号存储在寄存器或堆栈中。
我的理解准确吗?有人可以澄清或提供其他详细信息吗,尤其是关于 C 库的作用和验证步骤?
有关大多数详细信息,请参阅@MikeNakis 的回答。我只想回应这一点:
这有点令人担忧。也许这只是措辞不当,但如果这里确实存在误解,那么:
您的书中描述的系统调用设计与任何用户空间库都没有直接关系。原则上,任何用户空间程序都可以通过引用中描述的机制的适当操作系统特定版本来请求系统调用,而无需借助库函数。
但是,如果您的系统提供托管的 C 实现,那么它提供的 C 标准库中的许多函数确实会执行所描述的系统调用。此外,您可能特别想到某些系统的 C 实现作为扩展提供的系统调用包装函数。这些函数除了为特定系统调用提供方便的接口外,几乎没有其他作用。此外,某些系统的 C 标准库提供了一个通用的系统调用包装函数,要求调用者指定系统调用编号并以原始系统调用所需的形式提供适当的参数。除了最后一个之外,我认为所有这些都不能很好地描述为“系统调用 API”。
不。
在支持指令的 CPU 架构中可以找到“陷阱表”,
TRAP N
其中N
是陷阱编号。在此类架构中,陷阱表将陷阱编号映射到陷阱处理程序的地址。操作系统通常定义一个陷阱编号来提供系统调用。假设我们有一个支持多个陷阱处理程序的假想 CPU,以及一个用于系统调用的操作系统
TRAP 42
。系统调用号是调用操作系统陷阱之前必须设置的。例如:
因此,CPU 使用它
42
在陷阱表中查找陷阱处理程序,并跳转到该处理程序。这将是操作系统陷阱处理程序。在该处理程序中,操作系统使用的值在另一个R1
表(称为“系统调用”表)中查找系统函数的地址,并跳转到该地址。请注意,如果 CPU 支持使用无参数指令来调用操作系统,则该过程非常相似:
在这种情况下,只有一个处理程序,没有陷阱表。但是,仍然可以进行许多不同的系统调用,因此可以通过系统调用表解析系统调用号的机制仍然存在。
嗯,当然。如果系统调用号与实际有效的系统函数不对应,操作系统可能会对您的进程造成不良影响。
我不知道您说的“C 库的系统调用 API”是什么意思。无论如何,任何有兴趣调用系统调用的人都必须在调用操作系统之前将系统调用号存储在某个地方。操作系统定义了应该将数字存储在何处。它通常在寄存器中。