为什么OPENSSL_cleanse看起来如此复杂且线程不安全？
这是OpenSSL 1.0.1i中OPENSSL_cleanse的实现
unsigned char cleanse_ctr = 0; void OPENSSL_cleanse(void *ptr, size_t len) { unsigned char *p = ptr; size_t loop = len, ctr = cleanse_ctr; while(loop--) { *(p++) = (unsigned char)ctr; ctr += (17 + ((size_t)p & 0xF)); } p=memchr(ptr, (unsigned char)ctr, len); if(p) ctr += (63 + (size_t)p); cleanse_ctr = (unsigned char)ctr; } 它看起来很复杂且线程不安全（通过读写全局变量cleanse_ctr ）。 有人可以解释一下这个实现吗？ 用户是否需要关注其中可能的数据竞争？
代码中存在数据争用，但这并不重要，因为变量的要点只是提供用于填充内存的不同垃圾数据。 换句话说，任何给定线程从该变量读取的值都不重要。 用户无需关心它。 事实上，数据竞争甚至可能使该function更有效。
为什么OPENSSL_cleanse看起来如此复杂且线程不安全？
该函数很复杂，试图阻止优化器将其作为死代码删除。
C标准不提供像pin这样的关键字来确保不删除语句。 如果删除了归零器，那么编译器人员会告诉你“……但是你要求优化”。
C11提供附件K中的memset_s ，保证不被删除。 但是Drepper和朋友反对“更安全”的function，所以它们在GNU Linux上不可用。 例如，请参阅glibc库缺少memset_s 。
OpenSSL还避免了volatile因为GCC人员将标准解释为硬件支持的内存。 也就是说，易失性存储器可以由硬件改变，但不能由另一个线程改变。 这与微软对限定符的解释形成对比。
另请注意，在Windows平台（OpenSSL是跨平台）上，OpenSSL可以使用SecureZeroMemory 。 Microsoft解决了优化器提前删除代码的问题。
编辑（2016年2月） ：看起来OpenSSL 1.1.0简化了清理function： RT4116：将清理更改为memset 。 这是mem_clr.c上的差异：
diff --git a/crypto/mem_clr.cb/crypto/mem_clr.c index e6450a1..3389919 100644 (file) --- a/crypto/mem_clr.c +++ b/crypto/mem_clr.c @@ -59,23 +59,16 @@ #include #include -extern unsigned char cleanse_ctr; -unsigned char cleanse_ctr = 0; +/* + * Pointer to memset is volatile so that compiler must de-reference + * the pointer and can't assume that it points to any function in + * particular (such as memset, which it then might further "optimize") + */ +typedef void *(*memset_t)(void *,int,size_t); + +static volatile memset_t memset_func = memset; void OPENSSL_cleanse(void *ptr, size_t len) { - unsigned char *p = ptr; - size_t loop = len, ctr = cleanse_ctr; - - if (ptr == NULL) - return; - - while (loop--) { - *(p++) = (unsigned char)ctr; - ctr += (17 + ((size_t)p & 0xF)); - } - p = memchr(ptr, (unsigned char)ctr, len); - if (p) - ctr += (63 + (size_t)p); - cleanse_ctr = (unsigned char)ctr; + memset_func(ptr, 0, len); }
另请参见问题455：在OpenSSL的GitHub上重新实现非asm OPENSSL_cleanse（） 。