From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id 6102C3858D35 for ; Sat, 26 Sep 2020 17:07:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6102C3858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dalias@libc.org Date: Sat, 26 Sep 2020 13:07:11 -0400 From: Rich Felker To: Carlos O'Donell Cc: libc-alpha Subject: Re: RFC: malloc and secure memory. Message-ID: <20200926170710.GR3265@brightrain.aerifal.cx> References: <58adb753-aecf-d367-6dbe-bb475c4c4d2c@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58adb753-aecf-d367-6dbe-bb475c4c4d2c@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 17:07:13 -0000 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