From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by sourceware.org (Postfix) with ESMTPS id 5EA8D388A40E for ; Fri, 25 Sep 2020 23:40:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5EA8D388A40E Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9FE295C0262 for ; Fri, 25 Sep 2020 19:40:07 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute4.internal (MEProxy); Fri, 25 Sep 2020 19:40:07 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddugddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfufhtvghf rghnucfqkdftvggrrhdfuceoshhorhgvrghrsehfrghsthhmrghilhdrtghomheqnecugg ftrfgrthhtvghrnhepvdekuefhtdfgvddvieeiudehheevgeeihffhtdevjedugeejtdev tdevtdeuvdejnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsohhrvggrrhesfhgrshhtmhgr ihhlrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 037EE668007A; Fri, 25 Sep 2020 19:40:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-355-g3ece53b-fm-20200922.004-g3ece53b9 Mime-Version: 1.0 Message-Id: In-Reply-To: <58adb753-aecf-d367-6dbe-bb475c4c4d2c@redhat.com> References: <58adb753-aecf-d367-6dbe-bb475c4c4d2c@redhat.com> Date: Fri, 25 Sep 2020 19:39:41 -0400 From: "Stefan O'Rear" To: "Stefan O'Rear via Libc-alpha" Subject: Re: RFC: malloc and secure memory. Content-Type: text/plain X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, 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: Fri, 25 Sep 2020 23:40:11 -0000 On Thu, Sep 24, 2020, at 4:56 PM, 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(); This is a bit late and I apologize, but is there any possibility of choosing a more descriptive name than SECURE for this? It's extremely vague, will mean something different for everybody, and because security is a situational and global property of systems, I would generally consider it incorrect to use "secure" to describe local and binary properties of subsystems. -s