Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Sep 2018 13:38:50 -0500
From:      Benjamin Kaduk <bjkfbsd@gmail.com>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        svn-src-projects@freebsd.org, src-committers <src-committers@freebsd.org>,  John Baldwin <jhb@freebsd.org>, jkim@freebsd.org
Subject:   Re: svn commit: r338816 - in projects/openssl111: secure/lib/libcrypto share/mk
Message-ID:  <CAJ5_RoA8GtCEupmneDpywUznB7SAhvgF-Y2Lm%2Bs58pP7hoisLg@mail.gmail.com>
In-Reply-To: <08a628fe-e640-7804-7c54-de9fdc407c7d@FreeBSD.org>
References:  <201809200020.w8K0K45h000526@repo.freebsd.org> <20180920100939.GU3161@kib.kiev.ua> <CAJ5_RoBnqMwb=9uZrsC%2Bf3p1X5PWrKY8A=RJVNVujmC=VkzWsA@mail.gmail.com> <20180920131952.GZ3161@kib.kiev.ua> <08a628fe-e640-7804-7c54-de9fdc407c7d@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 20, 2018 at 12:41 PM Jung-uk Kim <jkim@freebsd.org> wrote:

> On 18. 9. 20., Konstantin Belousov wrote:
> > On Thu, Sep 20, 2018 at 08:16:02AM -0500, Benjamin Kaduk wrote:
> >> On Thu, Sep 20, 2018 at 5:10 AM Konstantin Belousov <
> kostikbel@gmail.com>
> >> wrote:
> >>
> >>> On Thu, Sep 20, 2018 at 12:20:04AM +0000, Jung-uk Kim wrote:
> >>>> Author: jkim
> >>>> Date: Thu Sep 20 00:20:04 2018
> >>>> New Revision: 338816
> >>>> URL: https://svnweb.freebsd.org/changeset/base/338816
> >>>>
> >>>> Log:
> >>>>   Link libcrypto with pthread.
> >>> Why ?
> >>>
> >>>
> >> It uses pthread_once and pthread locks.
> > So what ?  libc provides the stubs.
>
> Historically, OpenSSL was okay without pthread because native
> implementation wasn't provided and users had to provide native callback
> functions instead.
>
> https://www.openssl.org/docs/man1.0.2/crypto/threads.html
>
> In fact, "objdump -T /lib/libcrypto.so.8 | grep pthread_" returns
> nothing.  dwmalone discovered it and committed r127643 about 14 years ago.
>
> https://svnweb.freebsd.org/changeset/base/127643
>
> Now OpenSSL 1.1 actually uses POSIX pthread.  Please see the blog post
> for the rationale:
>
> https://www.openssl.org/blog/blog/2017/02/21/threads/
>
> Unfortunately, our stubs are not enough or broken somehow, i.e., some
> functions malfunction without pthread.
>
> FYI, OpenSSL 1.1.1 requires the following functions now:
>
> pthread_atfork(3)
> pthread_equal(3)
> pthread_getspecific(3)
> pthread_key_create(3)
> pthread_key_delete(3)
> pthread_once(3)
> pthread_rwlock_destroy(3)
> pthread_rwlock_init(3)
> pthread_rwlock_rdlock(3)
> pthread_rwlock_unlock(3)
> pthread_rwlock_wrlock(3)
> pthread_self(3)
> pthread_setspecific(3)
>
> If you have a functional patch for libc stubs, I'll be more than happy
> to revert it.
>
>
kib's reply is taking a long time to arrive, so let me just paste in the
relevant bits from another source:

%   From the list, I think the possible candidates are
%              pthread_once(),
%               pthread_atfork(),
%               pthread_key*/setspecific().
%       Other should work with stubs as is, key/setspecific currently just
fail.
%       pthread_once() and pthread_atfork() silently do nothing, is it your
%       problem ?
%
%       The story about pthread_once() is known, there are some high-profile
%       programs depending on pthread_once() failing in single-threaded
environment
%       (AKA gcc).

pthread_atfork() is just used to increment a generation counter for the
CSPRNG in the child, but
pthread_once() and pthread_key*/setspecific() are heavily used for
important functionality.
The list of ciphers, digests, error strings, etc., are initialized in
pthread_once().
pthread_setspecific() is used to provide per-thread DRBG instances (so the
default RNG
seems likely to fail if that function is a noop stub).  In short, openssl
is now a heavy pthread
consumer (on Unix).

-Ben



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ5_RoA8GtCEupmneDpywUznB7SAhvgF-Y2Lm%2Bs58pP7hoisLg>