Use vfork() instead of fork() where possible

[dwmw2]

The official PKCS#11 Users Guide suggests that on fork(), a child process should immediately call the C_Initialize() method of any loaded PKCS#11 providers, to ensure that there is no confusion about their state being carried over from the parent, in which the provider is still active.

This advice is a little confusing, because it's entirely pointless when you are really just doing a fork-and-exec. There's no point in doing anything in the child process between the fork() and the execve().

And it causes more problems than it solves, because some provider modules don't cope with it. Including the OpenSC module which is common on Linux and other open source platforms for most smartcard access, and the p11-kit-proxy module which is also common (and which we now load by default).

Nevertheless, this is the behaviour of the pkcs11-helper library that OpenVPN uses.

The offending modules are broken and should get fixed, of course. However, if even two of the common open source modules can suffer issues, what do we expect from the various closed-source PKCS#11 provider modules? If they only really test hard on Windows, they're certainly never going to encounter esoteric issues with behaviour on fork() which doesn't even exist there.

In accordance with Jon Postel's ​Robustness Principle we should be liberal in what we accept, and conservative in what we send.

It would be trivial to work around a number of these issues by using vfork() instead of fork() in the case where we are doing a simple fork-and-exec, as in openvpn_execve(). In my opinion, we should do so. OpenVPN exists as a VPN solution and should do its best to work in all environments, rather than being a torture test for esoteric aspects of spec compliance.

I posted at patch at ​http://sourceforge.net/p/openvpn/mailman/message/34076444/ in which I incorrectly claimed it should solve ticket #538. It doesn't, since that's a different issue. But we should apply this patch anyway.

[dwmw2]

Note that even one of the most ubiquitous PKCS#11 modules, the NSS 'soft token', doesn't seem to support having C_Initialize() called in the child process after a fork, if I'm reading ​Mozilla bug #331096 (especially comment 28) correctly.