1*b077aed3SPierre Pronchery=pod 2*b077aed3SPierre Pronchery 3*b077aed3SPierre Pronchery=head1 NAME 4*b077aed3SPierre Pronchery 5*b077aed3SPierre Proncheryopenssl-threads - Overview of thread safety in OpenSSL 6*b077aed3SPierre Pronchery 7*b077aed3SPierre Pronchery=head1 DESCRIPTION 8*b077aed3SPierre Pronchery 9*b077aed3SPierre ProncheryIn this man page, we use the term B<thread-safe> to indicate that an 10*b077aed3SPierre Proncheryobject or function can be used by multiple threads at the same time. 11*b077aed3SPierre Pronchery 12*b077aed3SPierre ProncheryOpenSSL can be built with or without threads support. The most important 13*b077aed3SPierre Proncheryuse of this support is so that OpenSSL itself can use a single consistent 14*b077aed3SPierre ProncheryAPI, as shown in L<CRYPTO_THREAD_run_once(3)/EXAMPLES>. 15*b077aed3SPierre ProncheryMulti-platform applications can also use this API. 16*b077aed3SPierre Pronchery 17*b077aed3SPierre ProncheryIn particular, being configured for threads support does not imply that 18*b077aed3SPierre Proncheryall OpenSSL objects are thread-safe. 19*b077aed3SPierre ProncheryTo emphasize: I<most objects are not safe for simultaneous use>. 20*b077aed3SPierre ProncheryExceptions to this should be documented on the specific manual pages, and 21*b077aed3SPierre Proncherysome general high-level guidance is given here. 22*b077aed3SPierre Pronchery 23*b077aed3SPierre ProncheryOne major use of the OpenSSL thread API is to implement reference counting. 24*b077aed3SPierre ProncheryMany objects within OpenSSL are reference-counted, so resources are not 25*b077aed3SPierre Proncheryreleased, until the last reference is removed. 26*b077aed3SPierre ProncheryReferences are often increased automatically (such as when an B<X509> 27*b077aed3SPierre Proncherycertificate object is added into an B<X509_STORE> trust store). 28*b077aed3SPierre ProncheryThere is often an B<I<object>_up_ref>() function that can be used to increase 29*b077aed3SPierre Proncherythe reference count. 30*b077aed3SPierre ProncheryFailure to match B<I<object>_up_ref>() calls with the right number of 31*b077aed3SPierre ProncheryB<I<object>_free>() calls is a common source of memory leaks when a program 32*b077aed3SPierre Proncheryexits. 33*b077aed3SPierre Pronchery 34*b077aed3SPierre ProncheryMany objects have set and get API's to set attributes in the object. 35*b077aed3SPierre ProncheryA C<set0> passes ownership from the caller to the object and a 36*b077aed3SPierre ProncheryC<get0> returns a pointer but the attribute ownership 37*b077aed3SPierre Proncheryremains with the object and a reference to it is returned. 38*b077aed3SPierre ProncheryA C<set1> or C<get1> function does not change the ownership, but instead 39*b077aed3SPierre Proncheryupdates the attribute's reference count so that the object is shared 40*b077aed3SPierre Proncherybetween the caller and the object; the caller must free the returned 41*b077aed3SPierre Proncheryattribute when finished. 42*b077aed3SPierre ProncheryFunctions that involve attributes that have reference counts themselves, 43*b077aed3SPierre Proncherybut are named with just C<set> or C<get> are historical; and the documentation 44*b077aed3SPierre Proncherymust state how the references are handled. 45*b077aed3SPierre ProncheryGet methods are often thread-safe as long as the ownership requirements are 46*b077aed3SPierre Proncherymet and shared objects are not modified. 47*b077aed3SPierre ProncherySet methods, or modifying shared objects, are generally not thread-safe 48*b077aed3SPierre Proncheryas discussed below. 49*b077aed3SPierre Pronchery 50*b077aed3SPierre ProncheryObjects are thread-safe 51*b077aed3SPierre Proncheryas long as the API's being invoked don't modify the object; in this 52*b077aed3SPierre Proncherycase the parameter is usually marked in the API as C<const>. 53*b077aed3SPierre ProncheryNot all parameters are marked this way. 54*b077aed3SPierre ProncheryNote that a C<const> declaration does not mean immutable; for example 55*b077aed3SPierre ProncheryL<X509_cmp(3)> takes pointers to C<const> objects, but the implementation 56*b077aed3SPierre Proncheryuses a C cast to remove that so it can lock objects, generate and cache 57*b077aed3SPierre Proncherya DER encoding, and so on. 58*b077aed3SPierre Pronchery 59*b077aed3SPierre ProncheryAnother instance of thread-safety is when updates to an object's 60*b077aed3SPierre Proncheryinternal state, such as cached values, are done with locks. 61*b077aed3SPierre ProncheryOne example of this is the reference counting API's described above. 62*b077aed3SPierre Pronchery 63*b077aed3SPierre ProncheryIn all cases, however, it is generally not safe for one thread to 64*b077aed3SPierre Proncherymutate an object, such as setting elements of a private or public key, 65*b077aed3SPierre Proncherywhile another thread is using that object, such as verifying a signature. 66*b077aed3SPierre Pronchery 67*b077aed3SPierre ProncheryThe same API's can usually be used simultaneously on different objects 68*b077aed3SPierre Proncherywithout interference. 69*b077aed3SPierre ProncheryFor example, two threads can calculate a signature using two different 70*b077aed3SPierre ProncheryB<EVP_PKEY_CTX> objects. 71*b077aed3SPierre Pronchery 72*b077aed3SPierre ProncheryFor implicit global state or singletons, thread-safety depends on the facility. 73*b077aed3SPierre ProncheryThe L<CRYPTO_secure_malloc(3)> and related API's have their own lock, 74*b077aed3SPierre Proncherywhile L<CRYPTO_malloc(3)> assumes the underlying platform allocation 75*b077aed3SPierre Proncherywill do any necessary locking. 76*b077aed3SPierre ProncherySome API's, such as L<NCONF_load(3)> and related, or L<OBJ_create(3)> 77*b077aed3SPierre Proncherydo no locking at all; this can be considered a bug. 78*b077aed3SPierre Pronchery 79*b077aed3SPierre ProncheryA separate, although related, issue is modifying "factory" objects 80*b077aed3SPierre Proncherywhen other objects have been created from that. 81*b077aed3SPierre ProncheryFor example, an B<SSL_CTX> object created by L<SSL_CTX_new(3)> is used 82*b077aed3SPierre Proncheryto create per-connection B<SSL> objects by calling L<SSL_new(3)>. 83*b077aed3SPierre ProncheryIn this specific case, and probably for factory methods in general, it is 84*b077aed3SPierre Proncherynot safe to modify the factory object after it has been used to create 85*b077aed3SPierre Proncheryother objects. 86*b077aed3SPierre Pronchery 87*b077aed3SPierre Pronchery=head1 SEE ALSO 88*b077aed3SPierre Pronchery 89*b077aed3SPierre ProncheryCRYPTO_THREAD_run_once(3), 90*b077aed3SPierre Proncherylocal system threads documentation. 91*b077aed3SPierre Pronchery 92*b077aed3SPierre Pronchery=head1 BUGS 93*b077aed3SPierre Pronchery 94*b077aed3SPierre ProncheryThis page is admittedly very incomplete. 95*b077aed3SPierre Pronchery 96*b077aed3SPierre Pronchery=head1 COPYRIGHT 97*b077aed3SPierre Pronchery 98*b077aed3SPierre ProncheryCopyright 2021 The OpenSSL Project Authors. All Rights Reserved. 99*b077aed3SPierre Pronchery 100*b077aed3SPierre ProncheryLicensed under the Apache License 2.0 (the "License"). You may not use 101*b077aed3SPierre Proncherythis file except in compliance with the License. You can obtain a copy 102*b077aed3SPierre Proncheryin the file LICENSE in the source distribution or at 103*b077aed3SPierre ProncheryL<https://www.openssl.org/source/license.html>. 104*b077aed3SPierre Pronchery 105*b077aed3SPierre Pronchery=cut 106