From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id 52581393C85C for ; Sun, 27 Sep 2020 20:29:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 52581393C85C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fw@deneb.enyo.de Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1kMdI6-0006oX-GJ; Sun, 27 Sep 2020 20:29:02 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1kMdI6-0008Bu-Cc; Sun, 27 Sep 2020 22:29:02 +0200 From: Florian Weimer To: Rich Felker Cc: Carlos O'Donell , libc-alpha Subject: Re: RFC: malloc and secure memory. References: <58adb753-aecf-d367-6dbe-bb475c4c4d2c@redhat.com> <20200926170710.GR3265@brightrain.aerifal.cx> Date: Sun, 27 Sep 2020 22:29:02 +0200 In-Reply-To: <20200926170710.GR3265@brightrain.aerifal.cx> (Rich Felker's message of "Sat, 26 Sep 2020 13:07:11 -0400") Message-ID: <87wo0fklpt.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Sun, 27 Sep 2020 20:29:10 -0000 * 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 >>=20 >> The request is for a way to mark some allocations as "secure" >> and to give them special properties. >>=20 >> I wonder if we can't do this in some generic way: >>=20 >> - Make arenas a first class construct. >>=20 >> /* Get arena with special properties. */ >> malloc_arena *secure_arena =3D NULL; >> /* Get a handle to an arena that has secure heaps. If glibc can make th= is >> kind of arena and heap then it does, otherwise it returns NULL. */ >> secure_arena =3D malloc_arena_get (HEAP_SECURE); >> /* Does this glibc support his kind of arena? */ >> if (secure_arena =3D=3D NULL) >> abort(); >>=20 >> - 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 =E2=80=9Csecure=E2=80=9D 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=E2=80=94who 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.