Hello everyone!

Recently, I've researching the vfork() system call on Linux, that is similar to fork(), but suspends the calling thread and lets the child process use the parent process memory instead of copying it (or copying-on-write). When a child process performs an execve(), exit or is killed with a signal, the parent process resumes in vfork() call. This is faster than fork(), but may be dangerous to use with high-level languages, therefore, I wonder, does the following code snippet use vfork() correctly?

This code first prepares the execve() arguments, then uses the syscall instruction to invoke the vfork() syscall. If the rax register contains the value 0, it performs execve() system calls (and exits using the ud2 instruction in case of failure). In this case, the "vforked" child does not leave the inline asm block, so the "vfork() returns twice" problem shouldn't affect the Rust code. The vfork() spawning may result in better performance, but the disadvantage for me is that the ability to prepare the environment for the new process is limit (as far as I understand, if I need to replace stdin/stdout/stderr with dup2(), I also have to do it with inline asm).

I'm on Linux x86_64, syscall 58 is vfork(), syscall 59 is execve().

3 posts - 2 participants

Read full topic