A fork() in the road • Hacker News Board

Re: A fork() in the road

#181

Post by eesmith » Fri, Apr 12, 2019, 1:44 AM UTC

cryptonector wrote: post #179

Dylan16807 wrote: post #162

Earlier quoted context omitted.

Easy to deal with by not applying privileges until the parent is done tinkering and hits start.

I don't see how. The privilege elevation mechanism cannot apply to an already-running process, since then there will be a way to subvert the process. Now, the better answer to that is to have nothing like a set-uid mechanism, which would be nice, for sure. But just how much violence are we to do to the Unix model, and when are we expected to finish this? It's not like Linux can be abandoned -- for better or worse, Li…

The paper suggests:

> a new process starts as an empty address space, and an advanced user may manipulate it in a piecemeal fashion, populating its address-space and kernel context prior to execution, without needing to clone the parent nor run code in the context of the child. ExOS [43] implemented fork in user-mode atop such a primitive. Retrofitting cross-process APIs into Unix seems at first glance challenging, but may also be productive for future research.

Re: A fork() in the road

#182

Post by a1369209993 » Fri, Apr 12, 2019, 6:24 AM UTC

cryptonector wrote: post #180

a1369209993 wrote: post #167

Earlier quoted context omitted.

Specifically, you'd want to do something like: pid_t child = pfork(); for(int fd=0;fd (Y'know, this looks kind of familiar...)

vfork() is the right tool. I dunno what semantics you have in mind for p_execve().

(See man (2)execve.)

  int p_execve(pid_t target,char* filename,
               char** argv,char** envp);

Executes a new program, specified by filename, in the context of the specified process. On success, the text, data, bss, and stack of the process specified by target are overwritten by that of the program loaded.

A target of zero specifies the current process, so p_execve(0,file,argv,envp) is equivalent to execve(file,argv,envp).

BUGS

We should probably require some kind of permission check before allowing the calling process to do this.

Re: A fork() in the road

#183

Post by kazinator » Sun, Apr 14, 2019, 3:09 AM UTC

afiori wrote: post #172

kazinator wrote: post #163

Earlier quoted context omitted.

The concept of "fork aware" didn't exist until threads. You could argue it's a thread problem. Remember, every library and OS functionality aso needs to be "thread aware" when threads are introduced. The pthread_atfork function can be thought about as "what do we do about thread and thread paraphernalia when we fork" rather than "what do we do about fork when we have threads". Even the close-on-exec flag race conditi…

> You could argue it's a thread problem But I explicitly want to not do it :) thread are obviously a good thing to have. > every library and OS functionality aso needs to be "thread aware" which is good, because differently from the case with fork thread aware libraries/OS help performance. Fork aware libraries/OS (in the case fork+exec) do not.

"Fork aware" is "thread aware". Hint: see the "pthread" substring in the identifier "pthread_atfork".

Note that this is necessary only because of the broken threading model that was retrofitted into Unix.

How it should work is that fork should clone the threads also. If a process with 17 threads forks, then the child has 17 threads. The thread IDs should be internal, so that all the pthread_t values in the parent space make sense in the child space and refer to the corresponding threads.

It's not fork's fault that the hacky thread design broke it. Fork is supposed to make a faithful replica of a process; of course if that principle is ignored in a major way (like, oops, where are the parent's threads?) then things are less than copacetic.

Threads also break the concept of a current working directory. If one thread makes a relative path access and another calls chdir, the result is a race condition.

Threads also break signals quite substantially; the integration of signal handling with threads is a mess.

Threads are not inherently a good thing to have; they are idiotic, in fact. Fork provides a disciplined form of threading that eliminates problems from the mutation of shared state, and provides fault isolation. It's much better to use forked processes instead of threads. Shared memory can be used for direct data structure access. With fork, you can create a shared anonymous mmap. This is then cloned into child processes as shared memory at the same virtual address.

Re: A fork() in the road

#184

Post by speedplane » Tue, Apr 16, 2019, 5:15 AM UTC

fanf2 wrote: post #73

speedplane wrote: post #35

Earlier quoted context omitted.

I used to work on a cross-platform project, and spent several weeks trying to figure out why our application ran significantly faster on linux than windows. One major culprit was process creation (another was file creation). I never really uncovered the true reason, but I suspect it had to do with the large number of DLLs that Windows would automatically link if you weren't very careful. Linux, of course, can also lo…

Anti-virus software makes process and file operations a lot slower.

> Anti-virus software makes process and file operations a lot slower.

It was a long time ago (~2006), and I honestly can't remember, but I feel like turning off anti-virus (and also backups, software updaters, and any other resident software) would have been one of the first things I would have checked. There was definitely something more fundamental going on.