xref: /freebsd/secure/lib/libcrypto/man/man7/openssl-threads.7 (revision f126890ac5386406dadf7c4cfa9566cbb56537c5)
Automatically generated by Pod::Man 4.14 (Pod::Simple 3.42)

Standard preamble:
========================================================================
..
..
.. Set up some character translations and predefined strings. \*(-- will
give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
double quote, and \*(R" will give a right double quote. \*(C+ will
give a nicer C++. Capital omega is used to do unbreakable dashes and
therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
nothing in troff, for use with C<>.
.tr \(*W- . ds -- \(*W- . ds PI pi . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch . ds L" "" . ds R" "" . ds C` "" . ds C' "" 'br\} . ds -- \|\(em\| . ds PI \(*p . ds L" `` . ds R" '' . ds C` . ds C' 'br\}
Escape single quotes in literal strings from groff's Unicode transform.

If the F register is >0, we'll generate index entries on stderr for
titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
entries marked with X<> in POD. Of course, you'll have to process the
output yourself in some meaningful fashion.

Avoid warning from groff about undefined register 'F'.
.. .nr rF 0 . if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{\ . nr % 0 . nr F 2 . \} . \} .\} .rr rF Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff . ds #H 0 . ds #V .8m . ds #F .3m . ds #[ \f1 . ds #] .\} . ds #H ((1u-(\\\\n(.fu%2u))*.13m) . ds #V .6m . ds #F 0 . ds #[ \& . ds #] \& .\} . \" simple accents for nroff and troff . ds ' \& . ds ` \& . ds ^ \& . ds , \& . ds ~ ~ . ds / .\} . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' .\} . \" troff and (daisy-wheel) nroff accents . \" corrections for vroff . \" for low resolution devices (crt and lpr) \{\ . ds : e . ds 8 ss . ds o a . ds d- d\h'-1'\(ga . ds D- D\h'-1'\(hy . ds th \o'bp' . ds Th \o'LP' . ds ae ae . ds Ae AE .\} ========================================================================

Title "OPENSSL-THREADS 7ossl"
OPENSSL-THREADS 7ossl "2023-09-19" "3.0.11" "OpenSSL"
For nroff, turn off justification. Always turn off hyphenation; it makes
way too many mistakes in technical documents.
"NAME"
openssl-threads - Overview of thread safety in OpenSSL
"DESCRIPTION"
Header "DESCRIPTION" In this man page, we use the term thread-safe to indicate that an object or function can be used by multiple threads at the same time.

OpenSSL can be built with or without threads support. The most important use of this support is so that OpenSSL itself can use a single consistent \s-1API,\s0 as shown in \*(L"\s-1EXAMPLES\*(R"\s0 in CRYPTO_THREAD_run_once\|(3). Multi-platform applications can also use this \s-1API.\s0

In particular, being configured for threads support does not imply that all OpenSSL objects are thread-safe. To emphasize: most objects are not safe for simultaneous use. Exceptions to this should be documented on the specific manual pages, and some general high-level guidance is given here.

One major use of the OpenSSL thread \s-1API\s0 is to implement reference counting. Many objects within OpenSSL are reference-counted, so resources are not released, until the last reference is removed. References are often increased automatically (such as when an X509 certificate object is added into an X509_STORE trust store). There is often an \f(BIobject_up_ref() function that can be used to increase the reference count. Failure to match \f(BIobject_up_ref() calls with the right number of \fB\f(BIobject_free() calls is a common source of memory leaks when a program exits.

Many objects have set and get \s-1API\s0's to set attributes in the object. A \*(C`set0\*(C' passes ownership from the caller to the object and a \f(CW\*(C`get0\*(C' returns a pointer but the attribute ownership remains with the object and a reference to it is returned. A \*(C`set1\*(C' or \*(C`get1\*(C' function does not change the ownership, but instead updates the attribute's reference count so that the object is shared between the caller and the object; the caller must free the returned attribute when finished. Functions that involve attributes that have reference counts themselves, but are named with just \*(C`set\*(C' or \*(C`get\*(C' are historical; and the documentation must state how the references are handled. Get methods are often thread-safe as long as the ownership requirements are met and shared objects are not modified. Set methods, or modifying shared objects, are generally not thread-safe as discussed below.

Objects are thread-safe as long as the \s-1API\s0's being invoked don't modify the object; in this case the parameter is usually marked in the \s-1API\s0 as \*(C`const\*(C'. Not all parameters are marked this way. Note that a \*(C`const\*(C' declaration does not mean immutable; for example \fBX509_cmp\|(3) takes pointers to \*(C`const\*(C' objects, but the implementation uses a C cast to remove that so it can lock objects, generate and cache a \s-1DER\s0 encoding, and so on.

Another instance of thread-safety is when updates to an object's internal state, such as cached values, are done with locks. One example of this is the reference counting \s-1API\s0's described above.

In all cases, however, it is generally not safe for one thread to mutate an object, such as setting elements of a private or public key, while another thread is using that object, such as verifying a signature.

The same \s-1API\s0's can usually be used simultaneously on different objects without interference. For example, two threads can calculate a signature using two different \fB\s-1EVP_PKEY_CTX\s0 objects.

For implicit global state or singletons, thread-safety depends on the facility. The CRYPTO_secure_malloc\|(3) and related \s-1API\s0's have their own lock, while CRYPTO_malloc\|(3) assumes the underlying platform allocation will do any necessary locking. Some \s-1API\s0's, such as NCONF_load\|(3) and related, or OBJ_create\|(3) do no locking at all; this can be considered a bug.

A separate, although related, issue is modifying \*(L"factory\*(R" objects when other objects have been created from that. For example, an \s-1SSL_CTX\s0 object created by SSL_CTX_new\|(3) is used to create per-connection \s-1SSL\s0 objects by calling SSL_new\|(3). In this specific case, and probably for factory methods in general, it is not safe to modify the factory object after it has been used to create other objects.

"SEE ALSO"
Header "SEE ALSO" \fBCRYPTO_THREAD_run_once\|(3), local system threads documentation.
"BUGS"
Header "BUGS" This page is admittedly very incomplete.
"COPYRIGHT"
Header "COPYRIGHT" Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the \*(L"License\*(R"). You may not use this file except in compliance with the License. You can obtain a copy in the file \s-1LICENSE\s0 in the source distribution or at <https://www.openssl.org/source/license.html>.