Helgrind 报告的 OpenSSL libcrypto.1.0.0 CRYPTO_malloc() 中可能的数据竞争条件

Question

我在使用 Helgrind 测试多线程 (pthreads) 应用程序时遇到问题，报告 libcrypto.1.0.0 中的 CRYPTO_malloc() 中可能存在数百个数据竞争。

我已阅读并完全理解所有可用的文档，包括 Linux 网络编程权威指南第 255-259 页和http://www.openssl.org/docs/crypto/threads.html。

我的代码正在初始化静态和动态锁结构和回调，并注册线程ID回调：

CRYPTO_THREADID_set_callback(ssl_mitm_thread_id);
CRYPTO_set_dynlock_create_callback(ssl_mitm_dyn_create_lock);
CRYPTO_set_dynlock_lock_callback(ssl_mitm_dyn_locking_callback);
CRYPTO_set_dynlock_destroy_callback(ssl_mitm_dyn_destroy_lock);
ssl_mitm_lock_mutexes = (pthread_mutex_t*)malloc(CRYPTO_num_locks() *
  sizeof(pthread_mutex_t));
for(i = 0; i < CRYPTO_num_locks(); i++) {
  pthread_mutex_init(&ssl_mitm_lock_mutexes[i], NULL);
}
CRYPTO_set_locking_callback(ssl_mitm_locking_callback);

SSL_library_init();
SSL_load_error_strings();
...etc...

我在加锁回调函数中添加了debug语句，openSSL只是调用了已弃用的CRYPTO_set_locking_callback()，并没有使用新的动态加锁接口。

即便如此，它还是调用了旧的静态锁定函数，因此正在尝试线程同步，但 Helgrind 仍然认为存在很多可能的数据竞争。大多数（如果不是全部）都在 CRYPTO_malloc() 中。

那么，这个 Helgrind 是不是过于狂热了，还是它是 OpenSSL/libcrypto 中的一个错误？

例如

==20093== ----------------------------------------------------------------
==20093==
==20093== Possible data race during write of size 4 at 0x63BA368 by thread #3
==20093== Locks held: none
==20093==    at 0x604F0FE: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20093==    by 0x57F4186: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==20093==    by 0x57D20C4: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==20093==    by 0x57D62E1: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==20093==    by 0x57DF0B6: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
[snip] (SSL_connect() called)
==20093==
==20093== This conflicts with a previous write of size 4 by thread #6
==20093== Locks held: none
==20093==    at 0x604F0FE: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20093==    by 0x57E1673: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==20093==    by 0x57DF359: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
[snip] (SSL_connect() called)
==20093==
==20093== ----------------------------------------------------------------

从 SSL_read、SSL_write、SSL_connect 和 SSL_accept 等调用的 CRYPTO_malloc() 中还有其他数据竞争示例。

Answer 1

下面片段中的最后一行是 Helgrind 抱怨的代码行：

void *CRYPTO_malloc(int num, const char *file, int line)
        {
        void *ret = NULL;

        if (num <= 0) return NULL;

        allow_customize = 0;

allow_customize 全局变量在静态初始化中被初始化为1。此值用于确保在调用分配例程本身之后不调用 malloc 自定义函数（CRYPTO_set_mem... 和变体）。这个设置为值0 是在锁之外完成的。从技术上讲，如果一个线程尝试调用CRYPTO_...alloc 函数而另一个线程尝试为CRYPTO 设置自定义函数，则存在竞争条件，但这可以被视为应用程序错误。

Answer 2

这里是CRYPTO_malloc 的定义：

$ grep -R CRYPTO_malloc *
...
crypto/mem.c:void *CRYPTO_malloc_locked(int num, const char *file, int line)
crypto/mem.c:void *CRYPTO_malloc(int num, const char *file, int line)
...

CRYPTO_malloc_locked 试图将页面保留在内存中（而不是写入swap）；而不是线程安全的分配器。

CRYPTO_malloc 就是这样做的：

void *CRYPTO_malloc(int num, const char *file, int line)
    {
    void *ret = NULL;

    ...
    ret = malloc_ex_func(num,file,line);

    ...
    return ret;
    }

malloc_ex_func 在CRYPTO_set_mem_functions 中设置为default_malloc_ex。和default_malloc_ex。但我似乎找不到default_malloc_ex 的实现。

但是，CRYPTO_malloc_init 具有以下内容：

#define CRYPTO_malloc_init()    CRYPTO_set_mem_functions( \
    malloc, realloc, free)

所以看起来 C 运行时的 malloc 正在被使用。

您使用的 OpenSSL 版本是否支持线程？您可以通过包含<openssl/openssl.con.h> 进行测试，并测试是否定义了OPENSSL_THREADS。

这也应该有效：

$ cat /usr/local/ssl/include/openssl/opensslconf.h | grep -B 1 -A 1 -i thread

#ifndef OPENSSL_THREADS
# define OPENSSL_THREADS
#endif