Re: Shouldn't no-pinshared be the default?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux