By their nature, unikernels are extremely well suited to running on top of a simple and well-defined interface. By extension, such interfaces are easy to audit

By their nature, unikernels are extremely well suited to running on top of a simple and well-defined interface. By extension, such interfaces are easy to audit and secure. Why is this better than running as a normal user process? Look at the complexity inherent in securely sandboxing applications using existing interfaces -- the Linux system call interface amounts to hundreds of system calls, with different mutations for different architectures and many calls multiplexing even more operations (eg. ioctl()) the numbers grow even higher. Unikernels give us a shot at redefining the process interface, while still being able to run on existing infrastructure (host OS or hypervisor). This means we can work toward a system where the application (unikernel) has least privilege by default. With Solo5 [1] we're working towards defining such an interface. We have a way to go yet [2], and are still very much in the "early adopter who knows what a unikernel is" stage, but the possibilities are exciting, not only from the application security point of view. [1] https://github.com/solo5/solo5 https://github.com/solo5/solo5 [2] I'd be the first to say that the current Solo5 interfaces are suboptimal, but we're working on it: https://github.com/Solo5/solo5/pull/201 https://github.com/Solo5/solo5/pull/201