From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9914EC433DF for ; Mon, 22 Jun 2020 17:17:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4C97B20732 for ; Mon, 22 Jun 2020 17:17:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C97B20732 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B14CD6B0025; Mon, 22 Jun 2020 13:17:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC5E86B0026; Mon, 22 Jun 2020 13:17:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9DA646B0027; Mon, 22 Jun 2020 13:17:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0001.hostedemail.com [216.40.44.1]) by kanga.kvack.org (Postfix) with ESMTP id 7F4736B0025 for ; Mon, 22 Jun 2020 13:17:43 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 248111803E8DB for ; Mon, 22 Jun 2020 17:17:43 +0000 (UTC) X-FDA: 76957504806.27.heart25_2702e6e26e34 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 30F0916D26 for ; Mon, 22 Jun 2020 17:17:41 +0000 (UTC) X-HE-Tag: heart25_2702e6e26e34 X-Filterd-Recvd-Size: 4757 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Mon, 22 Jun 2020 17:17:39 +0000 (UTC) Received: from gaia (unknown [2.26.170.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7F0A120707; Mon, 22 Jun 2020 17:17:36 +0000 (UTC) Date: Mon, 22 Jun 2020 18:17:34 +0100 From: Catalin Marinas To: Peter Collingbourne Cc: Kevin Brodsky , Linux ARM , Will Deacon , Marc Zyngier , Vincenzo Frascino , Szabolcs Nagy , Richard Earnshaw , Andrey Konovalov , linux-mm@kvack.org, linux-arch@vger.kernel.org, Branislav Rankov , Dave P Martin Subject: Re: [PATCH 20/22] arm64: mte: Allow user control of the excluded tags via prctl() Message-ID: <20200622171716.GC10226@gaia> References: <20191211184027.20130-1-catalin.marinas@arm.com> <20191211184027.20130-21-catalin.marinas@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 30F0916D26 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Peter, Revisiting the gcr_excl vs gcr_incl decision, so reviving an old thread. On Mon, Dec 16, 2019 at 09:30:36AM -0800, Peter Collingbourne wrote: > On Mon, Dec 16, 2019 at 6:20 AM Kevin Brodsky wrote: > > In this patch, the default exclusion mask remains 0 (i.e. all tags can be generated). > > After some more discussions, Branislav and I think that it would be better to start > > with the reverse, i.e. all tags but 0 excluded (mask = 0xfe or 0xff). > > > > This should simplify the MTE setup in the early C runtime quite a bit. Indeed, if all > > tags can be generated, doing any heap or stack tagging before the > > PR_SET_TAGGED_ADDR_CTRL prctl() is issued can cause problems, notably because tagged > > addresses could end up being passed to syscalls. Conversely, if IRG and ADDG never > > set the top byte by default, then tagging operations should be no-ops until the > > prctl() is issued. This would be particularly useful given that it may not be > > straightforward for the C runtime to issue the prctl() before doing anything else. > > > > Additionally, since the default tag checking mode is PR_MTE_TCF_NONE, it would make > > perfect sense not to generate tags by default. > > This would indeed allow the early C runtime startup code to pass > tagged addresses to syscalls, I guess you meant that early C runtime code won't get tagged stack addresses, hence they can be passed to syscalls. Prior to the prctl(), the kernel doesn't accept tagged addresses anyway. > but I don't think it would entirely free > the code from the burden of worrying about stack tagging. Either way, > any stack frames that are active at the point when the prctl() is > issued would need to be compiled without stack tagging, because > otherwise those stack frames may use ADDG to rematerialize a stack > object address, which may produce a different address post-prctl. If you want to guarantee that ADDG always returns tag 0, I guess that's only possible with a default exclude mask of 0xffff (or if you are careful enough with the start tag and offset passed). > Setting the exclude mask to 0xffff would at least make it more likely > for this problem to be detected, though. I thought it would be detected if we didn't have a 0xffff default exclude mask. With only tag 0 generated, any such problem could be hidden. > If we change the default in this way, maybe it would be worth > considering flipping the meaning of the tag mask and have it be a mask > of tags to allow. That would be consistent with the existing behaviour > where userspace sets bits in tagged_addr_ctrl in order to enable > tagging features. The first question is whether the C runtime requires a default GCR_EL1.Excl mask of 0xffff (or 0xfffe) so that IRG, ADDG, SUBG always generate tag 0. If the runtime is fine with a default exclude mask of 0, I'm tempted to go back to an exclude mask for prctl(). (to me it feels more natural to use an exclude mask as it matches the ARM ARM definition but maybe I stare too much at the hardware specs ;)) -- Catalin