Penetration-resistance of a HaLVM unikernel
A HaLVM unikernel is a Haskell program compiled with a modified version of the Glasgow Haskell Compiler to produce a standalone Xen kernel, which will boot on any Xen PV machine instance. A HaLVM unikernel thus replaces the operating system with the runtime system provided by the Glasgow Haskell Compiler and a Haskell network stack.
The HaLVM-GHC compiler is a modification of the standard Glasgow Haskell Compiler (GHC), such that this compiler's runtime system (RTS) -- including memory allocator/manager, thread scheduler (and probably other parts) -- replace those functions of an operating system, and the hans package provides a pure Haskell network stack.
Based on my understanding of all the things involved, I sense that the security of this constellation is either really high, or there are a couple a few obvious-to-any-pen-tester vulnerabilities that haven't been discovered yet, because the GHC RTS hasn't really been looked at from a software security perspective.
- Are there any demonstrations (with code examples) of a Haskell program taking control of the RTS from within?
- The RTS consists of (as per 2011) ~50,000 lines of C code. Has this been analyzed from a software security perspective?
- As a security guy, what is your personal sense of the security level of this stack (Haskell program <-> HaLVM unikernel <-> Xen PV <-> (Amazon Xen PV implementation?))?
It should be noted that HaLVM uses GHC's single-threaded runtime. How much of the 50,000 lines of C have to do with the multi-threaded runtime, thus making it irrelevant to the current version of HaLVM, I don't know. But in the future, HaLVM may support the multi-threaded runtime, and at least then will this portion of the RTS C code also be interesting from a security perspective.
EDIT: Turns out I was not paranoid when I included Amazon's Xen implementation as a risk factor: http://arstechnica.com/security/2016/08/new-attack-steals-private-crypto-keys-by-corrupting-data-in-computer-memory/. Looks like this is hardware-level stuff, but highly relevant nonetheless.
