[Cryptography] Swap space (Re: It's all K&R's fault)

[Nemo]

Peter Gutmann <pgut001 at cs.auckland.ac.nz> writes:

> Nemo <nemo at self-evident.org> writes:
>
>>Well, Windows does not use fork()+exec(); it uses spawn() and its variants.
>>Hence it avoids the whole vfork() / "memory overcommit" mess.
>
> Aren't many fork()s now pretty close to vfork(), via COW?

Both Jerry and Tom have given good replies. Here is mine.

As Jerry mentioned, the issue is *virtual* memory (VM). Both the
original process and the fork-ed child have a full copy of the virtual
address space. You either (a) have sufficient RAM+swap to back all of
the writable VM or (b) fork() will fail or (c) you are Linux and have
vm.overcommit_memory enabled.

That last is the default on at least some Linux distributions, and it
means a process can get killed simply because an unrelated process
decides to write to its own _aleady-allocated_ memory. A truly lovely
failure mode, as a quick search for "oom-killer" will demonstrate.

As for vfork()... Yes, on Linux, it is no faster than fork(). But its
original purpose was not just speed.

http://pubs.opengroup.org/onlinepubs/7908799/xsh/vfork.html

(I say "was" because vfork() has since been removed from POSIX, probably
at the same time posix_spawn() appeared.)

vfork() traditionally suspends the parent process until the child calls
exec(), and the child is supposed to do pretty much nothing other than
call exec().

That is, the purpose of vfork() was to let you implement spawn(). (Prior
to Linux, no O/S even considered the "overcommit_memory" approach
because, let's face it, it's idiotic.)

 - Nemo
   https://self-evident.org/