作業系統中Kernel Mode和User Mode的區別

簡述：

為了不讓程式任意存取資源，大部分的CPU架構都支援Kernel mode與User mode兩種執行模式。當CPU運行於Kernel mode時，任務可以執行特權級指令，對任何I/O裝置有全部的訪問權，還能夠訪問任何虛擬位址和控制虛擬記憶體硬體；這種模式對應x86的ring0層，作業系統的核心部分，包括裝置驅動程式都運行在該模式。當CPU運行於User Mode時，硬體防止特權指令的執行，並對記憶體和I/O空間的訪問操作進行檢查，如果啟動並執行代碼不能通過作業系統的某種門機制，就不能進入核心模式；這種模式對應於x86的ring3層，作業系統的使用者介面部分以及所有的使用者應用程式都運行在該層級。

詳述：

From：部落格園 - 愛拼才會贏 - benjamin超人http://www.cnblogs.com/BenjaminYao/

這是一篇關於OS（作業系統）的筆記，在這裡我將用Linux Kernel作例子，解釋OS中Kernel/User mode的概念，由於作者才疏學淺，若有闕漏以及謬誤，敬請指正，感謝。

在許多電腦的硬體架構中，為了不讓程式任意存取任何資源（例如隨機存取儲存空間RAM），大部分的CPU架構都支援Kernel mode與User mode兩種執行模式，當然這種模式也得要OS有相關實際配合才有作用，像DOS就沒有Kernel/User mode的分別，所有以DOS執行的程式都可對任意資源執行任何行為，所以DOS上的病毒才能那麼囂張，動不動就格式化硬碟。

一般來說， 應用程式是在User mode中執行程式，普通的數值計算或變數指派都可以在此模式完成，但是若要執行一些危及系統安全的指令（例如對磁碟寫入資料），而這些指令是不準在User mode中執行的，強要執行那些特殊指令只會讓系統給你一個錯誤資訊而已，應用程式必須呼叫一些OS定義好的函數才能達成那些功能，例如printf()，這些OS事先定義好的函數我們稱為system call（系統調用）。

當應用程式執行了system call，並不是傻傻地讓應用程式想做什麼就做什麼，他們首先會嚴密地檢查這個調用的應用程式的許可權以及操作的內容（是否讀取不屬於自己的儲存空間範圍，是否讀寫沒有許可權讀寫的檔案，是否想把資料往錯誤的裝置送過去......），若是有任何錯誤，system call將會停止執行並回傳一個錯誤代號，讓應用程式知道自己錯在何處。相反地一切檢查都沒問題，system call將會通知CPU進入Kernel mode，並依照應用程式送過來的參數執行特權指令。當特權指令執行完畢，system
call將會通知CPU返回User mode，並回到應用程式中。

Kernel/User mode架構是非常普遍的執行模式，幾乎可以在任何機器上看到這套架構，從電腦到機上盒，刷卡機等等電子商品，為了保護某些特別的指令不被搞不清楚狀況的程式開發人員亂玩，OS開發人員通常藉由定義system call告訴開發人員們，哪些行為必須經過OS的過濾才能執行。

當然Linux等Open source kernel的開發人員可以自行定義並增加system call的數量， 豐富OS與應用程式的溝通介面，不過這種修改得經過非常小心的計劃與測試，因為在system call裡面執行的程式若是有錯，很可能讓整個OS崩潰（死機）！例如許多沒有Open source的驅動程式（xVidia，ATx之類的顯示卡），由於Kernel的開發人員無從得知那些驅動程式的演算法，所以也無法保證那些驅動程式會不會讓Kernel執行到一半掛掉。

事實上，所有第三方撰寫的驅動程式都會有這種問題，Windows常常被人臭罵有時候真的是無辜的，一切都是因為寫驅動程式的第三方公司功力太爛，寫出品質低落的驅動程式讓Windows壞到掛掉，微軟Windows小組也是滿腹苦水（在此並沒有袒護微軟的意思，只是陳述事實）。

英文解釋：

User Mode Code
User Mode code is just about everything that you will see running on your computer. Programs written in user mode utilize the standard Win32 API, and do not interact with the kernel, the memory, or the hardware directly. This is the safest mode of operation,
because user-mode is heavily monitored and restricted by the system. Programs running in user mode may not be able to perform all the same tasks as kernel mode code can (not directly, anyway), but user mode programs have a limited ability to hurt or "crash"
the system.
Kernel Mode Code　
Code operating in kernel mode has fewer restrictions than user-mode code, but with the greater freedom comes a much larger risk of damaging the system. For instance, a poorly constructed device driver can crash the system, and since it runs outside of user
control, there will be no good way to fix it! It is important, then, that kernel mode code be written only when absolutely necessary, and that kernel mode code is extensively tested and debugged before shipping it to the user.
Context Switching
All processes begin execution in user mode, and they switch to kernel mode only when obtaining a service provided by the kernel. This change in mode is termed a mode switch, not to be confused with a context switch (although it sometimes is), which is the switching
of the CPU from one process to another.