There are two changes below. First, OPENSSL_cleanse() was provided documentation consistent with the new policy of "public functions have documentation; otherwise its private". Second, updated OPENSSL_clear_realloc() and OPENSSL_clear_free() to reflect current state of affairs with respect to OPENSSL_cleanse() and its recent changes (https://git.openssl.org/?p=openssl.git;a=commitdiff;h=104ce8a9f02d250dd43c255eb7b8747e81b29422;hp=380f18ed5f140e0ae1b68f3ab8f4f7c395658d9e).
$ cat malloc.diff diff --git a/doc/crypto/OPENSSL_malloc.pod b/doc/crypto/OPENSSL_malloc.pod index 04fa0b7..4e08918 100644 --- a/doc/crypto/OPENSSL_malloc.pod +++ b/doc/crypto/OPENSSL_malloc.pod @@ -4,7 +4,7 @@ OPENSSL_malloc_init, OPENSSL_malloc, OPENSSL_zalloc, OPENSSL_realloc, OPENSSL_free, -OPENSSL_clear_realloc, OPENSSL_clear_free, +OPENSSL_clear_realloc, OPENSSL_clear_free, OPENSSL_cleanse CRYPTO_malloc, CRYPTO_zalloc, CRYPTO_realloc, CRYPTO_free, OPENSSL_strdup, OPENSSL_strndup, OPENSSL_memdup, OPENSSL_strlcpy, OPENSSL_strlcat, @@ -84,9 +84,17 @@ OPENSSL_zalloc() calls memset() to zero the memory before returning. OPENSSL_clear_realloc() and OPENSSL_clear_free() should be used when the buffer at B<addr> holds sensitive information. -The old buffer is filled with arbitrary data by calling OPENSSL_cleanse() +The old buffer is filled with 0's by calling OPENSSL_cleanse() before ultimately calling OPENSSL_free(). +OPENSSL_cleanse() fills B<ptr> of size B<len> with a string of 0's. +Use OPENSSL_cleanse() with care if the memory is a mapping of a file. +If the storage controller uses write compression, then its possible +that sensitive tail bytes will survive zeroization because the block +of zeros will be compressed. If the storage controller uses wear leveling, +then the old sensitive data will not be overwritten; rather, a block of +0's will be written at a new physical location. + OPENSSL_strdup(), OPENSSL_strndup() and OPENSSL_memdup() are like the equivalent C functions, except that memory is allocated by calling the OPENSSL_malloc() and should be releaed by calling OPENSSL_free(). -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4351 Please log in as guest with password guest if prompted
diff --git a/doc/crypto/OPENSSL_malloc.pod b/doc/crypto/OPENSSL_malloc.pod index 04fa0b7..4e08918 100644 --- a/doc/crypto/OPENSSL_malloc.pod +++ b/doc/crypto/OPENSSL_malloc.pod @@ -4,7 +4,7 @@ OPENSSL_malloc_init, OPENSSL_malloc, OPENSSL_zalloc, OPENSSL_realloc, OPENSSL_free, -OPENSSL_clear_realloc, OPENSSL_clear_free, +OPENSSL_clear_realloc, OPENSSL_clear_free, OPENSSL_cleanse CRYPTO_malloc, CRYPTO_zalloc, CRYPTO_realloc, CRYPTO_free, OPENSSL_strdup, OPENSSL_strndup, OPENSSL_memdup, OPENSSL_strlcpy, OPENSSL_strlcat, @@ -84,9 +84,17 @@ OPENSSL_zalloc() calls memset() to zero the memory before returning. OPENSSL_clear_realloc() and OPENSSL_clear_free() should be used when the buffer at B<addr> holds sensitive information. -The old buffer is filled with arbitrary data by calling OPENSSL_cleanse() +The old buffer is filled with 0's by calling OPENSSL_cleanse() before ultimately calling OPENSSL_free(). +OPENSSL_cleanse() fills B<ptr> of size B<len> with a string of 0's. +Use OPENSSL_cleanse() with care if the memory is a mapping of a file. +If the storage controller uses write compression, then its possible +that sensitive tail bytes will survive zeroization because the block +of zeros will be compressed. If the storage controller uses wear leveling, +then the old sensitive data will not be overwritten; rather, a block of +0's will be written at a new physical location. + OPENSSL_strdup(), OPENSSL_strndup() and OPENSSL_memdup() are like the equivalent C functions, except that memory is allocated by calling the OPENSSL_malloc() and should be releaed by calling OPENSSL_free().
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
