language-agnostic - 是否可以在托管操作系统之上运行“本机”代码？

Question

我正在阅读 Midori 并且有点开始想知道这是否可能。

在托管操作系统上，“托管代码”将是本机的，而“本机代码”将是……外星人？至少在理论上，是否有可能在托管操作系统上运行今天的本机代码？

Answer 1

首先，您应该从定义“托管”和“本地”开始。在像 Midori 这样的“托管”操作系统上，内核仍然是 ngen-ed（预编译为机器代码），而不是从 IL 即时编译。因此，我会将其排除为“托管”和“本地”之间的区别。

我想到的“托管”代码和“本机”代码之间还有另外两个区别——代码可变性和资源管理。

大多数“本机”代码是无法验证的，因此“托管”操作系统加载程序甚至可能拒绝加载“本机”图像。当然，可以生成可验证的“本机”代码，但这会带来很多限制，本质上与“托管”代码没有什么不同。

“托管”操作系统中的资源将由操作系统而非应用程序管理。“本机”代码通常分配和清理其资源。由 OS API 分配并提供给“本机”代码的资源会发生什么情况？或相反亦然？关于谁以及何时进行资源管理和清理应该有非常明确的规则。出于安全原因，我无法想象操作系统将“本机”代码直接控制到进程虚拟内存之外的任何资源。因此，“原生”的唯一原因是实现自己的内存管理。

今天的“natve”代码不符合上述任何规则。因此，“托管”操作系统应该拒绝直接执行它。不过，“托管”操作系统可能会提供像 Hyper-V 这样的虚拟化层，并在虚拟机中托管“本机”代码。

Answer 2

通过托管，我假设您的意思是代码在一个环境中运行，该环境对代码的类型安全、安全内存访问等进行一些检查。而本机，嗯，正好相反。现在它的这个执行环境决定了它是否可以允许本机代码在未经验证的情况下运行。这样看：操作系统和顶层应用程序都需要一个执行环境来运行。它们唯一的关系是顶层应用程序正在调用底层操作系统以执行较低级别的任务，但在调用操作系统时，它实际上是由执行环境（可能/可能不支持代码验证，具体取决于编译代码时传递的选项），当控制权转移到操作系统时，执行环境再次负责执行操作系统代码（这个环境可能是另一个环境一起），在这种情况下，

因此，理论上，本机代码可能/可能不会在托管操作系统上运行。这一切都取决于其运行所在的执行环境的行为。操作系统是否托管不会影响它是否在其上运行。如果顶级应用程序和操作系统都具有相同的执行环境（托管），则本机代码将不会在操作系统上运行。

Answer 3

从技术上讲，本机代码模拟器可以用托管代码编写，但它不能在裸硬件上运行。

我怀疑任何依赖软件验证来隔离对共享资源的访问（例如 Singularity）的托管操作系统都允许直接运行非托管代码，因为它可能能够绕过软件提供的所有保护（与普通操作系统不同，某些托管操作系统不这样做） t 依赖于硬件提供的保护技术）。

Answer 4

来自 MS Research 论文Singularity: Rethinking the Software Stack (p9)：

原则上，保护域可以托管一个进程，该进程包含使用不安全语言（如 C++）编写的无法验证的代码。虽然对于运行遗留代码非常有用，但我们尚未探索这种可能性。目前，保护域内的所有代码也包含在 SIP 中，它继续提供隔离和故障遏制边界。

所以看起来，虽然目前尚未探索，但这是一种明显的可能性。非托管代码可以在硬件保护域中运行，它会因必须处理虚拟内存、TLB 等而受到性能影响，但系统作为一个整体可以在运行非托管代码时安全地维护其不变量。