Commit graph

17 commits

Author SHA1 Message Date
David Benjamin
2de108dfa3 Save and restore the Windows error around TlsGetValue.
TlsGetValue clears the last error even on success, so that callers may
distinguish it successfully returning NULL or failing. This error-mangling
behavior interferes with the caller's use of GetLastError. In particular
SSL_get_error queries the error queue to determine whether the caller should
look at the OS's errors. To avoid destroying state, save and restore the
Windows error.

Fixes #6299.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6316)
2018-05-23 17:34:54 -04:00
Richard Levitte
28428130db Update copyright year
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5990)
2018-04-17 15:18:40 +02:00
Rich Salz
7de2b9c4af Set error code if alloc returns NULL
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5886)
2018-04-05 15:13:55 -04:00
Pauli
f49452c297 Return a value from atomic read on Windows.
Use a read lock when reading using pthreads.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4517)
2017-10-11 09:47:54 +10:00
Pauli
30ff41beab Add atomic write call
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4414)
2017-10-10 08:45:53 +10:00
Pauli
94683b7acb Add a CRYPTO_atomic_read call which allows an int variable to be read
in an atomic fashion.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4414)
2017-10-10 08:45:52 +10:00
Rich Salz
2915fe19a6 Add fork handlers, based on pthread_atfork
Only for Unix platforms

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3754)
2017-06-29 16:19:41 -04:00
Matt Caswell
1fda5bc435 Revert "Fixed deadlock in CRYPTO_THREAD_run_once for Windows"
This reverts commit 349d1cfddc.

The proposed fix is incorrect. It marks the "run_once" code as having
finished before it has. The intended semantics of run_once is that no
threads should proceed until the code has run exactly once. With this
change the "second" thread will think the run_once code has already been
run and will continue, even though it is still in progress. This could
result in a crash or other incorrect behaviour.

Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-11-14 11:55:13 +00:00
DK
349d1cfddc Fixed deadlock in CRYPTO_THREAD_run_once for Windows
Fixed deadlock in CRYPTO_THREAD_run_once() if call to init() is causing
a recursive call to CRYPTO_THREAD_run_once() again that is causing a hot
deadloop inside do { } while (result == ONCE_ININIT); section.

CLA: trivial
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1913)
2016-11-13 15:43:05 -05:00
Andy Polyakov
f1f5ee17b6 include/openssl: don't include <windows.h> in public headers.
If application uses any of Windows-specific interfaces, make it
application developer's respondibility to include <windows.h>.
Rationale is that <windows.h> is quite "toxic" and is sensitive
to inclusion order (most notably in relation to <winsock2.h>).
It's only natural to give complete control to the application developer.

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
2016-07-08 11:49:44 +02:00
Matt Caswell
fcb318c64b Fix Windows 64 bit crashes
The function InitOnceExceuteOnce is the best way to support the
implementation of CRYPTO_THREAD_run_once() on Windows. Unfortunately
WinXP doesn't have it. To get around that we had two different
implementations: one for WinXP and one for later versions. Which one was
used was based on the value of _WIN32_WINNT.

This approach was starting to cause problems though because other parts of
OpenSSL assume _WIN32_WINNT is going to be 0x0501 and crashes were
occurring dependant on include file ordering. In addition a conditional
based on _WIN32_WINNT had made its way into a public header file through
commit 5c4328f. This is problematic because the value of this macro can
vary between OpenSSL build time and application build time.

The simplest solution to this mess is just to always use the WinXP version
of CRYPTO_THREAD_run_once(). Its perhaps slightly sub-optimal but probably
not noticably.

GitHub Issue #1086

Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-20 23:08:18 +01:00
Rich Salz
aa6bb1352b Copyright consolidation 05/10
Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-17 15:38:09 -04:00
Viktor Dukhovni
5c4328f04f Fold threads.h into crypto.h making API public
Document thread-safe lock creation

Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-16 12:16:26 -04:00
Mat
6b88864310 Fix: CRYPTO_THREAD_run_once
InitOnceExecuteOnce returns nonzero on success:
MSDN: "If the function succeeds, the return value is nonzero."

So return 1 if it is nonzero, 0 others.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-04-02 16:56:09 -04:00
Mat
642565106e Fix return type for CRYPTO_THREAD_run_once
return type should be int and not void

Signed-off-by: Rich Salz <rsalz@akamai.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-09 20:42:30 -05:00
FdaSilvaYY
0b2fc9286f GH773: Possible leak on CRYPTO_THREAD_lock_new failure
Signed-off-by: Rich Salz <rsalz@akamai.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
2016-03-03 19:47:01 -05:00
Alessandro Ghedini
71a04cfca0 Implement new multi-threading API
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
2016-02-26 10:00:36 +00:00