操作系统中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.