作業系統分析——為什麼需要RPL,request privilege level
在學特權級的時候，我們都會知道一共有三個特權級：CPL，DPL，RPL。
CPL和DPL是比較好理解的，CPL是當前CPU所在的特權級，這個值是儲存在CS段暫存器的段選擇子中的。而DPL則是目標段描述符的特權級。我們想啊，我現在帥的等級為CPL，這個等級可以通過我身上的一個叫做CS的東西知道。然後我想去訪問某個地方。這個地方不是可以隨便訪問的，這些地方是有特權級DPL，世界的法則規定只有CPL<=DPL，我才能去訪問這個地方。
而RPL又是什麼的呢？這個值就是我們給定的段選擇子的最低兩位的數值，一般這個值是由程式設計師來給定的。於是很多人會把這個RPL調為0，假裝它的請求特權級都是最高特權的，而讓RPL近似於無效。這麼看的話，好像RPL沒有什麼存在的必要性。
其實，RPL通常情況下是的確沒有啥作業，因為程式設計師會把這個值設定為0，而使得RPL檢查失效。然而，考慮這麼一種情況：
假設某個系統提供一個系統呼叫sys_fun(segment)。這個系統呼叫負責從磁碟讀一波東西，然後寫到一個目標段segment中。
先假設沒得RPL，CPU只基於CPL和DPL來實施特權級保護。 呼叫者的CPL一般處於ring3特權級。通過系統呼叫，系統的CPL由ring3翻轉到了ring0。既然CPL等於ring0了，那麼無論目標的segment是多少都可以往裡面寫資料了。如果呼叫者故意把目標Segment填成0x0008。即核心段的程式碼段。那就完蛋了,核心的程式碼機會被覆蓋掉。這肯定是不被作業系統設計員和CPU容忍的。
於是，如果有一個東西能夠記錄呼叫者之前所在的舊CPL就好啦，然後在寫入目標segment的時候，先把目標segment的RPL改成舊的CPL，就可以解決這個問題。
而這正是RRL可以發揮作用的地方！也就是說，在這類情況下，CPU是會把目標運算元的Segment裡面的RPL修改掉的，而不是使用者自己填入的。