Shouldn't no-pinshared be the default?

[Jakob Bohm]

On 05/03/2019 14:47, Tomas Mraz wrote:
> On Tue, 2019-03-05 at 14:16 +0100, Yann Ylavic wrote:
>> On Tue, Mar 5, 2019 at 12:51 PM Matt Caswell <matt at openssl.org>
>> wrote:
>>> 2) The no-pinshared option does not appear in 1.1.1 or 1.1.1a. It
>>> first appears
>>> in 1.1.1b. Backporting the option was considered ok. But changing
>>> the default
>>> mid-series is probably not a good idea.
>>>
>>> Changing the default could be considered for 3.0.
>> Yes please, as it stands the 1.1 series is unloadable on the most
>> used
>> openssl libraries, distros'. I find this a bit unfortunate, and more
>> #ifdef-ery to come (though I'd like the OPENSSL_INIT_[NO_]UNLOAD one
>> :) ).
> But is it in reality at all possible to explicitly unload OpenSSL?
> You're talking here about mod_ssl but what if the OpenSSL is loaded not
> just by mod_ssl but by other shared library loaded into the httpd
> process - for example libkrb5 or libldap. Then you can see what
> disaster can happen if mod_ssl on unload explicitly calls
> OpenSSL_cleanup().
>
> The explicit cleanup is thus simply a no-go in distro-wide use of
> OpenSSL.
>

On any system with a shared library concept (perhaps except some
historic abominations), shared library unload reference counting
is already handled by the OS/loader.  Thus any shared library that
cleans itself up when actually unloaded by the OS should just work.

Unfortunately OpenSSL 1.1.x chose to deliberately prevent itself
from being unloaded instead of making an internal abstraction for
the 3 unload scenarios common to all shared library systems:

A. Process is exiting, shared library is being unloaded along
   with the rest of the process.
      A few resources (such as network sockets and C FILE* objects)
   should be graciously cleaned up, memory will be freed unless the
   OS is "no-MMU" style (Linux-noMMU, Win32s).  Any threads still
   accessing the library will exit very soon too.

B. Shared library is being unloaded before process exit was
   requested, all library resources must be cleaned up to avoid
   becoming memory leaks. No clients are trying to use the
   library, but any long-running library APIs might not have
   returned (due to application mistakes or lack of abort APIs).
Threads still accessing the library need to synchronize
   their orderly return to callers outside the shared library.
    If OS serialization allows, the library needs to delay
   completion of the unload handler until the threads have
   left the library.

C. A client application requests cleanup manually.  Shared
   libraries accessed by multiple in-process "applications"
   (Your example above) will need to sometimes ignore such
   requests, static libraries can assume only one caller and
   should do the requested cleanup.

About 25 years ago I struggled with another library that did
the same kind of unload-blocking that OpenSSL 1.1.x does.  It
was sad to see a big project like OpenSSL repeat that mistake.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded