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: 4.0-PRE-CLANG-FORMAT-WEBKIT~148 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=768468f40e810ceef00b1c3b7cac05beaa1d8f8c;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) --- diff --git a/doc/man3/OPENSSL_malloc.pod b/doc/man3/OPENSSL_malloc.pod index 5ddc6e4a6c0..30ceeb6ec03 100644 --- a/doc/man3/OPENSSL_malloc.pod +++ b/doc/man3/OPENSSL_malloc.pod @@ -151,6 +151,10 @@ these functions return an error if multiplication of B and B leads to an integer overflow, thus preventing allocations of an incorrect size. 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