[openssl-dev] Self-initialization of locking/threadid callbacks and auto-detection of features

[Florian Weimer]

On 06/15/2015 06:02 PM, Nico Williams wrote:
> On Thu, Jun 11, 2015 at 10:41:58AM +0200, Florian Weimer wrote:
>> Detecting things in libcrypto is very difficult on GNU/Linux due to the
>> way dynamic linking works.
> 
> Details?

Detection based on weak symbols can break due to linking order (if the
main executable is not linked against libpthread).  Merely linking
against libpthread, without ever creating any threads, is also not an
indicator of thread usage (libcrypto, for instance, currently does this
unconditionally).

> Perhaps OpenSSL should have several configuration flavors for Linux
> then.  If you want to statically link a non-threaded program with
> OpenSSL, then you should use the libpthread static link meant for it.

I have not considered the static linking case at all, to be honest.  It
should be used only very rarely.  If the lack of stubs is a problem for
static linking, glibc could be enhanced to provide them in a separate
archive.

> A workaound for libraries may be to use a private copy (as if by static
> linking) of OpenSSL with distinct SONAME/symbols and initialize that
> copy properly.  This is generally safe (we've tried it) but also a bit
> troublesome.  On the plus side this means that ABI incompatibilities
> betwee OpenSSL releases become a non-issue.

We can't do that because too much would need to be recompiled and
relinked for updates.

> Or indeed, libpthread should move into libc (which I gather would take a
> long time and is beyond what we can do here).

See my offer to add more stubs as needed.

> (Moving the implementation of a library to another requires support for
> shared object "filters", at least on Solaris, so that dynamically-linked
> dependents of libpthread and such will find the symbols they need there,
> though the RTLD knows to go look in the object they moved to.  We say
> that libpthread is a filter of libc because only the pthread-related
> symbols of libc appear in libpthread.  IIUC the Linux RTLD does not
> support filters.)

If I understand you correctly, we emulate them with IFUNCs in glibc.
There is no additional indirection at run time, calls go directly
through the libc implementation even if it is called through the
libpthread symbol.

>> Linking -lpthread has a real performance hit for unthreaded
>> applications, so core libraries should avoid it.
> 
> It shouldn't.

We can get rid of the performance overhead for single-threaded case, but
it's a multi-year effort, and we haven't even started.

What you as a library author can do: do not link against libpthread.
Most functionality you might need is available from libc proper, and
where it is not, ask for advice on the libc-help list.

> In any case, the initialization problems when OpenSSL is used by
> *libraries* are simply unacceptable.

Right.

-- 
Florian Weimer / Red Hat Product Security