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

Question

我正在阅读Midori，并开始怀疑这是否可能。

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

Answer 1

首先，您应该首先定义“托管”和“本机”。在像Midori这样的“托管”操作系统上，内核仍然是编程的（预编译为机器代码），而不是从IL进行jit编译。因此，我会将其排除在“托管”和“原生”之间。

在我看来，“托管”和“本机”代码之间存在另外两个区别 - 代码可执行性和资源管理。

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

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

今天的“natve”代码将无法遵守上述任何规则。因此，“托管”操作系统应该拒绝直接执行它。尽管如此，“托管”操作系统可能会提供类似Hyper-V的虚拟化层，并在虚拟机中托管“本机”代码。

Answer 2

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

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

Answer 3

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

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

Answer 4

来自MS Research论文Singularity: Rethinking the Software Stack（第9页）：

  

原则上，保护域可以承载单个进程   包含用不安全语言编写的无法验证的代码，例如   C ++。虽然对于运行遗留代码非常有用，但我们没有   然而探索了这种可能性。目前，所有代码都在   保护域也包含在SIP中，并继续   提供隔离和失效遏制边界。

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