Re: RFC: malloc and secure memory.

[Florian Weimer <fw@deneb.enyo.de>]

* 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.

Many systems only allow 64 KiB of non-swappable memory per process, so
calling mmap (followed by mlock) would be quite wasteful and restrict
the number of active allocations to 16 with a 4 KiB page size.

There are various competing ideas what “secure” should mean in this
context, so maybe it's supposed to be about something else, and the 64
KiB wouldn't apply.  It would be tough to get multiple libraries to
coordinate the best use of this space even with a finer-grained
allocator—who wants to use non-secure memory for their data?

But I think the general idea to require that programers open-code
matching allocator and deallactor calls is not too onerous.  If it is,
the next village down the road has std::allocator on offer.