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.6 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 0A1F9C49EA5 for ; Thu, 24 Jun 2021 16:54:12 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 2FE4761407 for ; Thu, 24 Jun 2021 16:54:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2FE4761407 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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=MucPb0fUcWUpsQfSfWO3Y/yz/nJVIG3L/D69PThKt1w=; b=MWmScahfdbWvh9 R0x0dToRP/pc0vSc2liJMMcRvjGh/7go3+fAS8moKq0Qsau5oZiYAAsWc0YAXYDJKeskwRd2KkDeN avBV1Ms/N9O49Cv+9Dt86WDc7wmnrMzp6V6G4GO1Q/VHQrf8rJTq1iXp6/DkQfyUu/k9fxC4f2IcE 5NcnRnTbrqQDUMIvnaLEdLYPFVih69Ii2xlF96Ukmxs8F1HSadX8bqAbrmZBEKCsL18/ULJQoNTtb ad7uM6ChtfVlrym4SdLJc7h4SuFf7Eg16izsvNJPD1rnpv/9GBPPLlbOCdevvH2DZAmC0qM909L0Q AjTWnQPr3rQ0vbkMIXcA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwSaj-00FZ3a-U6; Thu, 24 Jun 2021 16:52:38 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwSae-00FZ24-QH for linux-arm-kernel@lists.infradead.org; Thu, 24 Jun 2021 16:52:35 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2866E61407; Thu, 24 Jun 2021 16:52:30 +0000 (UTC) Date: Thu, 24 Jun 2021 17:52:28 +0100 From: Catalin Marinas To: Szabolcs Nagy Cc: Peter Collingbourne , Will Deacon , Vincenzo Frascino , Evgenii Stepanov , Linux ARM , Tejas Belagod Subject: Re: [PATCH v5] arm64: mte: allow async MTE to be upgraded to sync on a per-CPU basis Message-ID: <20210624165228.GB25097@arm.com> References: <20210615203807.3582804-1-pcc@google.com> <20210617215829.GD25403@willie-the-truck> <20210618150953.GH16116@arm.com> <20210621123936.GB29283@willie-the-truck> <20210621151858.GC11552@arm.com> <20210621173902.GA29713@willie-the-truck> <20210621185036.GD11552@arm.com> <20210623085530.GF13058@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210623085530.GF13058@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-20210624_095232_934776_A78482B6 X-CRM114-Status: GOOD ( 49.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Wed, Jun 23, 2021 at 09:55:30AM +0100, Szabolcs Nagy wrote: > The 06/22/2021 11:37, Peter Collingbourne wrote: > > On Mon, Jun 21, 2021 at 11:50 AM Catalin Marinas > > wrote: > > > On Mon, Jun 21, 2021 at 06:39:02PM +0100, Will Deacon wrote: > > > > On Mon, Jun 21, 2021 at 04:18:59PM +0100, Catalin Marinas wrote: > > > > > Given that there are no real users of MTE yet, we have some choice of > > > > > tweaking the ABI, backporting to 5.10. The question: is the expectation > > > > > that the sysfs forcing of TCF is limited to deployments where the user > > > > > space is tightly controlled (e.g. Android with most apps starting from > > > > > zygote) or we allow it to become more of a general hint of what's the > > > > > fastest check on a CPU? If the former, I'm fine with forcing without any > > > > > additional bit, though I'd still prefer the opt-in. For the latter, I'd > > > > > like some wider discussion with non-Android folk on what they expect > > > > > from the TCF setting. Otherwise simply using PROT_MTE would may lead to > > > > > tag check faults. > > > > > > > > I don't think there's anything Android-specific here. The problem being > > > > solved concerns big/little SoCs with MTE, and I think it's up to the > > > > distribution how the sysfs stuff is used. > > > > > > But distros don't control what applications are running, so most likely > > > they would disable the sysfs control entirely. At that point, the > > > feature becomes primarily an Android play. > > > > > > Anyway, I'm not dead against forcing of the TCF mode regardless of the > > > user choice but I'd like to ensure that we don't miss other use-cases or > > > that we don't make the sysfs control an expert-only feature. > > > > > > Adding Szabolcs to get a view from the glibc perspective. > > Adding Tejas as he will look at memory tagging in glibc. Thanks. Is there any MTE support in mainline glibc? If not, we may have another chance of adjusting the ABI. > > Given these diverging opinions my view is that we should choose > > whichever option leaves our options open for the future. For example, > > imagine that we make the ABI change now such that upgrades may happen > > for all applications and we don't have PR_MTE_DYNAMIC_TCF. This means > > that applications no longer have a guarantee of their TCF mode which > > may preclude some use cases (if we add an opt out later, applications > > will be affected when running on the kernel versions between when we > > changed the ABI and when we added the opt out). On the other hand, if > > we introduce PR_MTE_DYNAMIC_TCF, we can always make the ABI change > > later and start ignoring the PR_MTE_DYNAMIC_TCF flag at that point. > > > > Maybe the best compromise would be to change the ABI and at the same > > time add the opt out, but I don't have a strong opinion. > > so the observable difference between async mode and async mode > upgraded to sync mode is that async mode allows to ignoring the fault > and things can continue, while in sync mode the program cannot move > forward in case of a fault since the pc is still at the faulting > instruction? Yes. Would an application find the async mode useful or it can be freely overridden by the kernel (well, a user via sysfs)? > may be we can have a mode where the cpu is in sync mode checks but the > kernel steps over the faulting instruction before reporting it? so > emulating async semantics (in a slow and complicated way..), but > guaranteeing (almost) immediate faults for better debugging/security. It's a pretty complex step over (or emulate), so I wouldn't go there. The user signal handler could disable tag checking altogether (PSTATE.TCO) and continue. > personally i don't see a big issue with a mode that says "either sync > or async check behaviour" and user code has to deal with it, however.. The question is more about whether we still want to keep the current user program choice of sync vs async (vs the new asymmetric mode in 8.7). If the user wouldn't care, we just override it from the kernel without any additional PR_ flag for opting in (or out). > the per cpu setting is a bit nasty: can the kernel decide which cpu > should use sync and which async? or a privileged user will have to > fiddle with sysfs settings on every system to make this useful? The proposed interface is sysfs. I think that's not relevant to the user application since it wouldn't have control over it anyway. What's visible is that it cannot rely on the mode it requested, not even for the lifetime of a thread (as it may migrate between CPUs). Do you see any issues with this? For Android, it's probably fine but if other programs cannot cope (or need the specific mode requested), we'd need a new control (for opt-in or opt-out). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel