using palloc/pfree for OpenSSL allocations with CRYPTO_set_mem_functions

Поиск
Список
Период
Сортировка
От Evan Czaplicki
Тема using palloc/pfree for OpenSSL allocations with CRYPTO_set_mem_functions
Дата
Msg-id CAF7GuPFpH-qTDrnkbrFgwkfDv6N5X3cqUkmRUYLz6jrs4YENSA@mail.gmail.com
обсуждение исходный текст
Ответы Re: using palloc/pfree for OpenSSL allocations with CRYPTO_set_mem_functions
Список pgsql-general
Дерево обсуждения
I noticed that OpenSSL has a CRYPTO_set_mem_functions function:

If no allocations have been done, it is possible to “swap out” the default implementations for OPENSSL_malloc(), OPENSSL_realloc() and OPENSSL_free() and replace them with alternate versions.

But a different technique is used in contrib/pgcrypto/openssl.c to work around the different allocation system of OpenSSL:

To make sure we don't leak OpenSSL handles on abort, we keep OSSLCipher objects in a linked list, allocated in TopMemoryContext. We use the ResourceOwner mechanism to free them on abort.

I see the particulars might have changed on the master branch though!

CRYPTO_set_mem_functions must be called before any uses of malloc/free though, so I believe it needs to be called right after the OPENSSL_init_ssl calls (e.g. in src/backend/libpq/be-secure-openssl.c and src/interfaces/libpq/fe-secure-openssl.c) for this to be possible.

Would it be desirable to do this? If not, why is the TopMemoryContext approach a better option? I do not understand the code quite well enough to evaluate the tradeoffs myself yet!

Best,
Evan

P.S. Searcthing all time with this query, I found one thread in 2018 that mentions CRYPTO_set_mem_functions, but in a different capacity. I hope I did not miss some other mention of it on the email lists!

В списке pgsql-general по дате отправления:

Предыдущее
От: Allan Kamau
Дата:
Сообщение: Re: building a singularity image from docker hub postgres image
Следующее
От: Johnathan Tiamoh
Дата:
Сообщение: Re: Postgresql BUG / Help Needed