From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bird.elm.relay.mailchannels.net (bird.elm.relay.mailchannels.net [23.83.212.17]) by sourceware.org (Postfix) with ESMTPS id AC5A9396ECD3 for ; Thu, 26 Nov 2020 15:28:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AC5A9396ECD3 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 4A1A8541720; Thu, 26 Nov 2020 15:28:01 +0000 (UTC) Received: from pdx1-sub0-mail-a90.g.dreamhost.com (100-96-8-96.trex.outbound.svc.cluster.local [100.96.8.96]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id AFCA7541565; Thu, 26 Nov 2020 15:28:00 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a90.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.10); Thu, 26 Nov 2020 15:28:01 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Whimsical-Callous: 7ac0afa34cd7ba70_1606404481083_232602595 X-MC-Loop-Signature: 1606404481082:4110294050 X-MC-Ingress-Time: 1606404481082 Received: from pdx1-sub0-mail-a90.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a90.g.dreamhost.com (Postfix) with ESMTP id 456FE7F13F; Thu, 26 Nov 2020 07:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gotplt.org; h=subject:to :cc:references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=gotplt.org; bh=rWzFI7 PI4LfUcsVEmUIfRWCSzhY=; b=hWOZPoHRhzgEVos9JFiJ6NhvqisqpkSOvXbVG5 DswGZcPrqwiSgL8L4oqYXW+wsuBZjp7Xq3CGCiJBDxWHA8NDHhpd7UDI4Gd3UF9r lSTvy4Gk3u6LtgY9SfjVK4Kf9FHQAEyZ4lUuw0YMlZH/Qydrr8JYF2h22PmPVV8Q NXr4g= Received: from [192.168.1.111] (unknown [1.186.101.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a90.g.dreamhost.com (Postfix) with ESMTPSA id B1BF57E670; Thu, 26 Nov 2020 07:27:56 -0800 (PST) Subject: Re: [PATCH v3 2/8] elf: Add a tunable to control use of tagged memory To: Richard Earnshaw , "H.J. Lu" Cc: Richard Earnshaw , GNU C Library 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> X-DH-BACKEND: pdx1-sub0-mail-a90 From: Siddhesh Poyarekar Message-ID: Date: Thu, 26 Nov 2020 20:57:50 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <23a8ad00-a376-48ae-cc6a-2684261146a1@foss.arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, 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:28:14 -0000 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? 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! Siddhesh