HaLVM unikernel 是使用 Glasgow Haskell 编译器的修改版本编译的 Haskell 程序，以生成独立的 Xen 内核，该内核将在任何 Xen PV机器实例上启动。因此，HaLVM unikernel 用 Glasgow Haskell 编译器和 Haskell 网络堆栈提供的运行时系统替换了操作系统。

HaLVM-GHC 编译器是对标准 Glasgow Haskell 编译器 (GHC) 的修改，因此该编译器的运行时系统 (RTS)——包括内存分配器/管理器、线程调度器（可能还有其他部分）——替换了操作系统，并且该hans软件包提供了一个纯 Haskell 网络堆栈。

根据我对所涉及的所有事情的理解，我感觉这个星座的安全性要么非常高，要么有几个明显的漏洞尚未被发现，因为GHC RTS 并没有真正从软件安全的角度来看待。

• 是否有 Haskell 程序从内部控制 RTS 的任何演示（带有代码示例）？
• RTS 由（根据 2011 年）~ 50,000 行 C 代码组成。是否从软件安全的角度对此进行了分析？
• 作为一名安全人员，您个人对这个堆栈的安全级别有什么看法（Haskell 程序 <-> HaLVM unikernel <-> Xen PV <->（Amazon Xen PV 实现？））？

需要注意的是，HaLVM 使用 GHC 的单线程运行时。50,000 行 C 语言中有多少与多线程运行时有关，因此与当前版本的 HaLVM 无关，我不知道。但在未来，HaLVM 可能会支持多线程运行时，至少从安全角度来看，这部分 RTS C 代码也会很有趣。

编辑：当我将亚马逊的 Xen 实施作为风险因素包括在内时，我并没有偏执：http: //arstechnica.com/security/2016/08/new-attack-steals-private-crypto-keys-by-corrupting-data -在计算机内存中/。看起来这是硬件级别的东西，但仍然高度相关。