RPL的故事 ——《x86汇编语言：从实模式到保护模式》读书笔记31

关于RPL（请求特权级），网上的资料不少，不过我认为都没有说明白。希望我可以把这个问题讲清楚，如有纰缪，还请您不吝赐教。

要理解RPL，首先要明白访问数据段时的特权级检查规则。

1. 访问数据段时的特权级检查

为了访问数据段，数据段的选择子必须被加载进段寄存器（DS,ES,FS,GS,SS）。在把一个段选择子加载进段寄存器之前，处理器会进行特权级检查（如下图所示）。

在数值上必须满足以下两点：
1. CPL<=数据段描述符的DPL
2. RPL<=数据段描述符的DPL
否则，会产生一个一般保护异常，且不加载段选择子。

2. 为什么要引入RPL

2.1 概述

当低特权级的应用程序使用call far指令通过调用门将控制转移到较高特权级的非一致代码段（例如操作系统提供的例程，假设其代码段的DPL=0）时，会改变当前的特权级，而在目标代码段的特权级上执行，对于本例来说CPL的数值就会变成操作系统例程段的DPL的数值，即0。如果没有RPL，那么此时CPL权限是最高的，也就可以去访问任何数据，这就不安全了。所以引入RPL，让它代表访问权限，因此在检查CPL的同时，也会检查RPL（正如上文第一节提到的规则）。一般来说如果RPL的数值比CPL大(权限比CPL的低)，那么RPL会起决定性作用。

2.2 狡猾的应用程序开发者

举个例子，比如操作系统提供了一个调用门（这个门对应的目标代码段的DPL为0），其功能是读取硬盘的一个扇区到指定的内存位置。这个调用门有3个参数（通过栈来传递），分别是逻辑扇区号、数据段选择子和段内的偏移。

假设有个应用程序（运行在特权级3）的开发者，通过苦心钻研知道了操作系统数据段的选择子（其指向的数据段的特权级为0），为了搞破坏，他把这个选择子作为参数传给了调用门。如果没有RPL，那么访问数据段的检查规则就是“CPL<=数据段描述符的DPL”。当通过调用门转移后，CPL从3变成了目标代码段的特权级0，正好符合检查规则，于是他的阴谋得逞了。

2.3 善变的CPL

仔细分析这个问题，根源在于CPL变了，摇身一变变成目标代码段的特权级了。所以引入RPL，让RPL代表“真实”的CPL，并且再加上一条规则“RPL<=数据段描述符的DPL”，因为RPL=3，所以检查不会通过。

3. RPL的值是怎么来的

你可能会问，那RPL的值是怎么得来的？难道CPU可以智能识别出CPL变身了，然后自动把CPL变身前的值传递给RPL？

不不不，CPU可没有这么厉害。关于这个问题，我先告诉你一个好消息：RPL的值可以由当前进程随便写。就是上文图中的那个黄色字段，你爱填多少填多少。
这下你乐了吧：）既然随便写，那我写0好了。这样一来，“RPL<=数据段描述符的DPL”总是成立的。

但是别高兴，我还要宣布一条坏消息：操作系统会检查RPL的值，如果你填写的RPL在数值上小于CPL（调用者的特权级，而非目标代码段的特权级），那么操作系统会把RPL打回原形，强制它等于CPL。

4. ARPL指令

为了方便操作系统得到正确的RPL值，处理器提供了ARPL指令。该指令的作用是调整选择子中RPL字段的值（Adjust RPL Field of Segment Selector），其格式为

    arpl r/m16, r16

该指令比较两个选择子的RPL字段。
目的操作数可以是一个通用寄存器（内容是16位的段选择子）或者一个指向16位单元的内存地址（该16位单元存放的是段选择子）；
源操作数只能是一个通用寄存器（内容是16位的段选择子）。

该指令执行时，处理器检查目的操作数的RPL字段，如果它在数值上小于源操作数的RPL字段，则设置ZF标志，并修正目的操作数的RPL字段，使其等于源操作数的RPL字段值；否则，仅仅把ZF标志清零，其他什么也不做。

ARPL是典型的操作系统指令，通常用于调整应用程序传递给操作系统的段选择子，使其RPL字段的值和应用程序的特权级相匹配。

5. 火眼金睛的操作系统

结合上文2.2节的那个例子，配合下图来说明。
为了防止恶意的数据访问，操作系统应该从当前栈中取得用户程序的代码段选择子（调用者代码段寄存器CS的内容，也就是下图中的“原CS”）作为源操作数，并且把作为参数传递进来的数据段选择子（下图中的“参数2”）作为目的操作数，来执行ARPL指令，把数据段选择子的RPL恢复到调用者的特权级别上。

一旦调整了请求特权级，那么当前特权级CPL=0，RPL=3，数据段描述符的DPL=0，虽然符合“CPL<=数据段描述符的DPL”，但是不符合“RPL<=数据段描述符的DPL”，所以会禁止访问，并引发异常。这样一来，狡猾的应用程序开发者的阴谋就不会得逞了。