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=-10.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 2DD43C433E9 for ; Fri, 5 Feb 2021 23:31:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EB64B64FE9 for ; Fri, 5 Feb 2021 23:31:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230490AbhBEXbA (ORCPT ); Fri, 5 Feb 2021 18:31:00 -0500 Received: from mail.kernel.org ([198.145.29.99]:40978 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232572AbhBEOXL (ORCPT ); Fri, 5 Feb 2021 09:23:11 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 6A7DE650F0; Fri, 5 Feb 2021 15:39:22 +0000 (UTC) Date: Fri, 5 Feb 2021 15:39:19 +0000 From: Catalin Marinas To: Vincenzo Frascino Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Andrew Morton , Will Deacon , Dmitry Vyukov , Andrey Ryabinin , Alexander Potapenko , Marco Elver , Evgenii Stepanov , Branislav Rankov , Andrey Konovalov Subject: Re: [PATCH v11 4/5] arm64: mte: Enable async tag check fault Message-ID: <20210205153918.GA12697@gaia> References: <20210130165225.54047-1-vincenzo.frascino@arm.com> <20210130165225.54047-5-vincenzo.frascino@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210130165225.54047-5-vincenzo.frascino@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 30, 2021 at 04:52:24PM +0000, Vincenzo Frascino wrote: > diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c > index 92078e1eb627..7763ac1f2917 100644 > --- a/arch/arm64/kernel/mte.c > +++ b/arch/arm64/kernel/mte.c > @@ -182,6 +182,37 @@ bool mte_report_once(void) > return READ_ONCE(report_fault_once); > } > > +#ifdef CONFIG_KASAN_HW_TAGS > +void mte_check_tfsr_el1(void) > +{ > + u64 tfsr_el1; > + > + if (!system_supports_mte()) > + return; > + > + tfsr_el1 = read_sysreg_s(SYS_TFSR_EL1); > + > + /* > + * The kernel should never trigger an asynchronous fault on a > + * TTBR0 address, so we should never see TF0 set. > + * For futexes we disable checks via PSTATE.TCO. > + */ > + WARN_ONCE(tfsr_el1 & SYS_TFSR_EL1_TF0, > + "Kernel async tag fault on TTBR0 address"); Sorry, I got confused when I suggested this warning. If the user is running in async mode, the TFSR_EL1.TF0 bit may be set by copy_mount_options(), strncpy_from_user() which rely on an actual fault happening (not the case with asynchronous where only a bit is set). With the user MTE support, we never report asynchronous faults caused by the kernel on user addresses as we can't easily track them. So this warning may be triggered on correctly functioning kernel/user. > + > + if (unlikely(tfsr_el1 & SYS_TFSR_EL1_TF1)) { > + /* > + * Note: isb() is not required after this direct write > + * because there is no indirect read subsequent to it > + * (per ARM DDI 0487F.c table D13-1). > + */ > + write_sysreg_s(0, SYS_TFSR_EL1); Zeroing the whole register is still fine, we don't care about the TF0 bit anyway. > + > + kasan_report_async(); > + } > +} > +#endif -- Catalin