Re: using palloc/pfree for OpenSSL allocations with CRYPTO_set_mem_functions

Evan Czaplicki <evancz(at)gmail(dot)com> writes:
> I noticed that OpenSSL has a CRYPTO_set_mem_functions
> <https://www.openssl.org/docs/man3.2/man3/CRYPTO_set_mem_functions.html>
> 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 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.

> 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!

Seems to me that these address different purposes. If we put in a
CRYPTO_set_mem_functions layer, I doubt that we'd have any good idea
of which allocations are used for what. So we could not replace what
pgcrypto is doing with a simple MemoryContextReset (even if we cared
to assume that freeing an OSSLCipher involves only free() operations
and no other resources). I think the only real win we'd get from
such a layer is that OpenSSL's allocations would be better exposed
for accounting purposes, eg the pg_backend_memory_contexts view.
That's not negligible, but I don't find it a compelling reason to
do the work, either.

regards, tom lane