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@xxxxxxxxxxx>
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
