A critique of fork() from microsoft is disappointing since these systems abstractions aren’t universal truths and can only be judged meaningfully within the context of the cultures that created them.

I don’t think an ad hominem is a very helpful start to a post, but I partially agree with the second part of this sentence. Systems abstractions are not universal truths but their value is universal within the context of the hardware on which they need to run. This changes over time and across market segments (abstractions for rack-scale computing don’t work well on embedded systems with significantly less than 1 MiB of RAM, for example).

I work for Microsoft Research, but I held the opinion that fork is a terrible abstraction for at least 10, probably closer to 15, years before I joined Microsoft and it has absolutely nothing to do with Windows or the VMS / Mainframe culture. Prior to joining Microsoft I served two terms on the FreeBSD Core Team, so I hope that establishes my credentials as someone who understands the ‘UNIX culture’. I’ve also worked on a port of Linux to an environment with no MMU that aimed to run existing Linux software.

These folks are not the only people to object to fork. Mothy has been complaining about it for years and there’s a huge section in the UNIX Haters’ Handbook (1994) about it.

It’s easy to understand fork if you understand the hardware context in which it was created, which has nothing to do with the culture of the programmers. On PDP machines, you had one process executing in core memory and when you did a context switch you wrote it out to drum (or similar) memory and read another process in. On this hardware, fork is an obvious abstraction: you write out the process and then create a new copy of the kernel data structures. You now have a copy of the process that you’ve just written out sitting in memory for free, doing anything other than fork is more work.

The fork abstraction started showing its age quite early. Once UNIX ran on systems with MMUs, you could keep two or more processes in core (a term that remains, even though core memory is a historical curiosity) at a time and context switching became just a matter of updating the segment descriptor table (or pointing to a different one). At this point, fork required copying the entire process and was expensive. With paged MMUs, it became a bit cheaper as you could ‘just’ mark every page as copy-on-write, but that complicated the VM subsystem. Two other advances made it even worse:

• Threads were added to UNIX. Only the calling thread is copied by fork, so you many end up with locks held by other threads that you can’t unlock (especially if they’re error-checking pthread mutexes and abort if you try to unlock them from a thread that doesn’t own them), so if you want to actually use the forked child rather than just call execve then you need every library that creates threads to be aware of this and release locks then recreate its threads in the child, which is basically impossible to get right.
• SMP came along and now updating page tables required cross-core synchronisation. This is particularly bad on x86 (except AMD Milan) or RISC-V, where you need an IPI to do TLB invalidates, so the cost of fork scales badly with both the size of the process and the number of cores. Ona system with 128 cores and 1TiB of RAM, fork does a phenomenal amount of work to create a virtual memory environment that often lives for less than 1ms and which doesn’t touch more than a couple of pages.

Awareness of the pain of fork is not new. The vfork system call was introduced somewhere around 2.9BSD or 3BSD, putting it in or before 1980. The FreeBSD 1.0 (1992) man page says that vfork will be removed in a future release. In FreeBSD 10 (2014), we quietly removed that comment because vfork remains the best way of creating a child process on *NIX, in spite of being incredibly hard to use correctly (it can, at least, be used to create APIs that can be used easily).

There are basically two ways of creating a process that don’t suffer from the problems of fork.

The first (which is the direction VMS / NT went) is conceptually cleaner. You have a kernel API that creates a new empty process and returns a capability to it (which Windows calls a handle). You can use this capability to do things like map files or anonymous memory objects into the process, write initial state into that memory (e.g. stack contents), inject threads, and so on. The big disadvantage of this is that it requires remote versions of all of your APIs. On *NIX, mmap is how you modify your process’s address space but it doesn’t let you modify another process’s address space. Similarly, pthread_create lets you create a thread but it doesn’t let you create a thread in another process.

In most *NIX systems, there’s a separation of concerns around threading where the kernel doesn’t know much about the thread other than that it is a schedulable entity and it has a register file that needs to be context switched when it is [de]scheduled. The threading library builds the pthread abstractions in userspace and the same kernel can run multiple different threading libraries. That kind of design makes it a bit more difficult to implement this model because even if there were a remote form of mmap and newthr / clone + CLONE_THREAD, the userspace threading library would have to be restructured to use these to inject remote threads and do things like copy TLS segments from the binary. This is simpler with Windows where there is precisely one threading library but that simplicity comes at the cost of flexibility.

Designing these APIs to avoid confused deputy vulnerabilities is also nontrivial. If I create a new process owned by a different user, or with reduced privileges in some other way, then I need to ensure that any OS handles that I’ve created for the child were either with the reduced rights or were intentionally created with elevated privileges.

The other approach is embodied by vfork. You let a process run with a different set of kernel state other than the memory mapping and then launch the new process once it’s modified the state that it wants to. This means that you don’t need remote versions of open, close, socket, and so on, because you’re setting up the kernel state using the local versions of the calls. The BSD incarnation of this, via vfork is a bit limited in that the only way to end a vfork context is via execve, which creates a completely new memory map, so you can’t use this to set up shared memory regions between the parent and child. You also can’t create threads in the child. These things could be built with cooperation from the run-time linker, but they aren’t in any *NIX systems that I’m aware of.

The advantage of vfork is that there’s a clear separation between things done with the parent’s rights and things done with the child’s rights. You can do things like call setuid or cap_enter in the vfork context and then anything done after this is done with the child’s permissions context. Copying the file descriptor table can still be quite costly, especially given that most child processes immediately call closefrom to close most of them after putting the small number that they want to explicitly inherit in the right places in the file descriptor table.

The big downside of fork is that it can affect process state. For example, if you accidentally call malloc in the vfork context and then don’t free the memory, it’s leaked in the parent. This isn’t so bad with C++ and RAII, where you can allocate space on the stack for the arguments to execve and then do everything else in a nested block so that destructors all run before the execve call, but it’s painful to use in C, which is the language that UNIX was co-designed with. It’s probably fine in a garbage-collected language, as long as you don’t accidentally acquire any locks in the vfork context.

Both of these approaches work well with any kind of process-isolation technology and even without an MMU. In the CHERI project, we’ve extended FreeBSD with a coexecve system call that creates a new OS process within the same address space as the parent, isolated using CHERI capabilities. This works well with vfork (we added a sysctl that turns any execve in a vfork context into a coexecve and most things seem to just work) but would be impossible to support with fork.

TL;DR: The fact that fork is a bad design is fairly uncontroversial among systems researchers and has been well-known to UNIX kernel developers since before I was born.

This isn’t a critique of fork() from Microsoft – it’s a critique of fork() of four operating systems researchers, one of whom is affiliated by Microsoft. Would your comment be different if the submitter used a different URL to the paper, like this one (ETH is an university in Switzerland where the fourth author works): https://people.inf.ethz.ch/troscoe/pubs/hotos_fork.pdf

The paper discusses how fork came to be, providing insights what the small community though was good at the time.

It’s also a style that differs wildly from a lot of real world Linux/modern *nix usage (including most cases that are meaningfully sensitive to process spawning overhead). The authors do acknowledge (in section 3) that this was a reasonable design for its original use case in its original context. But that was a context with different hardware, different available libraries/other os abstractions, different demands from user level programs, etc.

But this also isn’t otherwise a lazy internet rant; it’s a pretty through exploration of the topic, including alternatives (they point out that rfork()/clone() solves some problems, but not others). I find it disappointing to see a pretty thoughtful paper dismissed with “bah, Microsoft.”

Which, fwiw, only even applies to one of the authors. Jonathan Appavoo was my advisor as a grad student and I later worked for Orran Krieger for a couple years; I can attest that they are not “Microsoft people.”

I just want to note that this isn’t only a Microsoft “extinguish” thing. OS research in recent years is very Unix (even primarily Linux)-centric, seeming like we have forgotten other OSes than Linux. Mothy addressed this at this years’ OSDI as well. I’m not saying that Microsoft didn’t have any sneaky intentions with this paper, but there is a valid critique here.