This is the basic idea behind the exokernel concept: have the kernel's only job be to enforce protection boundaries between processes, and then expose an interf

This is the basic idea behind the exokernel concept: have the kernel's only job be to enforce protection boundaries between processes, and then expose an interface to userspace that is identical to what the hardware exposes (eg. directly write to buffers and queues): https://en.wikipedia.org/wiki/Exokernel https://en.wikipedia.org/wiki/Exokernel No production exokernels were built, but the concept lives on as virtualization. Most hypervisors (eg. Xen) work on a substantially similar principal: the hypervisor is responsible for securely multiplexing the hardware between guest OSes, and then the guest OS talks to an interface that basically looks like the hardware. A step beyond this is to get rid of the guest OS and have application code talk directly to the hardware interface. This is a unikernel (or called a "libOS" in the original exokernel papers), and as you predict, unikernels running on a hypervisor are often faster than traditional monolithic kernel OSes. The main thing blocking their adoption is that they require significant rewrites to application-level code: most applications (and the libraries they depend on) generally assume POSIX syscalls are available and would need to be largely rewritten to work in terms of direct hardware access. You can rewrite POSIX as a library in userspace (this was the approach taken by the original exokernel research), but most of the performance gains come from bypassing inappropriate abstractions, so if you use the same abstractions you get basically the same performance. https://en.wikipedia.org/wiki/Unikernel https://en.wikipedia.org/wiki/Unikernel