首先要明確的壹個簡單的原則：軟件的功能壹定要建立在硬件支持的基礎之上。可以說，軟件實現的功能，是由硬件邏輯堆積封裝而來的。
那麽，壹個操作系統，我們知道，它具有很多內核的代碼、數據結構。控制著整個計算機系統的運轉，例如I/O輸出、內存訪問等等。
現在的多進程操作系統，提供給了用戶自己編程的功能，也就是讓用戶自己編程，自己創建進程。那麽，壹個問題就來了，壹個進程假如需要系統的功能調用怎麽辦？
假如讓進程來自己控制那些設備的驅動，那麽，難免會有惡意的用戶進程來破壞；或者說低水平的程序員控制錯誤。那麽，這部分功能就交給操作系統來進行維護。
也就是說，在壹個用戶進程的運行過程中，它壹直是處於用戶態的。當需要系統的服務的時候，就必須借助壹個途徑，從當前PC運行的用戶地址空間轉移到內核的代碼地址空間。這個怎麽轉移呢？壹個答案就exception，壹個與中斷類似的過程。這時，這個中斷處理函數就會去訪問壹個固定的地址，例如壹張表，而那張表中登記了各個系統服務函數的入口地址（這個在系統起來的時候就創建好了）。這時候，在查到那個系統服務之後，這個exception處理函數就會將系統的狀態提升到特權級，然後再進入那個服務函數，這時，系統就能繼續通過特權級進行系統的操作了。當這個調用完成之後，就會返回到剛剛的handler exception處理函數之中，這時這個 exception handler函數再將系統的的狀態降到用戶態。這樣，返回到剛才的用戶進程代碼空間之後，系統的特權級就降為用戶態。這樣，對於用戶來說，只是進行了壹個系統服務的調用。通過這個系統調用才能提升該進程運行過程中的系統特權級，然後運行完之後，再返回用戶進程之前，重新被降為用戶態。
過程如該圖：
User Process:
instruction i 觸發中斷，有對應的處理函數入口 異常處理函數（會提升降低系統狀態）
syscall ------> exception triggered ---> exception handler --> kenel function
user mode user mode ---> kernel mode
所以，從剛才的例子來看，進程的狀態從用戶態到系統態的提升，實際上靠的就是這個exception handler這個中斷處理函數。對於這個函數的查找，我個人的理解是這樣的：
在系統運行之後，操作系統有壹個固定的中斷號是對應於壹個固定的處理函數，這個處理函數回去找壹個對應的系統服務函數，在進入到這個系統服務函數之前，這個處理函數會去將寄存器對應的位修改為特權態。這時，轉入到對應的系統調用函數，此時系統就允許具有特權態的CPU訪問對應的內存地址（內核代碼）。否則，系統就會報錯。
這樣的壹個系統特權的提升，實際上是硬件設計好的壹個存取的保護。可以這樣講。當前，我們的操作系統都使用的是分頁機制，每個頁都在頁表中都占壹個記錄，而這個記錄往往還有壹個項記錄該張頁表是否能被用戶態或者內核態訪問。
簡單的來說就是，cpu的PC取壹條指令，該指令就是虛擬地址，然後根據該地址查到對應的頁，此時，這個頁的有壹項會被檢查，就是該頁當前能否能被訪問，判斷的方式就是去查當前某個寄存器的某壹位，看當前是否處於內核態，假如處於內核態，就會去訪問，假如不行，那麽硬件就會報錯，說明該進程不能訪問對應的頁。
其實說白了，在系統中加了壹個寄存器，在內存中的頁表中放了壹個對應位。然後再加上壹些默認的硬件檢查。看訪問壹張頁面的時候這個寄存器是否被設置。就這麽個過程而已。
最後再總結壹個東西，具有內核態的 進程能夠訪問 系統的所有頁 (這樣，就能訪問所有內核的代碼，數據結構等等)。而只有用戶態的進程只能訪問它所具有訪問權限的頁。
我的理解就是這樣，不過我自己總結下來看，內核態確實是反映在硬件上的。
但是關鍵是要看，當前的CPU是屬於哪個進程的。當然了，因為所有進程都屬於OS，所以，我覺著說OS處於什麽態也是可以的……
個人理解，希望不要誤導妳們