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

[Nemo]

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

> Tom Mitchell <mitch at niftyegg.com> writes:
>
>>Swap is still needed, the size is open to discussion.
>>
>>The reason is the fork(); exec() pair. 
>
> That's obviously a Unix-specific thing, because Windows will run with zero
> swap quite happily.  I don't think I've ever used a swapfile under any
> NT-kernel version of Windows.

Well, Windows does not use fork()+exec(); it uses spawn() and its
variants. Hence it avoids the whole vfork() / "memory overcommit" mess.

As a quick reminder, the mess is that fork() clones the entire virtual
address space. So if a huge process is trying to start a tiny
sub-process, the system will need twice the VM (following the fork()),
but only momentarily (until the exec()). A spawn() interface, combining
fork()+exec() into on fell swoop, does not suffer from this problem.

POSIX actually added a spawn function
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn.html),
but too late and with a bloated interface. I am pretty sure I have
literally never seen it used.

Also, a little bit of swap is nice if you have lots of little processes
in mostly doing nothing in the background, which you almost certainly
do.

Encrypted swap is great for servers and always-on desktops, and
obviously it should be the default in such environments. But it wreaks
havoc on suspend/resume, which is built on top of swap (at least on
Linux the last time I checked). This strikes me as tricky, though not
impossible, to solve... I do not know whether anybody has.

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