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=-8.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 55FA0C433E2 for ; Tue, 8 Sep 2020 16:31:23 +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 BA88B206A4 for ; Tue, 8 Sep 2020 16:31:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="VzOxAlov"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="sDezdMKJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BA88B206A4 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=q5Pm7qBBvw681Ivjat06YkhkXXFqiy/PpEmwMUpQ2oo=; b=VzOxAlovS1T9qPlZ5mBi1eM+T YWre6tvnQduf3qydnJgpfPmidRlge8qX1rceqUuThIzxE1dDtfdzpXVn1RT5FJ/Zj+FAhKEobGOOo WZzD25zxsRcdjag1kblev9FMU7r0Rfp88QFoeYf/1mo2lh9Ppzas+tVyRpmC4ZOTDP09B2VWK5lwP lxv+ZgB0ovNesWy1uQoWmuNvKIaESfNbfxXz5uOQqkDZERTKEKNcgxqTy5QTlFXOBpBoce1vFpsYo 7WPd6lDhZQoXpSqdpNTCsOUFy3wz3pg3SwBXPSHO6agfKP+i27fx0gmt+kRXdYj6JlG1Rqe4q/mOW npGTdKrkQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFfiv-0006Sj-HC; Tue, 08 Sep 2020 15:39:57 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFfit-0006SQ-RH for linux-arm-kernel@merlin.infradead.org; Tue, 08 Sep 2020 15:39:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=CzeQ9DdrbquynWH3MRxVx2h7XesAlGjIoWK9Q/P/Yxw=; b=sDezdMKJMm4WODv7qQfJBN6nhW VLTIzCzeeZGjyTR2G/z4jsSTOH7mLonvMvHe6MLEQSrv1TM47y1U1fafddOHFZL4Zp1uvnk5rOfCl OFp/hAJ+ncK0jCtDAgetFGVkpRt26MBeMCDGFHzx+crPkpxMryPCHCwfSaQQG80HP+y2/ywMFmstm 7qKEOGuk2POf0R8ktnlpQDx0AC8IDs5DzBo63r+oxiyza+LPvKuG/owVSjmRVFstWq/qDFM7CGfR9 kIOtOKgqA/Vur8Q//x/AD9UjqQTqK+q7z+acAAZk2eXyjOdYd1utlD1a3wR6sjiIEeSKkBArqI1ZD V/APM0mg==; Received: from mail.kernel.org ([198.145.29.99]) by casper.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFfio-0005bj-VV for linux-arm-kernel@lists.infradead.org; Tue, 08 Sep 2020 15:39:54 +0000 Received: from gaia (unknown [46.69.195.48]) (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 D6EA92463B; Tue, 8 Sep 2020 15:39:13 +0000 (UTC) Date: Tue, 8 Sep 2020 16:39:11 +0100 From: Catalin Marinas To: Andrey Konovalov Subject: Re: [PATCH 24/35] arm64: mte: Switch GCR_EL1 in kernel entry and exit Message-ID: <20200908153910.GK25591@gaia> References: <20200827103819.GE29264@gaia> <8affcfbe-b8b4-0914-1651-368f669ddf85@arm.com> <20200827121604.GL29264@gaia> 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-20200908_163951_814198_B6FE89BB X-CRM114-Status: GOOD ( 36.59 ) 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 , Marco Elver , Elena Petrova , Kevin Brodsky , Will Deacon , Branislav Rankov , kasan-dev , LKML , Linux Memory Management List , Alexander Potapenko , Evgenii Stepanov , Andrey Ryabinin , Andrew Morton , Vincenzo Frascino , Dmitry Vyukov 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, Sep 08, 2020 at 04:02:06PM +0200, Andrey Konovalov wrote: > On Thu, Aug 27, 2020 at 2:16 PM Catalin Marinas wrote: > > On Thu, Aug 27, 2020 at 11:56:49AM +0100, Vincenzo Frascino wrote: > > > On 8/27/20 11:38 AM, Catalin Marinas wrote: > > > > On Fri, Aug 14, 2020 at 07:27:06PM +0200, Andrey Konovalov wrote: > > > >> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c > > > >> index 7717ea9bc2a7..cfac7d02f032 100644 > > > >> --- a/arch/arm64/kernel/mte.c > > > >> +++ b/arch/arm64/kernel/mte.c > > > >> @@ -18,10 +18,14 @@ > > > >> > > > >> #include > > > >> #include > > > >> +#include > > > >> +#include > > > >> #include > > > >> #include > > > >> #include > > > >> > > > >> +u64 gcr_kernel_excl __read_mostly; > > > > > > > > Could we make this __ro_after_init? > > > > > > Yes, it makes sense, it should be updated only once through mte_init_tags(). > > > > > > Something to consider though here is that this might not be the right approach > > > if in future we want to add stack tagging. In such a case we need to know the > > > kernel exclude mask before any C code is executed. Initializing the mask via > > > mte_init_tags() it is too late. > > > > It depends on how stack tagging ends up in the kernel, whether it uses > > ADDG/SUBG or not. If it's only IRG, I think it can cope with changing > > the GCR_EL1.Excl in the middle of a function. > > > > > I was thinking to add a compilation define instead of having gcr_kernel_excl in > > > place. This might not work if the kernel excl mask is meant to change during the > > > execution. > > > > A macro with the default value works for me. That's what it basically is > > currently, only that it ends up in a variable. > > Some thoughts on the topic: gcr_kernel_excl is currently initialized > in mte_init_tags() and depends on the max_tag value dynamically > provided to it, so it's not something that can be expressed with a > define. In the case of KASAN the max_tag value is static, but if we > rely on that we make core MTE code depend on KASAN, which doesn't seem > right from the design perspective. The design is debatable. If we want MTE to run on production devices, we either (1) optimise out some bits of KASAN (configurable) or (2) we decouple MTE and KASAN completely and add new callbacks in the core code (slab allocator etc.) specific to MTE. My first choice is (1), unless there is a strong technical argument why it is not possible. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel