Re: RFC: malloc and secure memory.

[Florian Weimer <fweimer@redhat.com>]

* Carlos O'Donell via Libc-alpha:

> 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.
>
> 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);
>   ...
>   /* Completely different TU, or scope... */
>   free (password_storage);

How is this going to work with existing out-of-tree mallocs?  Do you
want them all to change?  Why would these implementations want to add
the overhead to support memory they have not allocated?  How would they
discover the actual implementation of free to call?

If we want to add new allocator interfaces, they need to have completely
separate names, and should follow an existing, well-understood design
(e.g., the APR pool interfaces, libtalloc with its pointers-as-pools,
the Windows 2.x heap interfaces with its handles).

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill