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=-17.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,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=ham 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 C71D0C00A89 for ; Thu, 5 Nov 2020 11:35:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 18B9C2083B for ; Thu, 5 Nov 2020 11:35:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="sR+Li0rd" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 18B9C2083B 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 79AB96B00ED; Thu, 5 Nov 2020 06:35:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 74C446B00EE; Thu, 5 Nov 2020 06:35:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 661BE6B00EF; Thu, 5 Nov 2020 06:35:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0097.hostedemail.com [216.40.44.97]) by kanga.kvack.org (Postfix) with ESMTP id 1B1A16B00ED for ; Thu, 5 Nov 2020 06:35:25 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id AFF951EE6 for ; Thu, 5 Nov 2020 11:35:24 +0000 (UTC) X-FDA: 77450158968.15.sink49_1711b9f272c9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 886C41814B0C1 for ; Thu, 5 Nov 2020 11:35:24 +0000 (UTC) X-HE-Tag: sink49_1711b9f272c9 X-Filterd-Recvd-Size: 7171 Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com [209.85.215.195]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Thu, 5 Nov 2020 11:35:23 +0000 (UTC) Received: by mail-pg1-f195.google.com with SMTP id u4so1236858pgr.9 for ; Thu, 05 Nov 2020 03:35:23 -0800 (PST) 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=S+r/dPqbzqLZgGMdUBdXFU/WPqHd1cGIgABAmt0Dvlo=; b=sR+Li0rdCdEZxUspJsqWzrLwdV41Kif8THgslj84rvYxC+3GS6RGU4YDm7LxxhZpGl hMVkVHm8MpMC06dRTyzQnw75O8sPwOMZcFwb+mS/VrSvooJuaJic7QlLChi8xhRxrOV5 StW5T6h8dr8Tvwd2HcN5uq+OjpbzD6TGz2VRpMABHTJzohoUc8iUQGF9IInd3VAOEPUT WjWOQyYTdqtu2DqKREM/1OZTsZWeM3gVcSTCsw92YJuC7fgUmj5ZaoUoB5L6rr2XpPVp jhgxiipeBWSE2KIxN0youkKvbKfeewPT3yo9x4V3jsATYfGV/7qYUnURpysOOHfk8g9e 4uYg== 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=S+r/dPqbzqLZgGMdUBdXFU/WPqHd1cGIgABAmt0Dvlo=; b=hSX+hhmWud5JETPZEW2ptujkD4yBjZfgAz597eHQIyc3mTWqkRakQAGPHndOkvyK5y opY5hK7Am1qeIM2GHVjApRiNKb/DUZIfkJWjAYP2hAMJjwg/W3U949JjvwaLejfmERyD ia9nQ6Vm5HI4SHnwupSogxkm/oSEWBsOoQiQHNXXQbIcS5cBUFzeRb8jbBmqS174gkDj mZejHioQF9u+qAVHlCGmD3QC7Q4IYuSVYPwlLhmIcAKCUGvjUtgiWfRTt6LkkZ2+b2OS jujMOp/LDQ/muBwmTg0ag7eCl5ywgGV8P586ZsW6JQ+SGV9HORzAQuk6MU9ip10W93+F P8Sw== X-Gm-Message-State: AOAM5326BIcLJyoUkXe650oZ2os0oYx261UfBaJ9OK1mCUq2zqSm7fx6 bWfsXSRn/5MNYmbXCaGtDP2ZAZq3krF3u3SSbkT5LQ== X-Google-Smtp-Source: ABdhPJz5sk+8mrpiVJwpfQJJfLGN1y7X0ryA389G2TdXuKM8sPBNOqsF99oameI0mbSWpVXVORL2hdGuXyWo8v/P37E= X-Received: by 2002:a63:5153:: with SMTP id r19mr2005408pgl.130.1604576122878; Thu, 05 Nov 2020 03:35:22 -0800 (PST) MIME-Version: 1.0 References: <5e3c76cac4b161fe39e3fc8ace614400bc2fb5b1.1604531793.git.andreyknvl@google.com> <58aae616-f1be-d626-de16-af48cc2512b0@arm.com> In-Reply-To: <58aae616-f1be-d626-de16-af48cc2512b0@arm.com> From: Andrey Konovalov Date: Thu, 5 Nov 2020 12:35:11 +0100 Message-ID: Subject: Re: [PATCH v8 30/43] arm64: kasan: Allow enabling in-kernel MTE To: Vincenzo Frascino Cc: Catalin Marinas , Will Deacon , Dmitry Vyukov , Andrey Ryabinin , Alexander Potapenko , Marco Elver , Evgenii Stepanov , Branislav Rankov , Kevin Brodsky , Andrew Morton , kasan-dev , Linux ARM , Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" 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, Nov 5, 2020 at 12:13 PM Vincenzo Frascino wrote: > > Hi Andrey, > > On 11/4/20 11:18 PM, Andrey Konovalov wrote: > > Hardware tag-based KASAN relies on Memory Tagging Extension (MTE) > > feature and requires it to be enabled. MTE supports > > > > This patch adds a new mte_init_tags() helper, that enables MTE in > > Synchronous mode in EL1 and is intended to be called from KASAN runtime > > during initialization. > > > > The Tag Checking operation causes a synchronous data abort as > > a consequence of a tag check fault when MTE is configured in > > synchronous mode. > > > > As part of this change enable match-all tag for EL1 to allow the > > kernel to access user pages without faulting. This is required because > > the kernel does not have knowledge of the tags set by the user in a > > page. > > > > Note: For MTE, the TCF bit field in SCTLR_EL1 affects only EL1 in a > > similar way as TCF0 affects EL0. > > > > MTE that is built on top of the Top Byte Ignore (TBI) feature hence we > > enable it as part of this patch as well. > > > > seems that in this patch you dropped me as author. Would you mind to clarify the > reason? Sorry, a mistake while squashing/rebasing, will fix in the next version. > > > Signed-off-by: Vincenzo Frascino > > Co-developed-by: Andrey Konovalov > > Signed-off-by: Andrey Konovalov > > --- > > Change-Id: I4d67497268bb7f0c2fc5dcacefa1e273df4af71d > > --- > > arch/arm64/include/asm/mte-kasan.h | 6 ++++++ > > arch/arm64/kernel/mte.c | 7 +++++++ > > arch/arm64/mm/proc.S | 23 ++++++++++++++++++++--- > > 3 files changed, 33 insertions(+), 3 deletions(-) > > > > diff --git a/arch/arm64/include/asm/mte-kasan.h b/arch/arm64/include/asm/mte-kasan.h > > index 3a70fb1807fd..ae75feaea2d4 100644 > > --- a/arch/arm64/include/asm/mte-kasan.h > > +++ b/arch/arm64/include/asm/mte-kasan.h > > @@ -29,6 +29,8 @@ u8 mte_get_mem_tag(void *addr); > > u8 mte_get_random_tag(void); > > void *mte_set_mem_tag_range(void *addr, size_t size, u8 tag); > > > > +void __init mte_init_tags(u64 max_tag); > > + > > #else /* CONFIG_ARM64_MTE */ > > > > static inline u8 mte_get_ptr_tag(void *ptr) > > @@ -49,6 +51,10 @@ static inline void *mte_set_mem_tag_range(void *addr, size_t size, u8 tag) > > return addr; > > } > > > > +static inline void mte_init_tags(u64 max_tag) > > +{ > > +} > > + > > #endif /* CONFIG_ARM64_MTE */ > > > > #endif /* __ASSEMBLY__ */ > > diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c > > index 06ba6c923ab7..fcfbefcc3174 100644 > > --- a/arch/arm64/kernel/mte.c > > +++ b/arch/arm64/kernel/mte.c > > @@ -121,6 +121,13 @@ void *mte_set_mem_tag_range(void *addr, size_t size, u8 tag) > > return ptr; > > } > > > > +void __init mte_init_tags(u64 max_tag) > > +{ > > + /* Enable MTE Sync Mode for EL1. */ > > + sysreg_clear_set(sctlr_el1, SCTLR_ELx_TCF_MASK, SCTLR_ELx_TCF_SYNC); > > + isb(); > > I am fine with the approach of letting cpu_enable_mte() call directly > kasan_init_tags(), but how does it work of the other 2 implementation of KASAN? > Is it still called in arch_setup()? Yes, the other 2 modes are initialized in setup_arch(). > I would prefer to keep the code that initializes the sync mode in > cpu_enable_mte() (calling kasan_init_tags() before then that) This won't work, we'll later need to make the decision about whether to turn on MTE at all in KASAN runtime based on KASAN boot flags. > or in a separate > function since setting the mode has nothing to do with initializing the tags. This will work. Any preference on the name of this function? Alternatively we can rename mte_init_tags() to something else and let it handle both RRND and sync/async. Thanks!