Fix UWP builds by defining VirtualLock

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull

Fix UWP builds by defining VirtualLock

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18311)

show more ...

Update copyright year

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Release: yes

Move e_os.h to include/internal

Including e_os.h with a path from a header file doesn't work well on
certain exotic platform. It simply fails to build.

Since we don't seem to b

Move e_os.h to include/internal

Including e_os.h with a path from a header file doesn't work well on
certain exotic platform. It simply fails to build.

Since we don't seem to be able to stop ourselves, the better move is
to move e_os.h to an include directory that's part of the inclusion
path given to the compiler.

Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17641)

show more ...

Update copyright year

Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14801)

Remove locking in CRYPTO_secure_allocated()

The check for being in secure memory is against the arena. The arena is only
ever modified by sh_init() and sh_done() and in both cases, it i

Remove locking in CRYPTO_secure_allocated()

The check for being in secure memory is against the arena. The arena is only
ever modified by sh_init() and sh_done() and in both cases, it is done without
locking. Thus, it is safe for the CRYPTO_secure_allocated() to not lock.

Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14775)

show more ...

Make the lock in CRYPTO_secure_allocated() a read lock

Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14775)

Always check CRYPTO_LOCK_{read,write}_lock

Some functions that lock things are void, so we just return early.

Also make ossl_namemap_empty return 0 on error. Updated the docs, and

Always check CRYPTO_LOCK_{read,write}_lock

Some functions that lock things are void, so we just return early.

Also make ossl_namemap_empty return 0 on error. Updated the docs, and added
some code to ossl_namemap_stored() to handle the failure, and updated the
tests to allow for failure.

Fixes: #14230

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14238)

show more ...

Add MAP_CONCEAL from OpenBSD which has similar purpose but on mmap
call level.

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Re

Add MAP_CONCEAL from OpenBSD which has similar purpose but on mmap
call level.

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13394)

show more ...

CRYPTO_secure_malloc_init: Add FreeBSD support for secure-malloc dont-dump-region.

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Re

CRYPTO_secure_malloc_init: Add FreeBSD support for secure-malloc dont-dump-region.

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13394)

show more ...

Implement OpenSSL secure memory for Windows

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl

Implement OpenSSL secure memory for Windows

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13172)

show more ...

Fix wrong return value check of mmap function

The mmap function never returns NULL. If an error occurs, the function returns MAP_FAILED.

CLA: trivial

Reviewed-by: Tomas Mra

Fix wrong return value check of mmap function

The mmap function never returns NULL. If an error occurs, the function returns MAP_FAILED.

CLA: trivial

Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12187)

show more ...

Update copyright year

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11616)

secmem: ignore small minsize arguments to CRYPTO_secure_malloc_init().

If the user specifies a minimum allocation size that is smaller than
the free list structure (or zero), calculate t

secmem: ignore small minsize arguments to CRYPTO_secure_malloc_init().

If the user specifies a minimum allocation size that is smaller than
the free list structure (or zero), calculate the minimum possible size rather
than failing.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11149)

show more ...

Mem-sec small code adjustment

Conditional code readability improvement.

Remove unused macro

Commit #11042 has introduced a new, unused, CRYPTO_EX_INDEX macro.
Remove be

Mem-sec small code adjustment

Conditional code readability improvement.

Remove unused macro

Commit #11042 has introduced a new, unused, CRYPTO_EX_INDEX macro.
Remove before version release.

Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11103)

show more ...

Make secure-memory be a config option

Adding support for "no-secure-memory" was simple, a one-liner.
Fixing all the "ifdef OPENSSL_SECURE_MEMORY" to be "ifndef NO_xxx"
was a bit more

Make secure-memory be a config option

Adding support for "no-secure-memory" was simple, a one-liner.
Fixing all the "ifdef OPENSSL_SECURE_MEMORY" to be "ifndef NO_xxx"
was a bit more work. My original goof, for not following the OpenSSL
pattern "ifndef NO_" used everywhere else.

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/11023)

show more ...

Make minimum size for secure memory a size_t.

The minimum size argument to CRYPTO_secure_malloc_init() was an int but ought
to be a size_t since it is a size.

From an API perspe

Make minimum size for secure memory a size_t.

The minimum size argument to CRYPTO_secure_malloc_init() was an int but ought
to be a size_t since it is a size.

From an API perspective, this is a change. However, the minimum size is
verified as being a positive power of two and it will typically be a small
constant.

Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from #11003)

show more ...

Use vxRandLib for VxWorks7

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/

Use vxRandLib for VxWorks7

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/8023)

show more ...

Following the license change, modify the boilerplates in crypto/

[skip ci]

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7827)

test/secmemtest: test secure memory only if it is implemented

Fixes #7322

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>

test/secmemtest: test secure memory only if it is implemented

Fixes #7322

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/7351)

show more ...

Zero memory in CRYPTO_secure_malloc.

This commit destroys the free list pointers which would otherwise be
present in the returned memory blocks. This in turn helps prevent
informati

Zero memory in CRYPTO_secure_malloc.

This commit destroys the free list pointers which would otherwise be
present in the returned memory blocks. This in turn helps prevent
information leakage from the secure memory area.

Note: CRYPTO_secure_malloc is not guaranteed to return zeroed memory:
before the secure memory system is initialised or if it isn't implemented.

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7011)

show more ...

Use void in all function definitions that do not take any arguments

Reviewed-by: Rich Salz <rsalz@openssl.org>
GH: #6208

mem_sec.c: portability fixup.

Reviewed-by: Rich Salz <rsalz@openssl.org>

mem_sec.c: portability fixup.

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5493)

mem_sec.c: relax POSIX requirement.

Even though mlock(2) was standardized in POSIX.1-2001, vendors did
implement it prior that point.

Reviewed-by: Rich Salz <rsalz@openssl.org>

mem_sec.c: relax POSIX requirement.

Even though mlock(2) was standardized in POSIX.1-2001, vendors did
implement it prior that point.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5460)

show more ...

Revert the crypto "global lock" implementation

Conceptually, this is a squashed version of:

Revert "Address feedback"

This reverts commit 75551e07bd2339dfea06ef1d31

Revert the crypto "global lock" implementation

Conceptually, this is a squashed version of:

Revert "Address feedback"

This reverts commit 75551e07bd2339dfea06ef1d31d69929e13a4495.

and

Revert "Add CRYPTO_thread_glock_new"

This reverts commit ed6b2c7938ec6f07b15745d4183afc276e74c6dd.

But there were some intervening commits that made neither revert apply
cleanly, so instead do it all as one shot.

The crypto global locks were an attempt to cope with the awkward
POSIX semantics for pthread_atfork(); its documentation (the "RATIONALE"
section) indicates that the expected usage is to have the prefork handler
lock all "global" locks, and the parent and child handlers release those
locks, to ensure that forking happens with a consistent (lock) state.
However, the set of functions available in the child process is limited
to async-signal-safe functions, and pthread_mutex_unlock() is not on
the list of async-signal-safe functions! The only synchronization
primitives that are async-signal-safe are the semaphore primitives,
which are not really appropriate for general-purpose usage.

However, the state consistency problem that the global locks were
attempting to solve is not actually a serious problem, particularly for
OpenSSL. That is, we can consider four cases of forking application
that might use OpenSSL:

(1) Single-threaded, does not call into OpenSSL in the child (e.g.,
the child calls exec() immediately)

For this class of process, no locking is needed at all, since there is
only ever a single thread of execution and the only reentrancy is due to
signal handlers (which are themselves limited to async-signal-safe
operation and should not be doing much work at all).

(2) Single-threaded, calls into OpenSSL after fork()

The application must ensure that it does not fork() with an unexpected
lock held (that is, one that would get unlocked in the parent but
accidentally remain locked in the child and cause deadlock). Since
OpenSSL does not expose any of its internal locks to the application
and the application is single-threaded, the OpenSSL internal locks
will be unlocked for the fork(), and the state will be consistent.
(OpenSSL will need to reseed its PRNG in the child, but that is
an orthogonal issue.) If the application makes use of locks from
libcrypto, proper handling for those locks is the responsibility of
the application, as for any other locking primitive that is available
for application programming.

(3) Multi-threaded, does not call into OpenSSL after fork()

As for (1), the OpenSSL state is only relevant in the parent, so
no particular fork()-related handling is needed. The internal locks
are relevant, but there is no interaction with the child to consider.

(4) Multi-threaded, calls into OpenSSL after fork()

This is the case where the pthread_atfork() hooks to ensure that all
global locks are in a known state across fork() would come into play,
per the above discussion. However, these "calls into OpenSSL after
fork()" are still subject to the restriction to async-signal-safe
functions. Since OpenSSL uses all sorts of locking and libc functions
that are not on the list of safe functions (e.g., malloc()), this
case is not currently usable and is unlikely to ever be usable,
independently of the locking situation. So, there is no need to
go through contortions to attempt to support this case in the one small
area of locking interaction with fork().

In light of the above analysis (thanks @davidben and @achernya), go
back to the simpler implementation that does not need to distinguish
"library-global" locks or to have complicated atfork handling for locks.

Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5089)

show more ...