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=-6.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 0C24DC4727C for ; Tue, 22 Sep 2020 16:57:21 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 74E1A22262 for ; Tue, 22 Sep 2020 16:57:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="TuzlSwtr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 74E1A22262 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=yKILt24rULi2jtSP7P4CFD8qEDFMt+5DznG2p9+IFoc=; b=TuzlSwtr4CYd7BCns4CQTG9yl 5KmK48+gnL9p8kgRIw0C2mnwBpSTktE++kSKFm8xOJxgFUlTCMZ0LNOwSVjr9yrMGGXXM0FbaBvO/ Hi55EkJUBNlVWu+PWS3uYxVENeUEdn4YO97saEcfEQ+jF3GEL9e6iXZwNsX9/OJn/rkhsUqguXilE m1yNi9eU13Yz8VdyPsFjevpG2wU4rquEdTxXUeQYc/hadEFG4Wlt9pxHfdBtwz3SyknpRMqOIhVf2 Gs4xm51Y0ifbkc3RqmUi0PZo0sZGIufSuXmu6y/UCCAjPuFJLyYiI7l92nm53Z6d3sKkOwChOqUUD rqN7BayXg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKlZq-0006TK-Jj; Tue, 22 Sep 2020 16:55:38 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKlZn-0006SD-Da for linux-arm-kernel@lists.infradead.org; Tue, 22 Sep 2020 16:55:36 +0000 Received: from gaia (unknown [31.124.44.166]) (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 332952071A; Tue, 22 Sep 2020 16:55:32 +0000 (UTC) Date: Tue, 22 Sep 2020 17:55:29 +0100 From: Catalin Marinas To: Szabolcs Nagy Subject: Re: [PATCH v9 29/29] arm64: mte: Add Memory Tagging Extension documentation Message-ID: <20200922165529.GH15643@gaia> References: <20200904103029.32083-1-catalin.marinas@arm.com> <20200904103029.32083-30-catalin.marinas@arm.com> <20200917081107.GA29031@willie-the-truck> <20200917090229.GA10662@gaia> <20200922155248.GA16385@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200922155248.GA16385@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200922_125535_620569_B4945D8D X-CRM114-Status: GOOD ( 34.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, libc-alpha@sourceware.org, Peter Collingbourne , Andrey Konovalov , Kevin Brodsky , linux-mm@kvack.org, Andrew Morton , Vincenzo Frascino , Will Deacon , Dave P Martin , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Szabolcs, On Tue, Sep 22, 2020 at 04:52:49PM +0100, Szabolcs Nagy wrote: > The 09/17/2020 10:02, Catalin Marinas wrote: > > On Thu, Sep 17, 2020 at 09:11:08AM +0100, Will Deacon wrote: > > > On Fri, Sep 04, 2020 at 11:30:29AM +0100, Catalin Marinas wrote: > > > > From: Vincenzo Frascino > ... > > > > Acked-by: Szabolcs Nagy > > > > > > I'm taking this to mean that Szabolcs is happy with the proposed ABI -- > > > please shout if that's not the case! > > > > I think Szabolcs is still on holiday. To summarise the past threads, > > AFAICT he's happy with this per-thread control ABI but the discussion > > went on whether to expand it in the future (with a new bit) to > > synchronise the tag checking mode across all threads of a process. This > > adds some complications for the kernel as it needs an IPI to the other > > CPUs to set SCTLR_EL1 and it's also racy with multiple threads > > requesting different modes. > > > > Now, in the glibc land, if the tag check mode is controlled via > > environment variables, the dynamic loader can set this at process start > > while still in single-threaded mode and not touch it at run-time. The > > MTE checking can still be enabled at run-time, per mapped memory range > > via the PROT_MTE flag. This approach doesn't require any additional > > changes to the current patches. But it's for Szabolcs to confirm once > > he's back. > > my thinking now is that for PROT_MTE use outside of libc we will need > a way to enable tag checks early so user code does not have to worry > about tag check settings across threads (coordinating the setting at > runtime seems problematic, same for the irg exclusion set). Yeah, such settings are better set at process start time. We can explore synchronising across threads with an additional PR_* flag but given the interaction with stack tagging and other potential races, it will need better coordination with user space and agree on which settings can be changed (e.g. exclusion mask may not be allowed). However, at this point, I don't see a strong case for such ABI addition as long as the application starts with some sane defaults, potentially driven by the user. > if we add a kernel level opt-in mechanism for tag checks later (e.g. > elf marking) or if the settings are exclusively owned by early libc > code then i think the proposed abi is ok (this is our current > agreement and works as long as no late runtime change is needed to the > settings). In the Android case, run-time changes to the tag checking mode I think are expected (usually via signal handlers), though per-thread. > i'm now wondering about the default tag check mode: it may be better > to enable sync tag checks in the kernel. it's not clear to me what > would break with that. this is probably late to discuss now and libc > would need ways to override the default no matter what, but i'd like > to know if somebody sees problems or risks with unconditional sync tag > checks turned on (sorry i don't remember if we went through this > before). i assume it would have no effect on a process that never uses > PROT_MTE. I don't think it helps much. We already have a requirement that to be able to pass tagged pointers to kernel syscalls, the user needs a prctl(PR_TAGGED_ADDR_ENABLE) call (code already in mainline). Using PROT_MTE without tagged pointers won't be of much use. So if we are to set different tag check defaults, we should also enable the tagged addr ABI automatically. That said, I still have a preference for MTE and tagged addr ABI to be explicitly requested by the (human) user either via environment variables or marked in an ELF note as "safe with/using tags". Given the recent mremap() issue we caused in glibc, I'm worried that other things may break with enabling the tagged addr ABI everywhere. Another aspect is that sync mode by default in a distro where glibc is MTE-aware will lead to performance regressions. That's another case in favour of the user explicitly asking for tag checking. Anyway, I'm open to having a debate on changing the defaults. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel