3 ms·

> The proper semantics for starting a new process is.. :) Ah.. I guess when "I was younger" (TM) I was also so dogmatic on most things computer-related. Anywa

by jagrsw 5y ago

> The proper semantics for starting a new process is.. :) Ah.. I guess when "I was younger" (TM) I was also so dogmatic on most things computer-related. Anyways, when we need to do something a bit more complex than equivalent of system(), then it quickly becomes evident, that in many cases we need to prepare ourselves for the future execve(). Here's the list of syscalls/c-funcs, which are called in two random projects I maintain, after fork() and before execve() (or execveat() or fexecve()). alarm(0); /* disable alarms */ setenv(); /* A couple of required envs, like MALLOC_PERTURB_ or MALLOC_PERTURB_ */ prctl(PR_SET_DUMPABLE, 1) /* regarding ptrace()-attach */ syscall(__NR_personality, ADDR_NO_RANDOMIZE); /* disable ASLR for debugging, if needed */ socketpair() /* reliable execve success detection, some form of witchcraft */ setpriority() prctl(PR_SET_PDEATHSIG, SIGKILL); /* die upon parents death */ setrlimit(); /* set of reset rlimits */ lseek(fd, 0, SEEK_SET); /* rewind input file for this specific subprocess */ /* prepare arguments (argv) for execve dynamically */ sysconf(_SC_NPROCESSORS_ONLN); pthread_setaffinity_np(); /* pin subprocess to a list of CPUs */ /* LOTS of functions here if we wanted to use net/process/mount namespacing e.g: assigning IP adddresses to interfaces creating custom views of the filesystem tree modifying capability sets */ open("/proc/self/oom_score_adj"), write(), close(); /* adjustment of oom score */ open("/proc/self/fd", O_DIRECTORY); getdents(); fcntl(F_GETFD); fcntl(F_SETFD, FD_CLOEXEC); close() /* closing fds upon exec */ setsid(); /* new session */ sigprocmask(empty_set); /* reset signal mask */ open("/dev/null"); dup2(null, 0..1); /* close fd 0,1,2 */ prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER); /* application of sandboxing */ and finally execv() or execveat() Granted, the projects are maintain are probably more on the heavy side of things, when it comes to process manipulation, before execve, but putting all of that in some control structure, would be down to impossible for me. Such structure would have to be so extensible, that it'd have to be some form of VM I guess effectively. So.. having ability to simply call a couple of syscalls from the context of a regular new process, and before execve() is quite good here. Sure.. maybe we should have some simple form of fork/execv, for those who want to call system() or popen() and not hit the memory overcommit related crashes. But not as a replacement, rather a new syscall. Even so, debugging while a process creation/execution failed would be madness, given that you simply would get EINVAL, and the failure could be related to any of dozen parameters in a process creation control structure.

Koromix 5y ago
I think that in a proper API, we could have: int process_handle = spawn("/bin/true", SP_PAUSED); // create process but don't execute, and return a handle // most API would take a process handle, thus you could do stuff (such as prctl) on the new process unpause(process_handle); There's a bit of a move in this direction in the Linux API with the PIDFD stuff.
- jagrsw 5y ago
  Sounds reasonable. I guess most process controlling syscalls (ptrace, prctl, seccomp, bpf, remotely operating on pid's FDs, setsid, signal masks) will have to be replaced to be able to operate on remote process or on a fd, but yeah, this can work, potentially.
foxfluff 5y ago
If it's all syscalls (i.e. no libraries messing with hidden state) and you don't mess with parent's memory, you might be able to do this all with clone(CLONE_VM|CLONE_VFORK) instead of fork(). This is what musl uses to implement posix_spawn().
- jagrsw 5y ago
  I think setenv() will use malloc() (it might use mutexes), same for error printing if it uses printf() or perror(). Also, this is all mess if fork() is called from a multi-threaded context. Esp. via clone(), which up to certain glibc() version cached getpid() result, and returned parent'd PID in the child (for performance reasons of course ;).

by jagrsw 5y ago

Koromix 5y ago

I think that in a proper API, we could have: int process_handle = spawn("/bin/true", SP_PAUSED); // create process but don't execute, and return a handle // most API would take a process handle, thus you could do stuff (such as prctl) on the new process unpause(process_handle); There's a bit of a move in this direction in the Linux API with the PIDFD stuff.

jagrsw 5y ago
Sounds reasonable. I guess most process controlling syscalls (ptrace, prctl, seccomp, bpf, remotely operating on pid's FDs, setsid, signal masks) will have to be replaced to be able to operate on remote process or on a fd, but yeah, this can work, potentially.

foxfluff 5y ago

If it's all syscalls (i.e. no libraries messing with hidden state) and you don't mess with parent's memory, you might be able to do this all with clone(CLONE_VM|CLONE_VFORK) instead of fork(). This is what musl uses to implement posix_spawn().

jagrsw 5y ago
I think setenv() will use malloc() (it might use mutexes), same for error printing if it uses printf() or perror(). Also, this is all mess if fork() is called from a multi-threaded context. Esp. via clone(), which up to certain glibc() version cached getpid() result, and returned parent'd PID in the child (for performance reasons of course ;).