Toward race-free process signaling

Posted Dec 6, 2018 20:11 UTC (Thu) by nopsled (guest, #129072)
In reply to: Toward race-free process signaling by rweikusat2
Parent article: Toward race-free process signaling

I think there are plans to introduce a new variant of clone that has CLONE_NEW or so as an additional flag that returns a process descriptor (since clone has already run out of flags).

to post comments

Toward race-free process signaling

Posted Dec 6, 2018 20:28 UTC (Thu) by quotemstr (subscriber, #45331) [Link] (6 responses)

The next clone, instead of just having a bigger flag parameter, really should, instead, look something like this:

#define CLONE2_SHARE_VM (1<<0) /* VALUE is a bool: default to true */
#define CLONE2_OUTPUT_FD /* VALUE is an int*: on success, clone2 writes a procfd FD */
...

struct clone2_parameter {
void* value; /* In, in-out, or out depending on NAME */
int name; /* CLONE2_XXX; after the pointer for 32-bit ABI compat crap */
};

/* Make a new task (process or thread). The new process's properties are mumble.
clone2_parameters override these defaults. If multiple clone2 parameter structures
have the same NAME, the last one wins. Return child PID on success; on failure, -1 with errno set. */
int clone2(const struct clone2_parameter* parameters, int nparameters);

This way, we can create an interface as rich as we want, in an extensible way, without ever again having to make a new god damn process creation system call. It'd also let us implement a posix_spawn directly, without vfork.

Toward race-free process signaling

Posted Dec 8, 2018 5:51 UTC (Sat) by dw (subscriber, #12017) [Link] (5 responses)

I've been working on a deep dive into the history of process management on UNIX, and noticed all these kernel implementations of posix_spawn() popping up (NetBSD, OS X, Solaris). While their rationale is solid (avoiding huge pointless serializing VM copies), directly implementing posix_spawn() looks like a potential mistake, due to the perpetual incompleteness of that interface.

This led to thoughts about a compromise, and a potentially reasonable answer: something like a combined fork+exec, where the VM is not preserved and inherited FDs are explicitly specified. The target of the exec is a helper binary to implement the desired post-fork behavior. Configuration of the helper would be done e.g. over a pipe or a memfd.

If a new clone() variant is under discussion as described here, another option might be to address the VM problem by allowing the variant to specify memory regions preserved in the child. posix_spawn() only requires access to existing file descriptors and say, one page describing the new child configuration.

The point of both options is to keep that huge inflexible interface in userspace, and some system call that still provides all the performance benefit, for applications where posix_spawn() doesn't go far enough (e.g. changing security credentials or similar)

Toward race-free process signaling

Posted Dec 8, 2018 5:55 UTC (Sat) by dw (subscriber, #12017) [Link]

Forgot to mention, the biggest motivation for a userspace spawn may be the sheer size of an equivalent kernel implementation ;) https://github.com/SilkieDragon/xnu/blob/0a798f6738bc1db0...

Toward race-free process signaling

Posted Dec 8, 2018 6:00 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

I thought that one of the better ideas is to make all the relevant process-management functionality to accept an explicit process file descriptors. And then the final piece - ability to create a process in a "suspended" state.

Intermediary executables are just a crutch.

Toward race-free process signaling

Posted Dec 8, 2018 6:15 UTC (Sat) by dw (subscriber, #12017) [Link] (2 responses)

The trouble is that there is an almost unlimited set of fork() use cases that can't be addressed by posix_spawn(), and no sensible finite set of APIs can ever fully describe what was already possible post-fork. As a contrived example, creating a connected UNIX client socket attached to the new process stdio, where peercred accurately reflects the connecting process is the new process.

Toward race-free process signaling

Posted Dec 8, 2018 9:03 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> As a contrived example, creating a connected UNIX client socket attached to the new process stdio, where peercred accurately reflects the connecting process is the new process.
You still will be able to dup() sockets into the new process. I'm not sure how you would forge the peercred, though.

Toward race-free process signaling

Posted Dec 8, 2018 15:38 UTC (Sat) by dw (subscriber, #12017) [Link]

The question is not whether one contrived example has an incomplete solution in the proposed scheme, but whether even a reasonable subset of use cases could be catered for even when approaching something like 100% churn in the interface, implementation, locking requirements and security model for almost all existing system calls, without forcing users to resort to e.g. vfork or debugging APIs (which they may lack privilege to use) to fill the remaining gaps.

We don't need to answer it for ourselves, Windows had process handles since prehistory, where you find endless hacks like this to cope with their process creation API remaining incomplete after almost 30 years.