Linux系统调用是否在异常处理程序中执行? [英] Are Linux system calls executed inside an exception handler?

问题描述

我了解到在输入系统调用后，例如syscall，int 0x80(x86/x86-64)或svc(ARM)指令，从Linux内核的角度来看，我们停留在调用进程上下文中(但从用户模式切换到内核模式).但是，从硬件角度来看，我们跳入syscall/svc/...异常处理程序.整个系统调用代码是否在Linux的异常处理程序中执行?

I understand that after entering a system call with e.g. syscall, int 0x80 (x86/x86-64) or svc (ARM) instruction, we stay in the calling process context (but switch from user to kernel mode) from Linux kernel point of view. However, from hardware point of view, we jump into a syscall/svc/... exception handler. Is the whole system call code executed inside the exception handler in Linux?

推荐答案

使用80x86常用的术语(来自Intel手册等)；CPU具有当前特权级别".(CPL)确定代码是否受到限制(例如，是否允许特权指令)，并且这是用户空间与内核空间"的基础.触发从CPL = 3(用户空间")到CPL = 0(内核空间")的切换的事物是:

Using the terminology that's common for 80x86 (from Intel's manuals, etc); the CPU has a "current privilege level" (CPL) that determines if code is restricted or not (e.g. if privileged instructions are permitted or not), and this is the basis of "user-space vs. kernel space". The things that trigger a switch from CPL=3 ("user space") to CPL=0 ("kernel space") are:

• 异常，通常表示CPU检测到了问题(例如，被零除)

• exceptions, which typically indicate that a problem (e.g. division by zero) was detected by the CPU

IRQ，表明设备需要注意

IRQs, which indicate that a device needs attention

软件中断，调用门以及 syscall 和 sysenter 指令.这些都是软件以不同的方式明确要求OS/内核提供某些内容(内核系统调用)，其中不同的操作系统/内核可能仅支持某些或其中一种(64位代码只需要 syscall ，除非操作系统/内核试图为过时的32位内容提供向后兼容性，否则其他所有替代方案都可能不受操作系统/内核的支持.

software interrupts, call gates, and the syscall and sysenter instructions. These are all different ways for software to explicitly ask the OS/kernel for something (kernel system calls) where different operating systems/kernels may only support some or one of them (64-bit code will only need syscall and all the other alternatives probably won't be supported by the OS/kernel unless it's trying to provide backward compatibility for obsolete 32-bit stuff).

任务门(已过时，不支持64位，并且不为任何知名的32位OS使用.)

Task gates (obsolete, not supported for 64-bit and not used by any well known 32-bit OS).

使用此术语；说Linux系统调用是在异常处理程序中执行的，这是错误的(因为异常是不涉及的特定事物).

Using this terminology; it'd be wrong to say that Linux system calls are executed in an exception handler (because an exception is something specific that isn't involved).

但是...

不同的人对术语的定义不同；一些人(ARM)定义了例外"作为导致切换到内核空间的任何事物"的同义词.对于主要关注于切换到超级用户模式对CPU的影响且几乎没有理由关心差异的CPU设计人员来说，这是有意义的(因为差异主要是软件开发人员的问题).对于使用该术语的其他所有人(软件开发人员)，您可以说内核中的所有内容都在异常处理程序中使用；这通常使例外"一词成为毫无意义(因为可能什么也没有"不提供任何其他信息).换句话说，使用该术语，"Linux系统调用在异常处理程序内执行".在技​​术上是正确的，但可以简化为执行Linux系统调用".而不更改语句的含义.

Different people define terminology differently; and some people (ARM) define "exception" as a synonym for "anything that causes a switch to kernel space". This makes some sense for CPU designers who are primarily focused on the impact on the CPU that any switch to supervisor mode has and have little reason to care about the differences (because the differences are mostly a software developer's problem). For everyone else (software developers) by using that terminology you could say that everything in the kernel is used inside an exception handler; which mostly makes the word "exception" meaningless (because "could be anything at all" doesn't provide any additional information). In other words, using that terminology, "Linux system calls are executed inside an exception handler" is technically correct but could be shortened to "Linux system calls are executed" without changing the statement's meaning.

注意:最近，英特尔发布了一项有关未来可能扩展的提案草案，该提案将(如果由CPU采用并支持并由OS启用)以新的事件"代替上述所有内容.方案;其中许多不同/分开的(异常，IRQ，系统调用...)处理程序被单个事件处理程序"所代替.(这将必须获取CPU提供的事件原因"，然后分支到事件原因特定的"代码).如果发生这种情况，我希望使用第三组术语(例如，``异常事件''，``IRQ事件''和``系统调用事件'')，其中所有内核代码都是在某种事件的上下文中执行的;以及其中在事件处理程序中执行Linux系统调用"在技术上是正确的，但可以缩短为执行Linux系统调用".

Note: Recently Intel published a draft proposal for a possible future extension that would (if adopted and supported by CPU and enabled by the OS) replace all of the above with a new "events" scheme; where many different/separate (exception, IRQ, system calls, ...) handlers are replaced by a single "event handler" (which would have to fetch an "event reason" provided by CPU and then branch to "event reason specific" code). If that happens I'd expect a third set of terminology (e.g. "exception event" and "IRQ event" and "system call event", where all of kernel's code is executed in the context of some kind of event; and where "Linux system calls are executed inside an event handler" would be technically correct but could be shortened to "Linux system calls are executed").

这篇关于Linux系统调用是否在异常处理程序中执行?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！