From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id D7675386103A for ; Thu, 26 Nov 2020 15:48:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D7675386103A Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6524031B; Thu, 26 Nov 2020 07:48:52 -0800 (PST) Received: from [192.168.1.19] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AE1483F23F; Thu, 26 Nov 2020 07:48:51 -0800 (PST) Subject: Re: [PATCH v3 2/8] elf: Add a tunable to control use of tagged memory To: Siddhesh Poyarekar , "H.J. Lu" Cc: GNU C Library , Richard Earnshaw References: <20201123154236.25809-1-rearnsha@arm.com> <20201123154236.25809-3-rearnsha@arm.com> <378cba09-12c1-59de-578a-1ca3a84015c5@foss.arm.com> <2a2cbd34-8dbc-34af-c5ee-b7d0ef5b48a7@gotplt.org> <26b8b11e-919a-b6e0-ff5f-51e724faffb2@foss.arm.com> <8ddb9604-5a6d-a656-0585-57a1b26c39f6@gotplt.org> <87e8b15f-8c86-4b2c-a5e4-3e70631ea505@gotplt.org> <23a8ad00-a376-48ae-cc6a-2684261146a1@foss.arm.com> From: Richard Earnshaw Message-ID: <6173c59d-ee67-9499-ac61-c2dd37b56c67@foss.arm.com> Date: Thu, 26 Nov 2020 15:48:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3492.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, 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: Thu, 26 Nov 2020 15:48:56 -0000 On 26/11/2020 15:27, Siddhesh Poyarekar wrote: > On 11/26/20 7:45 PM, Richard Earnshaw wrote: >> Sure, I can do that if you really think it's the right thing (I presume >> this has already been done for other tunables on other architectures, so > > There's sysdeps/aarch64/dl-tunables.list too, so there's no additional > plumbing needed... > >> that there isn't a lot of additional plumbing needed).  But is it?  It >> seems odd to me that the generic malloc code would read a tunable that >> only existed in a particular sysdep configuration.  There has to exist >> some mechanism for the machine independent code to know that the tagging >> behaviour is needed. > > ... but I see your point.  How about if we look at the patchset as > follows, which should make it more clearer.  It doesn't really change > your patchset in any major way (other than fixing failures and review > comments), it's only to make the story behind it and hence the design > decisions more deliberate. > > The first part of the patchset (1-3) enables infrastructure to enable > memory tagging in glibc.  At the project level, this involves adding > tagging calls (can't call them hooks because that name's taken and also > invoke nightmares for some) in malloc to allow tagging malloc'd objects. >  The tagging calls are nops in the default case but support could be > added either at the architecture level or in the form of a software > implementation. > > The library could add more tag calls in other parts of the library to > colour them library-internal (e.g. dynamic linker data, glibc internal > data) but that's for later. > > This basically means that memory tagging becomes a library-wide concept > and hence the glibc.mem.tagging tunable and configury should be > implemented project-wide, i.e. the way you've done it with your v3 > patchset with just the tunable naming changed. > > The second part (6-8, assuming 4 and 5 get subsumed into 3) of the > patchset implements aarch64 architecture support for memory tagging. > This involves enabling tagging for the entire process using prctl at > startup and tagging malloc'd objects.  It is unavoidable that tunables > will eventually have processwide impact and not just in the library; > there's precedent for that in x86 CET. > > What do you think? I think it's exactly the way the patch set was structured, I just wasn't explicit in saying that :) > > On a slightly different but related point, you may want to think about > inheritance of the glibc.mem.tagging tunable when you work on v4, i.e.: > > 1. Should child processes inherit them?  If you're modeling it along the > lines of MALLOC_CHECK_ (i.e. diagnostics only) then you'd want to keep > it as default, i.e. no inheritance.  However if you model it as a > hardening feature, you may want to set security_level to IGNORE so that > children inherit tagging and forking doesn't become a way to escape > tagging protections. > > 2. Should setxid children inherit enabled memory tagging? Again if > you're modeling it as a hardening feature, then maybe you want to set > security_level to NONE so that it is inherited by setxid children.  I > think it will be the first tunable to cross that boundary if you decide > to take that route! > A good question. I'd say at this point it's a bit more of a debugging feature (at least until things have settled down); but longer term it may well become a hardening feature as well. Before we can go down that route, though we'll need to sort out how to mark binaries that are genuinely incompatible with MTE. We already know that python's object management code violates MTE assumptions, for example; either that will need to be fixed, or we'll need a route to automatically disable MTE when running programs like that. So perhaps for now, we'd want to inherit it through normal fork() type calls, but perhaps not for setxid at this stage, but we may want to widen it later. On the other hand, for a security feature you'd perhaps want a more robust (harder to turn off) mechanism than just modifying a user-level environment variable. R. > Siddhesh