[Cryptography] WIPEONFORK in Linux 4.14

[Nico Williams]

On Tue, Nov 28, 2017 at 07:54:14AM +0000, Darren Moffat wrote:
> Is the use case for when we are purposely creating a multi-process system,
> by using fork/vfork/clone, where all the processes are running the same
> code?
>
> Or is it about fork/exec? In this case an in kernel posix_spawn() avoids
> many of the issues. Particularly those I've been involved with where the
> JVM was using native crypto libraries and we were depending first on
> getpid() and then on stacked pthread_atfork() handlers.

The case I was involved with involved making fork()/exec() of child
processes faster.  Normally one would use vfork() for this, but one
could imagine something closer to pthread_create() where if the "child"
thread exec()s then it creates a new process without replacing the
parent -- an "async vfork()" of sorts that is made possible by _not_
sharing a stack between the parent and child.

See: https://github.com/famzah/popen-noshell/issues?q=is%3Aissue+is%3Aclosed
and: https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c18d7db234

This *could* be done on Linux using clone(2), but it can't be done if
you'd call (on the child side) *any* C library functions that refer to
errno.  The reason is that you have to setup TLS (thread-local storage)
for the child, but a) the details of how to do this are NOT documented,
b) there are interactions with private internals of the chosen libc, so
you can't make this work unless you implement it _inside_ a C library.

Thus, some non-standard uses of clone(2) via syscall(2) are simply not
workable unless you're making use of them in the C library itself.

So I tend to think that anyone using clone(2) via syscall(2) gets what
they deserve.

But it's true that pthread_atfork() is a user-land mechanism, and
anyways refers to fork() but not esoteric uses of clone(2), and that a
kernel-land fork-safety mechanism would necessarily be more robust in
that you couldn't disable it no matter what you do in user-land.

(Well, I'm stretching things: one could always remap the wipe-on-fork
mappings as not wipe-on-fork, but presumably one wouldn't do that.
There may be a need for some clone(2) calls via syscall(2), but there's
no need to remap wipe-on-fork memory as not.  Wipe-on-fork is reliable.)

This makes wipe-on-fork a reasonable mechanism.  There may be others,
naturally, but we only need one that works reliably and _portably_.

Nico
--