linux - 为什么linux内核使用陷阱门来处理divide_error异常？

Question

在内核 2.6.11.5 中，除零异常处理程序设置为:

set_trap_gate(0,&divide_error);

根据“了解 Linux 内核”，用户模式进程无法访问英特尔陷阱门。但是很有可能用户模式进程也会生成 divide_error .那么为什么 Linux 以这种方式实现呢？

[编辑]
我认为问题仍然存在，因为 set_trap_gate()将 IDT 条目的 DPL 值设置为 0，这意味着只有 CPL=0(读取内核)代码可以执行它，因此我不清楚如何从用户模式调用此处理程序:

#include<stdio.h>

int main(void)
{
    int a = 0;
    int b = 1;

    b = b/a;

    return b;
}

这是用 gcc div0.c 编译的.以及 ./a.out 的输出是:

Floating point exception (core dumped)

所以看起来这不是由 0 陷阱代码除法处理的。

Answer 1

我手头有 Linux 内核 3.7.1 源代码，因此我将尝试根据这些源代码为您的问题提供答案。我们在代码中有什么。在 arch\x86\kernel\traps.c我们有函数 early_trap_init()可以找到下一行代码:

set_intr_gate(X86_TRAP_DE, &divide_error);

正如我们所看到的 set_trap_gate()被 set_intr_gate() 取代.如果在下一回合我们扩展此调用，我们将实现:

_set_gate(X86_TRAP_DE, GATE_INTERRUPT, &divide_error, 0, 0, __KERNEL_CS);

_set_gate是一个例程，负责两件事:

构建IDT描述符

将构造的描述符安装到目标单元格中
IDT 描述符数组。第二个只是内存复制和
对我们来说并不有趣。但是如果我们看看它是如何构建的
我们将看到提供的参数的描述符:

struct desc_struct{
    unsigned int a;
    unsigned int b;
};

desc_struct gate;

gate->a = (__KERNEL_CS << 16) | (&divide_error & 0xffff);
gate->b = (&divide_error & 0xffff0000) | (((0x80 | GATE_INTERRUPT | (0 << 5)) & 0xff) << 8); 

或者最后

gate->a = (__KERNEL_CS << 16) | (&divide_error & 0xffff);
gate->b = (&divide_error & 0xffff0000) | (((0x80 | 0xE | (0 << 5)) & 0xff) << 8);

正如我们在描述符构造的末尾所看到的，我们将在内存中拥有下一个 8 字节的数据结构

[0xXXXXYYYY][0xYYYY8E00], where X denotes digits of kernel code segment selector number, and Y denotes digits of address of the divide_error routine.

这些 8 字节的数据结构是处理器定义的中断描述符。处理器使用它来识别必须采取哪些操作来响应具有特定向量的中断的接受。现在让我们看看英特尔为 x86 处理器系列定义的中断描述符的格式:

                              80386 INTERRUPT GATE
31                23                15                7                0
+-----------------+-----------------+---+---+---------+-----+-----------+
|           OFFSET 31..16           | P |DPL|  TYPE   |0 0 0|(NOT USED) |4
|-----------------------------------+---+---+---------+-----+-----------|
|             SELECTOR              |           OFFSET 15..0            |0
+-----------------+-----------------+-----------------+-----------------+

在这种格式中，SELECTOR:OFFSET 对定义了函数的地址(长格式)，它将控制响应中断接受。在我们的例子中，这是 __KERNEL_CS:divide_error ，其中 divide_error()是除零异常的实际处理程序。
P 标志指定描述符应被视为由操作系统正确设置的有效描述符，在我们的例子中它处于提升状态。
DPL - 指定 divide_error() 所在的安全环功能可以通过使用软中断来触发。了解该领域的作用需要一些背景知识。

中断源一般分为三种:

从操作系统请求服务的外部设备。

处理器本身，当发现它收入进入异常状态时
请求操作系统帮助它摆脱那种状态。

在操作系统控制下的处理器上执行的程序，它向操作系统请求某些特殊服务。

最后一种情况以专用指令 int XX 的形式得到处理器的特殊支持。每次当程序需要OS服务时，它设置描述请求的参数并发出带有描述中断向量的参数的int指令，OS用于提供服务。通过发出称为软中断的 int 指令产生的中断。所以在这里，处理器只在处理软中断时才考虑 DPL 字段，在处理器本身或外部设备产生的中断的情况下完全忽略它们。 DPL 是一个非常重要的特性，因为它禁止应用程序模拟设备，并由此暗示系统行为。

例如，想象一下某个应用程序会做这样的事情:

for(;;){
    __asm int 0xFF; 

  //where 0xFF is vector used by system timer, to notify the kernel that the 
   another one timer tick was occurred
}

在那种情况下，您计算机中的时间将比现实生活中的时间快得多，然后您期望和您的系统期望。因此，您的系统将表现得非常严重。如您所见，处理器和外部设备被认为是受信任的，但对于用户模式应用程序而言并非如此。在我们的除零异常情况下，Linux 指定只能由环 0 的软中断触发此异常，或者换句话说，只能由内核触发。结果，如果 int 0 指令将在内核空间中执行，处理器会将控制权交给 divide_error()常规。如果将在用户空间执行相同的指令，内核会将其视为保护违规，并将控制权传递给通用保护故障异常处理程序(这是所有无效软中断的默认操作)。但是，如果处理器本身试图将某个值除以零会产生除零异常，则控制将切换到 divide error()。例程而不管发生错误划分的空间。
一般来说，允许应用程序通过软中断触发除零异常看起来不会有太大的危害。但是对于第一个来说，这将是一个丑陋的设计，而对于第二个来说，幕后可能存在一些逻辑，这依赖于这样一个事实，即除零异常只能由实际不正确的除法操作生成。

TYPE 字段指定处理器必须采取的辅助 Action 以响应中断接受。实际上只使用两种类型的异常描述符: 中断描述符和 陷阱描述符 .它们仅在一方面不同。中断描述符强制处理器禁用 future 的中断接受，而陷阱描述符则不会。老实说，我不知道为什么 Linux 内核决定使用中断描述符进行除零异常处理。陷阱描述符对我来说听起来更合理。

关于测试程序令人困惑的输出的最后说明

Floating point exception (core dumped)  

由于历史原因，Linux 内核通过向尝试除以零的进程发送 SIGFPE(读取信号浮点异常)信号来响应除零异常。是的，不是 SIGDBZ(阅读 SIGNal 除以零)。我知道这已经够困惑了。这种行为的原因是 Linux 模仿了原始的 UNIX 行为(我认为这种行为在 POSIX 中被卡住了)和原始的 UNIX 为什么将“除以零”异常视为“浮点异常”。我不知道为什么。