From: Eugene Syromiatnikov Date: Wed, 19 Nov 2025 14:19:59 +0000 (+0100) Subject: doc/man3/OPENSSL_malloc.pod: mention rationale for OPENSSL_cleanse() X-Git-Tag: 3.3-PRE-CLANG-FORMAT-WEBKIT~26 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=a28740aa8be4e5150e6deb6d3e246c96021295ed;p=thirdparty%2Fopenssl.git doc/man3/OPENSSL_malloc.pod: mention rationale for OPENSSL_cleanse() It was not entirely clear from the sole description, what is the reason for preferring OPENSSL_cleanse() over memset(). Add a note about situations in which OPENSSL_cleanse() should be chosen. Signed-off-by: Eugene Syromiatnikov Reviewed-by: Dmitry Belyavskiy Reviewed-by: Paul Dale Reviewed-by: Richard Levitte Reviewed-by: Tomas Mraz (Merged from https://github.com/openssl/openssl/pull/29174) (cherry picked from commit 768468f40e810ceef00b1c3b7cac05beaa1d8f8c) --- diff --git a/doc/man3/OPENSSL_malloc.pod b/doc/man3/OPENSSL_malloc.pod index 20441e76ac6..70f3cff1e04 100644 --- a/doc/man3/OPENSSL_malloc.pod +++ b/doc/man3/OPENSSL_malloc.pod @@ -103,6 +103,10 @@ before ultimately calling OPENSSL_free(). If the argument to OPENSSL_free() is NULL, nothing is done. OPENSSL_cleanse() fills B of size B with a string of 0's. +It is useful in cases when it is needed to ensure that memory (that contains +sensitive information) is overwritten (for example, before it is reclaimed, +or when it is stored on stack), and such operation is not optimised out +by compiler optimisations such as dead store elimination (as memset(3) may be). Use OPENSSL_cleanse() with care if the memory is a mapping of a file. If the storage controller uses write compression, then it's possible that sensitive tail bytes will survive zeroization because the block of