HermiTux is a unikernel: a minimal operating system with low memory/disk footprint and sub-second boot time, executing an application within a single address space on top of an hypervisor. Moreover, HermiTux is binary-compatible with Linux: it can run native Linux executables.
Although being a proof-of-concept, HermiTux supports multiple compiled (C, C++, Fortran) and interpreted (Python, LUA) languages. It provides binary analysis and rewriting techniques to optimize system call latency and modularize a kernel in the presence of unmodified binaries. It supports statically and dynamically linked programs, different compilers and optimization levels. HermiTux also provides basic support for multithreading, debugging and profiling.
HermiTux is a research project at Virginia Tech.
I guess no one here knows what to make of it?
Is this like link time optimization taken to the next level?
kwan_e,
I haven’t had the time to try it.
I don’t know if existing unikernels make this possible or not, but it would be totally awesome if application level code + service level code (ie user app + database) could be automatically rewritten to shortcut the code path that normally occurs through the libraries + sockets + kernel.
For example
val = sql(“select 1+1”)
A sophisticated unikerenl compilation ought to be able to optimize this down to val = 2.
Obviously this is a dumb example, and I’m oversimplifying by overlooking stateful side effects that probably exist in the sql code path, but never-the-less a unikernel with this level of cross-process recompilation optimization capability would be rock. I’d love to work on something like this 🙂
A recent white paper* from NCC group sheds doubt on the security benefits of unikernels. NCC has an agenda of courrse, but even if you take this into account the report is surprisingly scathing. Some of the issues raised relate to specific implementations, but some are more general issues.
*If* the security benefits of unikernels are overstated, are the remaining benefits (fast boot time, small memory footprint) enough to make unikernels interesting in a practical setting? Clearly the focus for HermiTux is compatibility, and that makes it interesting in its own right, but I’d like to know the use-cases for unikernels other than security.
* https://www.nccgroup.trust/us/our-research/assessing-unikernel-security/
flypig,
That’s an interesting link, I took a look at their paper out of curiosity.
It seems that every one of their criticisms applies to unmanaged code since managed code does not have the kinds of faults that benefit from those mitigations. It’s unclear to me at the moment to what extent managed languages running within a rumprun VM would be vulnerable due to vulnerabilities within the unikernel iitself?
Their premise that programming overflow vulnerabilities can affect the entire VM makes sense. However I sort of feel that a unikernel should be treated similarly to a client VM and get locked down at the host operating system. This includes using iptables to limit the VM to permissible network packets. As an administrator for client VMs (where clients & 3rd parties have root access and may theoretically run untrusted code) I feel this is the best practices for virtual machines – do not trust the client OS to enforce it’s own restrictions, client security&isolation should be enforced by the host! While I haven’t really experienced unikernels first hand, my gut reaction is the same security methodology can/should be applied to unikernels as well.
So long as the host OS locks down the VM and administrators treat the entire unikernel in the VM as a single application without security barriers between components, then unikernels should be ok.
Anyone have other opinions?