Rethinking the OS Boundary
To understand unikernels, you first need to understand the problem with how traditional operating systems are structured.
In a conventional setup, your application runs in user space — a protected memory region separate from the OS kernel, which runs in kernel space. When your application needs to do something privileged (open a file, send a network packet, allocate memory), it issues a system call — a formal request that crosses the user/kernel boundary. The kernel validates the request, performs the operation, and returns the result. This boundary is enforced by the CPU itself using privilege rings (Ring 0 for kernel, Ring 3 for user applications).
This boundary is a security feature, but it comes with a cost: every system call involves a context switch — saving the application's state, switching CPU privilege levels, executing the kernel code, and switching back. For high-throughput applications making millions of system calls per second, this overhead is measurable.
The LibraryOS Model
A Library Operating System (LibraryOS) dissolves this boundary by decomposing the OS into small, composable libraries.
Instead of a monolithic kernel that all applications share, OS functionality — the TCP/IP networking stack, the filesystem driver, the memory allocator, the scheduler — is broken into discrete, independently linkable libraries. Your application selects only the libraries it needs and links them directly into its own binary, just as you would link any third-party library.
The result: there is no kernel/user boundary to cross. The application and its OS libraries run in the same address space, at the same privilege level. A network send is a direct function call, not a system call with a context switch.
The Trade-off
Removing the kernel/user boundary means that a bug in the networking library can corrupt application memory directly — there is no protective wall. This is acceptable in a unikernel because the entire image runs exactly one trusted application. The threat model changes: you are not protecting the OS from a malicious application, because there is only one application and you wrote it.