HomeLog InSource

notes.public

[View] [Short] [Hash] [Raw]

2017-07-10

I’ve been exploring the idea of processes, users, containers and VMs as various expressions of an underlying isolation mechanism.

I also recently wrote about the idea of a file system that implemented directories as recursive mounts[#].

Combining these ideas, together with the idea of unikernels, I’ve come to the idea of “ProcOS.”

A unikernel is the minimum possible operating system that gets you from bare metal to a single running process. Unlike a traditional operating system, it doesn’t have any multiplexing features (scheduler, etc.), so it can only run one program at a time.

“ProcOS” is the unikernel’s complement: it is just a process that runs other processes. It’s a pure multiplexer, with no hardware support. It’s an OS that runs as a regular process on a traditional OS, a unikernel, or–get this–itself.

All ProcOS can do is run processes. Users and containers are just recursive instances of ProcOS.

So for example, let’s say you’re running ProcOS on a unikernel. You turn on the computer, and the unikernel loads. It starts running the root ProcOS. It is configured to spawn a login process, which lets users log into the system.

When a user logs in, the login process uses a special message to tell the root process to spawn a user process for that user. The user process contains the desktop environment or whatever. Anything the user does runs within their process.

One cool thing about the ProcOS idea is that it can be quite portable. You can run it in a VM with a unikernel, or you can run it directly on top of another OS as a regular process. This makes it very clear the overhead that is being removed: the VM and the unikernel (including all drivers) just evaporate.

Ultimately, how practical is this idea? Well, if you were to build a secure multiplexer, this is probably the way you’d want to build it, so that it could be as simple (meaning reliable) and versatile as possible.