1OPENSSL-THREADS(7ossl)              OpenSSL             OPENSSL-THREADS(7ossl)


6       openssl-threads - Overview of thread safety in OpenSSL


9       In this man page, we use the term thread-safe to indicate that an
10       object or function can be used by multiple threads at the same time.
12       OpenSSL can be built with or without threads support. The most
13       important use of this support is so that OpenSSL itself can use a
14       single consistent API, as shown in "EXAMPLES" in
15       CRYPTO_THREAD_run_once(3).  Multi-platform applications can also use
16       this API.
18       In particular, being configured for threads support does not imply that
19       all OpenSSL objects are thread-safe.  To emphasize: most objects are
20       not safe for simultaneous use.  Exceptions to this should be documented
21       on the specific manual pages, and some general high-level guidance is
22       given here.
24       One major use of the OpenSSL thread API is to implement reference
25       counting.  Many objects within OpenSSL are reference-counted, so
26       resources are not released, until the last reference is removed.
27       References are often increased automatically (such as when an X509
28       certificate object is added into an X509_STORE trust store).  There is
29       often an object_up_ref() function that can be used to increase the
30       reference count.  Failure to match object_up_ref() calls with the right
31       number of object_free() calls is a common source of memory leaks when a
32       program exits.
34       Many objects have set and get API's to set attributes in the object.  A
35       "set0" passes ownership from the caller to the object and a "get0"
36       returns a pointer but the attribute ownership remains with the object
37       and a reference to it is returned.  A "set1" or "get1" function does
38       not change the ownership, but instead updates the attribute's reference
39       count so that the object is shared between the caller and the object;
40       the caller must free the returned attribute when finished.  Functions
41       that involve attributes that have reference counts themselves, but are
42       named with just "set" or "get" are historical; and the documentation
43       must state how the references are handled.  Get methods are often
44       thread-safe as long as the ownership requirements are met and shared
45       objects are not modified.  Set methods, or modifying shared objects,
46       are generally not thread-safe as discussed below.
48       Objects are thread-safe as long as the API's being invoked don't modify
49       the object; in this case the parameter is usually marked in the API as
50       "const".  Not all parameters are marked this way.  Note that a "const"
51       declaration does not mean immutable; for example X509_cmp(3) takes
52       pointers to "const" objects, but the implementation uses a C cast to
53       remove that so it can lock objects, generate and cache a DER encoding,
54       and so on.
56       Another instance of thread-safety is when updates to an object's
57       internal state, such as cached values, are done with locks.  One
58       example of this is the reference counting API's described above.
60       In all cases, however, it is generally not safe for one thread to
61       mutate an object, such as setting elements of a private or public key,
62       while another thread is using that object, such as verifying a
63       signature.
65       The same API's can usually be used simultaneously on different objects
66       without interference.  For example, two threads can calculate a
67       signature using two different EVP_PKEY_CTX objects.
69       For implicit global state or singletons, thread-safety depends on the
70       facility.  The CRYPTO_secure_malloc(3) and related API's have their own
71       lock, while CRYPTO_malloc(3) assumes the underlying platform allocation
72       will do any necessary locking.  Some API's, such as NCONF_load(3) and
73       related, or OBJ_create(3) do no locking at all; this can be considered
74       a bug.
76       A separate, although related, issue is modifying "factory" objects when
77       other objects have been created from that.  For example, an SSL_CTX
78       object created by SSL_CTX_new(3) is used to create per-connection SSL
79       objects by calling SSL_new(3).  In this specific case, and probably for
80       factory methods in general, it is not safe to modify the factory object
81       after it has been used to create other objects.


84       CRYPTO_THREAD_run_once(3), local system threads documentation.


87       This page is admittedly very incomplete.
90       Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.
92       Licensed under the Apache License 2.0 (the "License").  You may not use
93       this file except in compliance with the License.  You can obtain a copy
94       in the file LICENSE in the source distribution or at
95       <https://www.openssl.org/source/license.html>.
993.0.5                             2022-07-05            OPENSSL-THREADS(7ossl)