假设我要基于一个很小的本机较低层内核构建操作系统，该较低层本地内核充当托管代码解释器/运行时，并基于一个较大的较高层内核编译为非本地机器语言（Java字节码，CIL等）。类似操作系统的示例将是Singularity和Cosmos。
与纯本机解决方案相比，使用这种基础结构编写操作系统存在哪些陷阱和开发挑战？
假设我要基于一个很小的本机较低层内核构建操作系统，该较低层本地内核充当托管代码解释器/运行时，并基于一个较大的较高层内核编译为非本地机器语言（Java字节码，CIL等）。类似操作系统的示例将是Singularity和Cosmos。
与纯本机解决方案相比，使用这种基础结构编写操作系统存在哪些陷阱和开发挑战？
Answers:
根据语言，可能会遇到许多开发挑战：
指针：如果一种语言没有指针，那么完成相对简单的任务将是一个挑战。例如，您可以使用指针写入VGA内存以打印到屏幕上。但是，在托管语言中，您将需要某种“插件”（来自C / C ++）来执行相同的操作。
组装：操作系统始终需要进行一些组装。与C / C ++不同，诸如C＃，Java等语言无法很好地与之配合使用。在C或C ++中，您还可以使用内联汇编，这对于许多任务非常非常有用。在很多情况下需要这样做（x86中的示例）：加载GDT，加载IDT，启用分页，设置IRQ等。
控制：如果您使用的是Cosmos之类的东西，则您没有完全的控制权。Cosmos是一个微内核，本质上是“引导”您的“内核”。如果您确实想执行，可以从头开始实现Cosmos之类的功能，但是这可能需要很长时间。
开销：与C甚至C ++相比，托管语言的开销很大。像Cosmos之类的东西需要执行很多事情才能甚至运行C＃hello world内核。在C语言中，您准备就绪，无需进行实际设置。在C ++中，只有一些事情需要实现才能使用C ++的某些功能。
结构：在C / C ++中，有些结构是许多托管语言所不具备的，因此，您将需要实现某种具有某种结构的方法。例如，如果要加载IDT（中断描述符表），则可以在C / C ++中创建一个结构（具有打包的属性），并使用x86 ASM指令lidt加载它。用托管语言，这很难做...
从语法角度来看，托管语言更容易，但是，对于许多与OS相关的事情，很多时候并不十分适合。这并不意味着它们无法使用，但是，通常建议使用C / C ++之类的东西。
我听说它（由一位研究微内核技术的研究人员声称）对如何评估通过托管代码可扩展的系统的安全性知之甚少。
问题在于，可能导致安全漏洞的错误类型与安全研究人员所习惯的完全不同。在传统的微内核中，内核的所有驱动程序和其他子部分通过在不同的地址空间中运行而彼此隔离。在通过类型检查托管代码实现隔离的微内核中，避免了每次需要使用子服务时切换地址空间的巨大开销，但是折衷是现在评估隔离机制更加困难。
当且仅当类型检查器说驱动程序是安全的并且类型检查器没有错误时，用托管语言编写的内核的任何特定部分（例如设备驱动程序）才是安全的。因此，类型检查器是内核的一部分。在实践中，类型检查器似乎比传统的微内核大得多，并且更复杂。这意味着攻击面可能更大。
我不知道传统的微内核隔离技术还是基于托管代码的隔离技术是否确实可靠。这里有一个引导问题：在广泛使用托管代码隔离技术之前，我们不会知道它们不安全的频率。但是，如果不知道它们有多不安全，就很难在安全性至关重要的情况下部署它们。