The exec system call conceptually creates a new process based on a set of predefined specifications. The memory image of the new process is clean, files not marked close on exec are maintained open in the new process, and signals not set to ignore are reset to default.
Like other services in K42, exec is implemented primarily in user space. Given the above model for loading, a K42 process may be considered an exec.so image that loads or overlays Linux executables when asked to exec. With this model, the same K42 process containing exec.so, can, when asked to perform an exec, unload the Linux executable and any shared libraries it has loaded, re-initialize the appropriate aspects of the Linux personality, and load the new Linux executable. In the common case, exec can be performed entirely in user space.
It is not possible to use the overlay model if the exec is for a setuid program (or for clone or native K42 processes). Because the old program could have stored permissions not granted to the new process anywhere in its memory image, we have a privileged server create a clean process, and copy the necessary state. This server uses the underlying K42 mechanisms used by fork.
The overlay strategy for implementing exec permits us to efficiently handle most Linux applications and perform the exec in user space. For the cases where we can not use the overlay strategy, most operations are still performed in user space.