ProcOS: scheduling atop Unikernels
bentrask.com
bentrask.com
The source is linked from the page - https://github.com/btrask/stronglink
> A searchable, syncable, content-addressable notetaking system
If I were to build a secure multiplexer as a unikernel, I'd still have the "configuration" at compile time only and I'd better have a damn good excuse to keep more state than the packet in transit on that instance (because someone would have to pay for the work to make the whole system consistent in the presence of buffering/caching nodes).
The emphasis on cheap recursion (if it can be achieved) also has benefits like making administrative responsibilities easier to delegate, and preventing various isolation leaks (including scheduling fairness).
Randomly, I think the interesting thing with unikernels is that with most modern languages being memory-safe (rust, python, java, .net, javascript) we don't need process isolation.
His idea isn't yet fully baked, but it's basically having a userland os provide scheduling and permissions management for other os's on the machine. Which is a little odd because the hypervisor needs its own scheduler to decide what vm to run next, and switching from a vm, to the hypervisor, to the scheduler vm, to the hypervisor, to another vm sounds really inefficient. Why not have the scheduler in the hypervisor? Having a dedicated vm for permissions management sounds suspect as well, as you have to perform that same series of switches to decide whether a user is authenticated. I think what he really wants is actually a hypervisor.
In a unikernel the hypervisor provides the memory isolation instead of the os. If we don't provide memory isolation at all it would basically transform remote code execution vulnerabilities into root privilege execution. If I can find a bug in your code or the cpython runtime I can own your machine. Memory safety is just the beginning of security, not a cure all.