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=-5.2 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 9C957C388F9 for ; Wed, 4 Nov 2020 17:47:51 +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 397D320BED for ; Wed, 4 Nov 2020 17:47:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="g1hi9bmz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 397D320BED Authentication-Results: mail.kernel.org; dmarc=fail (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=NYW5igqpNbGvKMr3CFB796GbZ1y7cXCzO2ZOHv2Kxrg=; b=g1hi9bmzKDfuLDK0OuVx1xh7y /Hd3RBTdgToJlAR40EE3N36Z+D86k3uFMZpD1NEvQYLAy1pk+hICpgB1+T8899I3Dp8HVE9z9gvF5 /LCPIfFdWrDfz0/rMauCxtSCBtdTQiq/r2G2Szz0ba8aurgYPq/D73Gk8U38WuY5BqJCREy4BikVO bbMmQyTkTnHNvSmaQZx4gMiJj6xSAKKs3heXbRxkfNsk6hx16H48dENTgTVquZyw9kN3pWj0G/Y8S Zix+T3gkgqd2EgSvVFaHwkkjzhAFZ9xozGPUR7Rw0rN8nesV+EeePhwKJLxmmqhMjjBkC5O5Qh56c HdiVAcJWA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kaMrJ-0000lt-2Y; Wed, 04 Nov 2020 17:46:09 +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 1kaMr7-0000hU-Qn for linux-arm-kernel@lists.infradead.org; Wed, 04 Nov 2020 17:46:02 +0000 Received: from gaia (unknown [2.26.170.190]) (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 3B2CF206F1; Wed, 4 Nov 2020 17:45:53 +0000 (UTC) Date: Wed, 4 Nov 2020 17:45:50 +0000 From: Catalin Marinas To: Peter Collingbourne Subject: Re: [PATCH v13 8/8] arm64: expose FAR_EL1 tag bits in siginfo Message-ID: <20201104174549.GG28902@gaia> References: <20201103183321.GB81026@C02TF0J2HF1T.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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-20201104_124558_071640_16CAE5F1 X-CRM114-Status: GOOD ( 24.20 ) 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 ARM , Andrey Konovalov , Helge Deller , Kevin Brodsky , Oleg Nesterov , "James E.J. Bottomley" , Kostya Serebryany , "Eric W. Biederman" , Linux API , David Spickett , Vincenzo Frascino , Will Deacon , Dave Martin , Evgenii Stepanov , Richard Henderson 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 On Tue, Nov 03, 2020 at 11:16:53AM -0800, Peter Collingbourne wrote: > On Tue, Nov 3, 2020 at 10:33 AM Catalin Marinas wrote: > > That said, I wonder whether we could solve this for MTE without new > > fields by always setting the tag in si_addr when si_code is SEGV_MTE*. > > This wouldn't solve the problem for MTE in the case where there is a > non-linear buffer overflow that extends into an unmapped page, in > which case we would get a SEGV_MAPERR that we would still need the tag > bits for. What I was thinking of is to only present the tags for SEGV_MTE* faults (tag check faults). Is the tag relevant for a SEGV_MAPERR fault? > > Alternatively, we could add a prctl() bit to require tagged si_addr. > > It's an option that we considered but I would be concerned about the > compatibility implications of this. In practice, on Android we would > always have this bit set, so applications would be exposed to the tag > bits in si_addr. If applications have previously relied on the > documented behavior that the tag bits are unset, they may get confused > by them now being set. It also wouldn't provide a way for the kernel > to communicate which tag bits are valid. It depends what you mean by application. If the MTE enabling and signal handling is done from zygote, I suspect the rest of the app won't install its own signal handlers, so they can't get confused. For standard Linux processes and glibc, the feature wouldn't be enabled by default even if MTE was turned on (we'd add a new prctl() bit). Anyway, I'm not saying we should go for this approach, just making sure that we explored all the options (sorry, should have read the previous 12 series ;)). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel