Unikraft is a comprehensive toolchain and library operating system which builds highly specialized unikernels, software bundles that consist of a target application along with just the operating system primitives and libraries features it needs to run.
Unikraft breaks the status quo of building unikernels manually, providing an automated toolchain that builds tailored unikernels that meet your (and your application’s) needs.
We haven’t been paying a lot of attention to the concept of unikernels on OSNews, and I’m not sure why – possibly because they’re outside of the comfort one of a lot of people, including myself.
This sounds like a great idea for containerized environments and embedded devices. The de-bloating and reduction of attack surface is a big deal.
Yes, I was kind of vaguely thinking this a topic or two back so it’s productive to put up an article on unikernels. Rather than discuss the security issues relating to applications and toolchains let alone OS I’d personally like to focus on the debloating issue. Once you strip out the eyecandy and whatnot the user interface needs and business logic of lots of applications isn’t that great even if the library and OS code behind it is. It would be nice if there was a magic wand which would perform debloat on all this to crunch things down even smaller.
Actually, another thing which would be handy is if things were ROMable to stop post install meddling.
Unikraft uses DCE (Dead Code Elimination) and LTO (Link Time Optimization) to produce debloated images (on top of having a modular architecture to make it easier than monolithic OSes to keep unneeded components out of images). Regarding your comment about “ROMable”: most unikernels, including Unikraft ones, don’t come with a shell/ssh server/rest API to modify their state beyond what the application (e.g., a web server) might allow. A more draconian approach would be to “seal” the unikernel (if running as a VM) as suggested in [1], where “…any code not present in the unikernel at compile time will never be run, completely preventing code injection attacks.” This method would apply to any VM, including Unikraft ones.
[1] http://mort.io/publications/pdf/asplos13-unikernels.pdf
@fhuici
I was thinking more code substitution on top of DCE and LTO. Loads of applications could ditch complex graphical overhead for a text based interface, or for other general code more optimised libraries. Also not every application is running on Linux or Windows. I kind of assumed any “code not present” would be deadended. Still, it’s all a nice idea as far as it goes. It suits my sense of humour to take 10GB of stuff and debloat it down to a couple of megabytes.
I still can’t get used to the amount of crap in languages and systems. Mind you if it was important you’d be coding on something else.
Running this on an OS with a separation kernel would be ideal for security.
We have a working prototype that uses Intel MPK and software fault isolation mechanisms to isolate the different libraries in Unikraft. This is work in progress; we should be able to have something publicly available in the coming months.
Excellent. I would love to see this in action.
Secure lean builds for IoT are always of interest, of course a lot of work has been done manually generating unikernels for various platforms, but having a simple automated and reliable cross platform build environment with a focus on lean, secure and fast would be a game changer.
Most of the hacker/dev toolchains produce rather bloated solutions, (bloated by IoT standards were kilobytes matter.) as they are really designed to work reliably with maximum utility rather than work efficiently which is understandable. Manufacturers tend to focus libraries on broadening the application surface rather than improving performance, they leave performance improvements up to hardware evolution.
People often look excitedly at the specs of IoT hardware, and then after tinkering for a period leave disappointed having been victims of bloat.