Content #
想象一下，应用程序的编写者通过钻研，知道了操作系统数据段的选择子，而且希望用这个选择子访问操作系统的数据段。
在特权级检查中引入RPL 的必要性
应用程序无法直接访问操作系统数据段，但它可以借助于调用门。调用门工作在目标代码段的特权级上，一旦处理器的执行流离开应用程序，通过调用门进入操作系统例程时，当前特权级从3 变为0。当那个不怀好意的程序将一个指向操作系统数据段的选择子通过CX 寄存器作为参数传入调用门时，因为当前特权级已经从3 变为0，可以从硬盘读出数据，并且允许向操作系统数据段写入扇区数据，他得逞了！
处理器的智商很低，它不可能知道谁是真正的请求者。作为最聪明的灵长类动物，你当然可以通过分析程序的行为来区分它们，但处理器不能。
因此，当指令 mov ds, ax 或者 mov ds, cx 执行时，AX 或者CX 寄存器中的选择子可能是操作系统自己提供的，也可能来自于恶意的用户程序，这两种情况要区别对待，但已经超出了处理器的能力和职权范围。怎么办？
看得出来，单纯依靠处理器硬件无法解决这个难题，但它可以在原来的基础上多增加一种检查机制，并把如何能够通过这种检查的自由裁量权交给软件（的编写者）。引入请求特权级（RPL）的原因是处理器在遇到一条将选择子传送到段寄存器的指令时，无法区分真正的请求者是谁。
但是，引入RPL 本身并不能完全解决这个问题，这只是处理器和操作系统之间的一种协议，处理器负责检查请求特权级RPL，判断它是否有权访问，但前提是提供了正确的RPL；内核或者操作系统负责鉴别请求者的身份，并有义务保证RPL 的值和它的请求者身份相符，因为这是处理器无能为力的。
因此，在引入RPL 这件事上，处理器的潜台词是，仅依靠现有的CPL 和DPL，无法解决由请求者不同而带来的安全隐患。那么，好吧，再增加一道门卫，但前提是，操作系统只将通行证发放给正确的人。