The Design and Implementation of the Anykernel and Rump Kernels

178
Supporting fork()
Recall, the fork() system call creates a copy of the calling process which essentially
differs only by the process ID number. After forking, the child process shares the
parent’s file descriptor table and therefore it shares the rumpclient socket. A shared
connection cannot be used, since use of the same socket from multiple independent
processes will result in corrupt transmissions. Another connection must be initiated
by the child. However, as stated earlier, a new connection is treated like an initial
login and means that the child will not have access to the parent’s rump kernel
state, including file descriptors. Applications such as web servers and shell input
redirection depend on the behavior of file descriptors being correctly preserved over
fork.
We solve the issue by dividing forking into three phases. First, the forking process
informs the rump kernel that it is about to fork. The rump kernel does a fork of the
rump process context, generates a cookie and sends that to the client as a response.
Next, the client process calls the host’s fork routine. The parent returns immediately
to the caller. The newly created child establishes its own connection to the
rump kernel server. It uses the cookie to perform a handshake where it indicates
it wants to attach to the rump kernel process the parent forked off earlier. Only
then does the child return to the caller. Both host and rump process contexts retain
expected semantics over a host process fork. The client side fork() implementation
is illustrated in Figure 3.36. A hijacked fork call is a simple case of calling
rumpclient_fork().
Supporting execve()
The requirements of exec are the “opposite” of fork.
Instead of creating a new
process, the same rump process context must be preserved over a host’s exec call.