user space to kernel space

===============================================================================================

 一年之后，再读这篇文章，发现当时自己对很多概念还是模棱两可，对intel保护规则一知半解，今天将它完善，不要误导别人。

===============================================================================================

现代操作系统是绝对不允许用户态代码随意访问内核数据或代码的。

• 1. 特权指令在用户态是不允许执行的
• 2. 严格控制用户态到内核态的切换

首先，要对异常的分类有个清晰的概念，比如说，故障（fault)，最常见的就是 page fault，故障可以被修复，一旦修复后，导致故障的指令会被重新执行。另外一个主要的异常就是今天的主角，编程异常(programmed exception)，指的就是程序员可以通过 int 指令来触发的异常，比如 int 3 （断点），int  128 （系统调用）。 那么除零是什么类型呢？它是故障。

 linux 内核源代码情景分析里面讲述的比较清楚，INT 指令是用户态主动切换至内核的唯一途径，就是这唯一的途径，也是严格受控的。

例如，用户在自己的代码里面嵌入汇编代码

int 2，这必然导致general_protection exception。不仅是2，任何其他异常向量都会导致产生该错误，唯一的例外就是4，5以及128向量，这也是用户态到内核态转换的唯一途径。

这个保护是由intel优先级检验机制和linux内核共同完成的。

intel规定，当通过中断门进入中断处理程序时， 必须满足如下条件

规则1：代码段DPL （由中断门的段选择符指定）<= CPL ，即中断处理程序的特权级别一定要高于引起中断的代码。这个条件基本上就是总是成立的，因为中断处理程序的DPL为0，所以在任何情况下，只要中断发生，必定会切换至内核态

根据上面的规则，如果我们在程序里面故意使用 int  X，那么是不是就可一模拟中断的发生呢？ 如果只有这一个规则，那么显然就存在漏洞，程序员可以毫无估计的，肆意的，在用户态调用中断门或者其它XX门切入内核模式。因为有漏洞，所以Intel 又出新规定了

对于编程异常，除了满足上述条件为，还必须满足下面的条件：

规则2：门描述符的DPL>=CPL

这样的话，linux内核在设置中断向量表时，除4，5以及128位置处门陷阱门描述符DPL设置为3（注意，这里指的是门描述符的DPL，不是处理程序的DPL），其他门的DPL均设为0，来保证用户态调用int 时，只有4，5，128是合法的，其它 int 指令都会导致 general protection 异常。

中断以及其它异常无需遵循规则2