operating-system - 内核模式和内存保护

Question

在操作系统用户模式应用程序的虚拟地址空间是私有的，一个应用程序不能更改属于另一个应用程序的数据。每个应用程序都是独立运行的，如果一个应用程序崩溃，崩溃仅限于那个应用程序。其他应用程序和操作系统不受崩溃影响

为什么在内核模式操作系统不保护内存和 BOSD 发生？

Answer 1

首先，在某种程度上，您将始终拥有一个不会失败™的组件。如果此组件崩溃，则无法恢复。例如，如果您丢弃正在运行的进程表，则除了重新启动之外，您无法重建它。因此，即使内存保护将此组件的崩溃限制为仅影响其自身，BSOD（或同等情况）也可能发生。

但是您的观点很好-有许多组件通常可以在没有灾难性故障的情况下重置。例如，驱动程序或网络堆栈。事实上，有一些操作系统可以在这个级别进行保护——它们被称为微内核架构。

然而，微内核的问题在于性能。在 x86 CPU 上，内存保护是通过两件事来实现的——当前特权级别（CPL，或“环”）、一个介于 0（最大访问）和 3（用户模式）之间的数字，以及页表。页表将虚拟地址映射到物理地址，并在每个页面（4096 字节的内存块）上设置访问限制。每个进程都有自己的页表，页表中的每一页都可以通过设置最大CPL、只读标志、禁止执行标志或禁止访问标志来限制。

更改您的 CPL 是一项相对较快的操作（尽管对于如何以及何时允许您这样做有安全限制）。然而，更改页表的成本非常高，因为它需要清除 CPU 上的缓存，称为转换后备缓冲区(TLB)。

通常在普通操作系统中，操作系统会为用户进程保留最低 X GB 的内存（3GB 通常是为 32 位架构选择的数字）。上层 (4 - X) GB 直接映射到物理内存的前 (4 - X) GB，并且仅限于 CPL 0（'ring 0'）。因此，内核可以将它的私有数据结构放在上层 1GB 左右，并且总是在相同的虚拟地址上访问它们，无论运行什么进程。如果一个进程进行系统调用需要六个子系统来做某事，没问题——你可以在它们之间调用函数。

然而，在微内核系统中，每个内核子系统都有自己的页表和自己的地址映射。为了服务用户调用，CPU 可能需要进行相当多的页表更改，并且这种性能损失加起来。此外，每个子系统都需要准备好处理其依赖项的故障，从而增加了系统的复杂性。由于这些问题，总的来说，微内核仅被用作研究和玩具操作系统（例如minix、GNU HURD）。

也就是说，近年来，宏内核和微内核之间的界限有些模糊。例如，在 Windows 7 中，图形驱动程序实际上与内核的其余部分是隔离的；如果它崩溃，系统可以恢复。在 Linux 和 OS X 中，FUSE可以在用户空间加载文件系统驱动程序；实际上，这些系统上的 NTFS 驱动程序使用这种机制。