[openssl-dev] [openssl.org #4351] PATCH: Update Malloc docs to reflect current state of affairs

noloader@gmail.com via RT rt at openssl.org
Fri Feb 26 22:25:33 UTC 2016


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

-------------- next part --------------
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().


More information about the openssl-dev mailing list