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)
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)
Eugene Syromiatnikov