The _one_ thing I'd like to see even in a microkernel [LWN.net]

The _one_ thing I'd like to see even in a microkernel

Posted Aug 5, 2026 9:05 UTC (Wed) by chris_se (subscriber, #99706)
In reply to: Anything that can be userspace should be userspace by quotemstr
Parent article: The beginning of a process-builder API

> Imagine you had a special process-launch helper (say, a souped-up /usr/bin/env) that you could spawn, give process-building instructions, and, when done, let run? And this process would do all the environment configuration you wanted, then execve the final binary, reporting over an inherited pipe any errors in the setup process?

You'd still need an additional syscall to spawn that helper program. (Otherwise you'd do the current fork/execve dance anyway, and then a helper doesn't improve your situation.)

You'd need some form of IPC in order to get that process to do what you want, and that IPC has to be powerful enough to be able to transfer file descriptors from your process to that process. (One of the main things the proposed spawning API does is give the user control over which file descriptors are in the initial set of descriptors passed to the new program.)

The operation itself would not be atomic - while the helper program is running, you do already have a subprocess, but if execve happens to fail in that program, that process ends, and error handling becomes way harder for the main process (especially if you have multiple threads and another thread has a general wait() running). Sure, that situation is the same as currently, but when designing something new you'd want to improve upon the existing.

You have to rely on that helper program existing/working in the moment you want to create a process (unlike e.g. a shared library in userspace where starting your program doesn't start up if it's not available / broken), this makes this more error-prone.

Finally, you'd still construct the helper program first, which definitely is a performance hit has compared to immediately starting the requested program.

Even from a microkernel perspective, managing processes and memory management are _the_ two key features that a microkernel should provide in the kernel directly. I believe a specific "start a new process with the following resource configuration" functionality is _the_ one functionality that would belong in a microkernel, and not a userspace helper.

to post comments

Smelling blood in the water,

Posted Aug 13, 2026 9:21 UTC (Thu) by ksandstr (guest, #60862) [Link]

>Even from a microkernel perspective, managing processes and memory management are _the_ two key features that a microkernel should provide in the kernel directly. I believe a specific "start a new process with the following resource configuration" functionality is _the_ one functionality that would belong in a microkernel, and not a userspace helper.

Empirically false; on the contrary it's entirely feasible to do POSIX on top of a microkernel that knows neither process nor file. Such kernels[0] instead abstract address spaces, threads, memory mappings[1], and exception handling, with these being mediated from system level to lesser privilege by synchronous IPC that provides client atomicity. Process spawning external to the microkernel then configures the new process' pager (such as a systemwide memory server), and any filesystems implementing the files it maps, to define the new program; and this is the equivalent of calling an arbitrarily complex spawn67() over IPC. That extends to non-files such as sockets and the like.

This seems like a lot of hair splitting, but the kernel-to-system divide runs in the very definition of a microkernel. Nothing in that detail applies to monolithic kernels either: they enjoy a similar API freedom internally and so lack the gains from going usermode, but are weighed down by their POSIX externals if they went anyway.

As for solving file descriptor TOCTOU in a process with unruly threads (e.g. syscalls that started before the spawn() call) messing with open files during a running syscall, it's simple enough to retard spawn() first and then halt other threads for its duration at the point where they'd access any file. (mutexes would do in a pinch.) Lighter methods may be possible, but that one is a complete solution albeit on the petri dish scale.

[0] Where "kernel" is the supervisor component, "system" is privileged non-POSIX user mode, and "user" (or "app") is cat(1) inna terminal window, its loader, the terminal program, ..., and the horse they rode in on.
[1] And even that is more a matter of portability and security (i.e. defense in depth), where an alternative would allow privileged programs to writably map their own page tables and those of other programs. Such "exokernel" optimization is long dead.