There is little need to support alignments larger than a page size,
and the open-coded OPENSSL_aligned_alloc() implementation implements
that support in quite wasteful manner, so it is better just to limit
the maximum supported alignment explicitly. The value of 65536
has been chosen so it is architecture-agnostic and is no less than page sizes
used in commonly occurring architectures (and also it is a pretty number).
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28295)
While posix_memalign() is generally not expected to fail, we can always use
the internal aligned alloc implementation to ensure that any
OPENSSL_aligned_malloc failure is indeed fatal and does not require
a fallback.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28295)
Factor the open-coded aligned allocation implementation in a separate
file and use it instead of just returning NULL in CRYPTO_aligned_alloc
implementation in the FIPS provider.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28295)
Originally, CRYPTO_aligned_alloc() returned NULL if OpenSSL was built
with OPENSSL_SMALL_FOOTPRINT defined, which is a weird place for such
a consideration; moreover it means that every caller requires to
implement some form of a fallback (and manually over-allocate
and then align the returned memory if the alignment is a requirement),
which is counter-productive (and outright ridiculous in environments
with posix_memalign() available). Move the OPENSSL_SMALL_FOOTPRINT
consideration to the only current caller and update the documentation
and tests accordingly.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28295)
The open-coded implementation performs addition of size and alignment,
that may overflow.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28059)
Report the errors for the known error codes returned
by posix_memalign().
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28059)
Otherwise the roundup calculation performed in the open-coded implementation
may put the pointer out of bounds.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28059)
The original C11 specification is pretty weird: it specifies that the size
must be a multiple of alignment (rendering it useless for small page-aligned
allocations that, for example, might be useful for RDMA) and until DR460[1]
it was UB in failing to do so (as it is with OPENSSL_ligned_alloc() calls
in alloc_new_neighborhood_list() on 32-bit systems, for example).
Moreover, it has arguably not been used much before, as all supported POSIX
systems have at least POSIX 2001 compatibility level nowadays,
Windows doesn't implement aligned_alloc() at all (because implementation
of free() in MS CRT is unable to handle aligned allocations[2]),
and _ISOC11_SOURCE is a glibc-specific feature test macro.
[1] https://open-std.org/JTC1/SC22/WG14/www/docs/summary.htm#dr_460
[2] https://learn.microsoft.com/en-us/cpp/standard-library/cstdlib?view=msvc-170#remarks-6
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28059)
There is no need to initialise neither *freeptr, as it is initialised
already, nor ret, as NULL can be simply returned instead.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28059)
* crypto/mem.c [OPENSSL_SMALL_FOOTPRINT] (CRYPTO_aligned_alloc): Change
freeptr to *freeptr to properly update the variable passed by pointer.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28059)
Analogous to the way CRYPTO_malloc does it.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28059)
Seems like the case of realloc() returning NULL with non-zero size
has been overlooked.
Complements: 5639ee79bd "ERR: Make CRYPTO_malloc() and friends report ERR_R_MALLOC_FAILURE"
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28059)
Signed-off-by: Norbert Pocs <norbertp@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27961)
If the application provides custom memory allocations functions via
CRYPTO_set_mem_functions() then those should be used instead something
else like posix_memalign(). The applications might verify alloc and free
calls and pointers from posix_memalign() were never returned by the
implementations.
At least stunnel4 complains here.
Use posix_memalign() or if aligned_alloc() only if the application did
not provide a custom malloc() implementation. In case of a custom
implementation use CRYPTO_malloc() and align the memory accordingly.
Fixes#25678
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25682)
Create a new hashtable that is more efficient than the existing LHASH_OF
implementation. the new ossl_ht api offers several new features that
improve performance opportunistically
* A more generalized hash function. Currently using fnv1a, provides a
more general hash function, but can still be overridden where needed
* Improved locking and reference counting. This hash table is
internally locked with an RCU lock, and optionally reference counts
elements, allowing for users to not have to create and manage their
own read/write locks
* Lockless operation. The hash table can be configured to operate
locklessly on the read side, improving performance, at the sacrifice
of the ability to grow the hash table or delete elements from it
* A filter function allowing for the retrieval of several elements at a
time matching a given criteria without having to hold a lock
permanently
* a doall_until iterator variant, that allows callers which need to
iterate over the entire hash table until a given condition is met (as
defined by the return value of the iterator callback). This allows
for callers attempting to do expensive cache searches for a small
number of elements to terminate the iteration early, saving cpu cycles
* Dynamic type safety. The hash table provides operations to set and
get data of a specific type without having to define a type at the
instatiation point
* Multiple data type storage. The hash table can store multiple data
types allowing for more flexible usage
* Ubsan safety. Because the API deals with concrete single types
(HT_KEY and HT_VALUE), leaving specific type casting to the call
recipient with dynamic type validation, this implementation is safe
from the ubsan undefined behavior warnings that require additional
thunking on callbacks.
Testing of this new hashtable with an equivalent hash function, I can
observe approximately a 6% performance improvement in the lhash_test
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23671)
This is used for memory allocation failure debugging only
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22347)
Allow 2 digits after the comma in percentage in OPENSSL_MALLOC_FAILURES.
Add OPENSSL_MALLOC_SEED to allow for some randomization.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22127)
There is a rarely used feature that can be enabled
with `./config enable-crypto-mdebug` when additionally
the environment variable OPENSSL_MALLOC_FAILURES is used.
It turns out to be possible that CRYPTO_zalloc may
create a leak when the memory is allocated and then
the shouldfail happens, then the memory is lost.
Likewise when OPENSSL_realloc is used with size=0,
then the memory is to be free'd but here the shouldfail
check is too early, and the failure may prevent the
memory to be freed thus creating a bogus memory leak.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21944)
Fixes#6251
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/14833)
Those 2 functions historically only ever returned 0 or 1. In OpenSSL 3.0
they were made no-ops and the documentation says they always return 0. In
fact they were returning -1. If any application was actually using these
functions then it may appear that they were actually successful (e.g. -1
could be interpreted as "true").
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18967)
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)
Doing the tsan operations under lock would be difficult to arrange here (locks
require memory allocation).
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/17479)
This macro is used to determine if certain pieces of code should
become part of the FIPS module or not. The old name was confusing.
Fixes#11538
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11539)
Typedefs of CRYPTO malloc, realloc and free.
MEM_CHECK "modes" are used only as a CRYPTO_mem_ctrl() parameter
The CRYPTO_mem_ctrl is defined only if OPENSSL_NO_CRYPTO_MDEBUG is
defined, thus define the MEM_CHECK modes under the same condition.
Maybe the macros can be removed at all since:
1. CRYPTO_mem_ctrl() just returns -1 and ignores the parameter
2. CRYPTO_mem_ctr() is declared as DEPRECATED by 3.0
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11042)
Fixes#8322
The leak-checking (and backtrace option, on some platforms) provided
by crypto-mdebug and crypto-mdebug-backtrace have been mostly neutered;
only the "make malloc fail" capability remains. OpenSSL recommends using
the compiler's leak-detection instead.
The OPENSSL_DEBUG_MEMORY environment variable is no longer used.
CRYPTO_mem_ctrl(), CRYPTO_set_mem_debug(), CRYPTO_mem_leaks(),
CRYPTO_mem_leaks_fp() and CRYPTO_mem_leaks_cb() return a failure code.
CRYPTO_mem_debug_{malloc,realloc,free}() have been removed. All of the
above are now deprecated.
Merge (now really small) mem_dbg.c into mem.c
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10572)
Currently, there are two different directories which contain internal
header files of libcrypto which are meant to be shared internally:
While header files in 'include/internal' are intended to be shared
between libcrypto and libssl, the files in 'crypto/include/internal'
are intended to be shared inside libcrypto only.
To make things complicated, the include search path is set up in such
a way that the directive #include "internal/file.h" could refer to
a file in either of these two directoroes. This makes it necessary
in some cases to add a '_int.h' suffix to some files to resolve this
ambiguity:
#include "internal/file.h" # located in 'include/internal'
#include "internal/file_int.h" # located in 'crypto/include/internal'
This commit moves the private crypto headers from
'crypto/include/internal' to 'include/crypto'
As a result, the include directives become unambiguous
#include "internal/file.h" # located in 'include/internal'
#include "crypto/file.h" # located in 'include/crypto'
hence the superfluous '_int.h' suffixes can be stripped.
The files 'store_int.h' and 'store.h' need to be treated specially;
they are joined into a single file.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)
Rationale is that it wasn't providing accurate statistics anyway.
For statistics to be accurate CRYPTO_get_alloc_counts should acquire
a lock and lock-free additions should not be an option.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6786)
Use atomic operations for the counters
Rename malloc_lock to memdbg_lock
Also fix some style errors in mem_dbg.c
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/4359)
cryptilib.h is the second.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4188)
Removed e_os.h from all bar three headers (apps/apps.h crypto/bio/bio_lcl.h and
ssl/ssl_locl.h).
Added e_os.h into the files that need it now.
Directly reference internal/nelem.h when required.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4188)
Remove GETPID_IS_MEANINGLESS and osslargused.
Move socket-related things to new file internal/sockets.h; this is now
only needed by four(!!!) files. Compiles should be a bit faster.
Remove USE_SOCKETS ifdef's
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4209)
Windows doesn't provide random(). In this particular case, our
requirements on the quality of randomness isn't high, so we don't
need to care how good randomness rand() does or doesn't provide.
Fixes#3778
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3779)
Eugene Syromiatnikov
openssl-machine
Norbert Pocs
sftcd
Sebastian Andrzej Siewior
Tomas Mraz
Neil Horman
Bernd Edlinger
Matt Caswell
Dr. David von Oheimb
Richard Levitte
Pauli
Davide Galassi
Rich Salz
Dr. Matthias St. Pierre
Andy Polyakov
knekritz
Rich Salz
Pauli
Hikar