|
|
Log in / Subscribe / Register

Smelling blood in the water,

Smelling blood in the water,

Posted Aug 13, 2026 9:21 UTC (Thu) by ksandstr (guest, #60862)
In reply to: The _one_ thing I'd like to see even in a microkernel by chris_se
Parent article: The beginning of a process-builder API

>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.


to post comments


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds