Feedback-ID: ie0a040ee:Fastmail
Message-ID: <fdac1035-417c-40a2-8a0a-24b3cd4e9ce8@eisentraut.org>
Date: Mon, 11 Nov 2024 09:12:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pgcrypto: better memory management?...
To: Bear Giles <bgiles@coyotesong.com>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <CALBNtw6ovb10hZ5uVBVNTVU5TLY1ZPFoWzrMZEKBonq+e1kbMQ@mail.gmail.com>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <CALBNtw6ovb10hZ5uVBVNTVU5TLY1ZPFoWzrMZEKBonq+e1kbMQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/fdac1035-417c-40a2-8a0a-24b3cd4e9ce8%40eisentraut.org>
Precedence: bulk

On 08.11.24 03:15, Bear Giles wrote:
> The first is that openssl has supported custom memory management for a 
> very long time - I remember using it in the late 90s. The function is in 
> crypto.h
> 
>   typedef void *(*CRYPTO_malloc_fn)(size_t num, const char *file, int line);
>   typedef void *(*CRYPTO_realloc_fn)(void *addr, size_t num, const char 
> *file,
>                                      int line);
>   typedef void (*CRYPTO_free_fn)(void *addr, const char *file, int line);
> int CRYPTO_set_mem_functions(CRYPTO_malloc_fn malloc_fn,
>                                CRYPTO_realloc_fn realloc_fn,
>                                CRYPTO_free_fn free_fn);
> 
> The main benefit of this function is that it openssl-internal functions 
> will use the same memory pool as your application. I know the current 
> extension uses palloc/pfree but I didn't see a call to this function.

The problem with this kind of interface is that in PostgreSQL, the idea 
is behind using palloc() is that you usually don't need to take care to 
free the memory, because it is automatically freed at some appropriate 
time (end of row, end of query, end of transaction, etc.).  But an 
external library like openssl doesn't know that.  So it could happen 
that PostgreSQL automatically frees some data structure that openssl 
thinks should still exist.

This kind of problem definitely existed with libxml, which has a very 
similar interface.  So you'd have to do some very careful analysis 
whether this would be safe for openssl.  I suspect it's not worth the 
bother.

> The second item is that openssl also has these wonderful functions:
> 
> int CRYPTO_secure_malloc_init(size_t sz, size_t minsize);
> int CRYPTO_secure_malloc_done(void);
> void *CRYPTO_secure_malloc(size_t num, const char *file, int line);
> void *CRYPTO_secure_zalloc(size_t num, const char *file, int line);
> void CRYPTO_secure_free(void *ptr, const char *file, int line);
> void CRYPTO_secure_clear_free(void *ptr, size_t num,
>                                const char *file, int line);
> int CRYPTO_secure_allocated(const void *ptr);
> int CRYPTO_secure_malloc_initialized(void);
> size_t CRYPTO_secure_actual_size(void *ptr);
> size_t CRYPTO_secure_used(void);
> 
> void OPENSSL_cleanse(void *ptr, size_t len);
> 
> These functions address (at least) two potential vulnerabilities. First 
> it tweaks the memory block so it will never be written to the swap file, 
> and second it (iirc) also tweaks the memory block to reduce the access 
> permissions further than usual.

PostgreSQL does do this kind of thing already, see explicit_bzero(). 
Maybe we could do more.  This would need a more specific analysis and 
proposal.