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

Question

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

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

Answer 1

从技术上讲，本机代码仿真器可以用托管代码编写，但它不在裸机上运行。

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

Answer 2

首先，您应该首先定义“托管”和“本地”。在像Midori这样的“受管理”的操作系统上，内核仍然被编译（预编译为机器代码），而不是从IL进行jit编译。所以，我认为这是“管理”与“本地”之间的区别。

在我看来，“管理”和“本地”代码还有两个区别 - 代码可证实性和资源管理。

大多数“原生”代码是无法验证的，因此“托管”操作系统加载器可能会拒绝加载“原生”图像。当然，制作可验证的“原生”代码是可能的，但这会带来很多限制，实质上与“受管理”代码没有区别。

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

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

Answer 3

通过托管我假设你的意思是代码运行在一个环境中，对代码进行类型安全检查，安全内存访问等等。而原生的，相反。现在它的这个执行环境决定它是否允许本地代码在未经验证的情况下运行。以这种方式来看待：操作系统和顶层应用程序都需要执行env才能运行。它们唯一的关系是顶层应用程序调用底层操作系统来执行较低级别的任务，但在调用操作系统时，它实际上是由执行env（它可能/可能不支持代码验证，例如依赖于编译代码时通过的选项），并且当控制传输到OS时，执行env再次负责执行OS代码（该环境可能是另一个envionment在一起），在这种情况下，它验证操作系统代码（因为它是一个托管操作系统）。

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

Answer 4

从MS研究纸Singularity: Rethinking the Software Stack（P9）：

保护域可能在原则上，主机写入包含在不安全的语言如 C++无法验证的代码单个进程 。尽管对于运行遗留代码非常有用，但我们还没有探索这种可能性。目前， 保护域内的所有代码也包含在SIP内，其继续 以提供隔离和故障限制边界。

因此，虽然目前尚未探索，但它是一种明显的可能性。非托管代码可以在硬件保护域中运行，它将不得不处理虚拟内存，TLB等性能问题，但系统作为一个整体可以在运行非托管代码时安全地维护其不变量。