Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on March 15, 2021 3:21 am wrote:
> anon2 (anon.delete@this.anon.com) on March 15, 2021 1:58 am wrote:
> > But when you step back and think about things a bit more generally and not just myopically at the kernel,
> > it's much less of a surprise that it doesn't work well -- would anybody think a "microuserspace" is
> > a good idea? glibc broken up into dozens of services running as threads, every application in the system
> > making IPC requests to the memory allocator server for malloc and free, to the string server for memcpy
> > or strlen, to the file server for fopen/fclose, etc.?
>
> Sandboxed applications work pretty much that way. They don't remote calls to strlen() but anything
> doing I/O must happen somewhere else together with the vast majority of syscalls. Depending on
> what you're doing some of that will be passed on to the kernel after filtering and sometimes
> they'll be implemented directly in userspace. So yeah, "microuserspace" is actually a good idea
> for certain domains.

Sandboxed applications in general do not work that way at all. Containers, cgroups, namespaces etc on Linux for example do no such thing, so it is entirely implementation specific. In this case the kernel isolates various resources inline in system calls, no IPC or message passing to be seen at all.

> Our world is complicated, there's no one-size-fits-all solutions.