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=-14.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL 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 D00AFC433E2 for ; Tue, 8 Sep 2020 14:02:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5C93223C42 for ; Tue, 8 Sep 2020 14:02:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="p9feilB1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5C93223C42 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B72676B0003; Tue, 8 Sep 2020 10:02:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AFC4E6B0037; Tue, 8 Sep 2020 10:02:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9EB176B0055; Tue, 8 Sep 2020 10:02:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0051.hostedemail.com [216.40.44.51]) by kanga.kvack.org (Postfix) with ESMTP id 847826B0003 for ; Tue, 8 Sep 2020 10:02:33 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 48DA6180ACC34 for ; Tue, 8 Sep 2020 14:02:33 +0000 (UTC) X-FDA: 77240059386.09.ray84_1e0d542270d5 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id CF15E180AD81F for ; Tue, 8 Sep 2020 14:02:27 +0000 (UTC) X-HE-Tag: ray84_1e0d542270d5 X-Filterd-Recvd-Size: 5442 Received: from mail-pj1-f68.google.com (mail-pj1-f68.google.com [209.85.216.68]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Tue, 8 Sep 2020 14:02:18 +0000 (UTC) Received: by mail-pj1-f68.google.com with SMTP id q4so2151060pjh.5 for ; Tue, 08 Sep 2020 07:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tB5vJBBCtNhXMgKB2GrADyceasBad1luqBoSGuNUjz8=; b=p9feilB1M35mHPB65haOwv2e+Ui0Qw1FZR6nJHx+HtJ5jdCWL+Vw+aGtIfvQo1r1OJ 0aHmvXgoDtAt/sBoiUVFV59gpc7u5lw8lcsFx+Yj3j79cT4WAP1MKg/yMvt1A90Qnr8V sD47h4UkaS+Ytrx40Sw8u+S7bIUHR3X0fSnVhGHgJLbbSyVQN6TnKb/P8CQmNn6TI69v Vd+X3f7izf2lMBoCiIHx2Z3/Mn4O07a+wOiNjeYSiSi6/azINfDQiyib/FAzB+3VwhQU +MAAJBmSsxhesuQWvcBOlU6uNChiTz9g7zt9S1akiMJl+zb91tDeOjIiaIywtwJRjiVo LiZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tB5vJBBCtNhXMgKB2GrADyceasBad1luqBoSGuNUjz8=; b=H8sgmABvBqjLD3KKQOqEmpso/imJX70OfeYXUiHN17n5Hu+cXR2+EZeODlHtFS3gFT Gn48lVQQTsX1yS8saEaMP+YJH/tyHYvKTLojZJ/lBaoaNN/eS1LJ/BVlitA5Sk5DVXOz uVMmIIu8ezSaHHujDrbLqrch5AmLhkQThKFQRlxa9gSg0hch3ckiMmURDYhSkTUxITSd kdnWGyfge/hcDCoK5Cnt1kpKwG+Gdv2eAhx2cODhQgZ/PBMPoqAW9+MjILz675LGYGDK P8ptE/pNwbmIirJHJqLhzBAZgHvRJv8yGMuTizuDJy+TIY1NRtV4F7MLj/qrTUd1GgWD PsYg== X-Gm-Message-State: AOAM530zvPMVBMNfBF23xIY6M3j0wVfVkGjrF9YradKymeaJrv1urSEG /tjsc2l1uybrsIGNMpG0bWDM4vXISriQMTY2pWFK+w== X-Google-Smtp-Source: ABdhPJwVsPMlGPGLSvUSlwAf67m6wSrtn8ecy42/I0lrRYwzO3XiWHqxki87TpJgnhSMr6md8e+Pc2LRgwAFcX0H4MU= X-Received: by 2002:a17:90a:81:: with SMTP id a1mr3986021pja.136.1599573737858; Tue, 08 Sep 2020 07:02:17 -0700 (PDT) MIME-Version: 1.0 References: <20200827103819.GE29264@gaia> <8affcfbe-b8b4-0914-1651-368f669ddf85@arm.com> <20200827121604.GL29264@gaia> In-Reply-To: <20200827121604.GL29264@gaia> From: Andrey Konovalov Date: Tue, 8 Sep 2020 16:02:06 +0200 Message-ID: Subject: Re: [PATCH 24/35] arm64: mte: Switch GCR_EL1 in kernel entry and exit To: Catalin Marinas Cc: Vincenzo Frascino , Dmitry Vyukov , kasan-dev , Andrey Ryabinin , Alexander Potapenko , Marco Elver , Evgenii Stepanov , Elena Petrova , Branislav Rankov , Kevin Brodsky , Will Deacon , Andrew Morton , Linux ARM , Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: CF15E180AD81F X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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: 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.