实际上，市场上几乎所有的 CPU，除了用于低功耗嵌入式设备的非常小的 CPU，都提供“硬件强制隔离”。这称为MMU。综合而言，MMU 将地址空间分成单独的页面（通常每个 4 或 8 kB；这取决于 CPU 架构和版本），并且每当某些代码访问页面时，MMU 会强制执行访问权限，并映射访问权限到物理地址（或者不是——这就是“虚拟内存”的工作方式）。在任何时候，CPU 都会通知 MMU 当前代码是“用户代码”还是“内核代码”，MMU 使用该信息来了解是否应授予访问权限。

每个页面的访问权限和到物理地址的映射在内存中的特殊表中配置，内核向 MMU 显示（基本上是通过将主表的物理 RAM 中的起始地址写入专用寄存器中）。通过切换 MMU 配置，内核实现了进程的概念：每个进程都有自己的地址空间，当内核决定将 CPU 授予一个进程时，它通过使该进程的 MMU 配置成为活动的来实现配置。

这与这些东西所能得到的硬件一样。如果你想要一个纯软件的隔离强制，那么你将不得不查看 Java 或 C#/.NET 之类的东西：强类型、数组边界检查和垃圾收集允许在没有一个 MMU。

基于 MMU 的进程隔离在实践中效果很好——进程不能改变甚至看到其他进程的页面。最后一个没有正确执行此操作的主要操作系统是 Windows-95 家族（直到并包括 2001 年臭名昭著的 Windows Millenium Edition）。

当您开始了解完全隔离是无用的时，麻烦就开始了：应用程序进程必须在某些时候能够与硬件交互，以保存文件或通过网络发送数据或显示图像。因此，必须有一些特定的网关，允许一些数据流入和流出每个进程的隔离地址空间，并在一个仲裁系统的严格控制下，保持一致性和分配给进程的硬件资源；该仲裁系统正是所谓的“操作系统”。逃避隔离的“网关”通常称为系统调用。

现在，操作系统是软件，并且有错误，因为每个重要的软件都有错误。其中一些允许恶意编写的进程以不良方式影响其他进程；这被称为“安全漏洞”。但是，制作“全硬件操作系统”并不能解决任何问题。事实上，这可能会使事情变得更糟。硬件也有错误；错误的来源是开发人员试图做的事情很复杂。在硬件中进行此操作只会使错误修复变得更加困难，因此它根本不会改善安全状况。

因此，为了更好地隔离进程，解决方案不是在问题上投入更多的硬件。这些东西已经足够了（也许太多了）。需要的是降低复杂性，这实际上是对系统调用列表进行彻底的修剪和重新设计。一个基本的 Linux 内核提供了 300 多种不同的系统调用！在尝试防止安全漏洞时，这需要做很多工作。不幸的是，删除系统调用会破坏与现有代码的兼容性。

首先，目前“硬件强制隔离”的实现看起来不够且薄弱。这里只是几个“讨厌”的问题：

1. 以“特权”模式运行的进程为什么可以访问所有其他进程的数据？
2. 设备驱动程序应该以“特权”模式还是“用户”模式运行？这两种解决方案都会导致严重的问题：在“特权”模式下运行的驱动程序对敏感数据的访问权限过多。以“用户”模式运行的驱动程序必须访问设备，因此必须将设备访问权限授予应用程序。
3. 我们真的信任所有设备驱动程序的供应商吗？
4. 所有现代操作系统都起源于我们所谓的“良好编程实践”完全不为人知的时代。可以检查任何开源操作系统的代码并在那里发现很多（抱歉）混乱。我们是否相信商业操作系统要好得多——仅仅因为我们看不到它们的来源？
5. 任何现代操作系统都是非常复杂的软件。提高复杂软件可靠性的常用方法是结构化。这种结构必须由各个模块之间的一些强制“边界”来支持。在 OS 编程中没有办法支持/强制执行这种隔离。所以我们只相信设计、支持和编码操作系统的人的良好意愿。

这个列表可以继续。

我最近搜索了有助于解决这些问题的 CPU 设计。没有发现这样的设计。