RFC: malloc and secure memory.

[Rich Felker]

On Thu, Sep 24, 2020 at 04:56:59PM -0400, Carlos O'Donell via Libc-alpha wrote:
> In reviewing this discussion:
> https://github.com/systemd/systemd/pull/14213
> 
> The request is for a way to mark some allocations as "secure"
> and to give them special properties.
> 
> I wonder if we can't do this in some generic way:
> 
> - Make arenas a first class construct.
> 
> /* Get arena with special properties.  */
> malloc_arena *secure_arena = NULL;
> /* Get a handle to an arena that has secure heaps.  If glibc can make this
>    kind of arena and heap then it does, otherwise it returns NULL.  */
> secure_arena = malloc_arena_get (HEAP_SECURE);
> /* Does this glibc support his kind of arena?  */
> if (secure_arena == NULL)
>   abort();
> 
> - Bind the malloc call site to a specific arena with specific properties.

I don't see any plausible motivation for why a caller would want to do
this rather than just calling mmap. It's far less portable, more
error-prone (since it doesn't look like it would catch use of one type
where you meant the other, as opposed to with direct mmap where
passing it to free or vice versa would trap at some point), and more
complex to program for.

Is the answer just "for systemd reasons"?

> For example:
> 
>   /* malloc_arena takes an opaque arena pointer that is a global
>      variable that the implementation provides, a function pointer
>      the memory allocator routine e.g. malloc, and a size.  */
>   password_storage = malloc_arena (secure_arena, malloc, size);

Is the function pointer merely being used as a lookup key here? Or is
the intend that it would be implemented by changing some thread-local
context, calling the pointed-to function, then restoring it? I don't
see what you get by having this weird interface since the signature
has to match to make the call, and there are no other malloc-family
functions that match malloc's signature anyway.

Rich