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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96000C636CD for ; Fri, 10 Feb 2023 18:28:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2967428000F; Fri, 10 Feb 2023 13:28:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 248AB280003; Fri, 10 Feb 2023 13:28:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1361128000F; Fri, 10 Feb 2023 13:28:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 020C6280003 for ; Fri, 10 Feb 2023 13:28:23 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BABD2A02C6 for ; Fri, 10 Feb 2023 18:28:22 +0000 (UTC) X-FDA: 80452217244.01.F919D80 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf16.hostedemail.com (Postfix) with ESMTP id F1265180015 for ; Fri, 10 Feb 2023 18:28:20 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676053701; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8N4wrGVcwiBGmfA2/Guzapu5gF1TGABEtfn81WOTSKE=; b=vi1bM7sjem/+Z43yGtAwOhtbjFASfDdTrep73anfvUV/u5HC54A2FWGeVt7XlUxiq9S9IK AzDKO2079J436cekyplETK85I8zABEMhHqbfK5bS+Aj9RoVBfvD/sfDyc514zWQqDWehxf P2rZexrHo76gBSrWXOSnDAz0yACHdwo= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676053701; a=rsa-sha256; cv=none; b=Bt3T+Ng7bxTeE5a6ZGMH/wHVvAZBFyDaFD0iqdWN4IjwyerwkTWKmvZwFma+I+f4hdOxOK ALJxzR1Xf6iZKRXfpyzU+RzJwFPRYSBdPKXiBBODiIiiJxfgb4rLFEQeb1thr9r6cDbvoV NbJZRvP2zOZzN0dftVlFK176FJLVRrU= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 617EEB824BF; Fri, 10 Feb 2023 18:28:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DCD4CC433EF; Fri, 10 Feb 2023 18:28:15 +0000 (UTC) Date: Fri, 10 Feb 2023 18:28:12 +0000 From: Catalin Marinas To: Peter Collingbourne Cc: Qun-wei Lin =?utf-8?B?KOael+e+pOW0tCk=?= , "andreyknvl@gmail.com" , Kuan-Ying Lee =?utf-8?B?KOadjuWGoOepjik=?= , Guangye Yang =?utf-8?B?KOadqOWFieS4mik=?= , "linux-mm@kvack.org" , Chinwen Chang =?utf-8?B?KOW8temMpuaWhyk=?= , "kasan-dev@googlegroups.com" , "ryabinin.a.a@gmail.com" , "linux-arm-kernel@lists.infradead.org" , "vincenzo.frascino@arm.com" , "will@kernel.org" Subject: Re: [PATCH v2 0/4] kasan: Fix ordering between MTE tag colouring and page->flags Message-ID: References: <20220610152141.2148929-1-catalin.marinas@arm.com> <66cc7277b0e9778ba33e8b22a4a51c19a50fe6f0.camel@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: kad5wt4w9ktrdmkrq8dctqugyaa9jmk7 X-Rspamd-Queue-Id: F1265180015 X-HE-Tag: 1676053700-55165 X-HE-Meta: U2FsdGVkX19JLYP4829uCW/fh8UllYD7tFBk5d2K/KygYiwsmugWTANbcDhIYNTv6mwCOO7KHFrDamwt5vQlRqtGSETu+EtZsCwB+y4jbDEoMYodWOhv7+xx3LD3uSWzaTlDHDTyKdwBDCzIiV3gFHgOxIb7FVWciNxY5qdvT15PkfEC6fn3rf3AFqPc6tk0mKJdDlFN4pZSl5wCIxs1/CO5sBT0u5WwPZBvMF5yhjZxF/6DocDh+Qt8jF4hzM2TLe6QbeW8trMXfJtn6bGv2mEj/nYNMm1raJaBgFBqf8qXaQKECdKwy6tm4GmWOVS8GwZFWofFczBbIpFV+nFZfY5fbSU6Bc8iMFVXiHsxUUfAVL//9RajfFQHjsUWDcYdf6CozsXdISs8bzOvWgbHU8p9HLqTQ7Uj5ZIe651ap7WASZp77KZSWOy5QZnZPpd2yCYz/qXY/l/1T3lqr3bEQSYvzu402/ZtMZYKMKXdxZkoR4iN4/svu2WVjpEgFu8eFW66p02pKy9h9pYyAgOqnSvr6RYGZtDp58z1EMbs2iTRNs3KM3D2X5tc0i8oAm0HLviALetijfeWXBlhWbBjjb6b4gN7aK0QVUoaJTZy4KCX5zYNMTzlA/FiCNImVReu3FBQJN2rnsugZnF4Ig3Nb2wEdRLm62IFUAODfmyQeu/3ddOLQbKvGiNNvaZO/6l5Jvw0SDKbSBcWSbiAHWNd67VacIbcWQaVGAC+N9CtLv7H6jvsrNPtgfE2y1hXTjRcYaK0SkjjqJgq+qMbs7fFydyp0KJw04ATYYNxaxEXO5urkuizhQ9YEchneuUmP3yta8DIowOajITbXJkwPNcU9NhbWlLVYnzo+X8Kcl7iwJy/EBdA39+FzMxYvgPOZIXfi8Sa7tcm54g+3gPHIRe+AWUycq4V5c4dmTCsDXzIOkfZNPs+SStTLNCyH3QPV5Dot2yuHJ0PWMYtdetCkMn /c592RUu 6Vbq+mKF7KfNHg6IifO+l2SieBrs+O/RxZNWYvUK9yM6tfTgUq+ZuZAkGOMypzJqPVRV9J5FKmrwQSIwk0RjNZsK73cPOUEM9cq5a1WrirV821/+k7suJpPE2CV7P5RtHZGhtL5jY6tMHy04XJdJxgJfCAhfYMCwLCcgj+JJXhv+pnQipLlvwal3Y1bcsMK2ifTq7ahN/6MVa0Qx3GyN3zpgNfacqcsfB0j6sI51Bv8jxdXfszA+eXvntJEdG2al4vBgmqtOjT5ttK31DgSlSIK255RGcaw8ipLFiWuBXnJ/brQ3wdMZ1Suzdz7kk3lTZB5mv2N139cwJIbZxNpi8CpVsfO1/g3NIUTvJRr1cD84quZoS2IS4CSNh2vphGnAjhfQ2P3gKX/T1/IRtDHv+PSxroHy2oi37pNSyT2N2PKvhiF80hqKdpwgC6G4EpBpeO4nAbZGrHq9/ERMjUyChys2jYgUL3nfXmfM3r8tnPoTQsJ1I5y9Ih/NHpdbpXyL5HqkZWwL8YQreUUTSVgm8SHgytoZTb4irVmYuQSntjl36YHE= 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: Hi Peter, On Thu, Feb 09, 2023 at 10:19:20PM -0800, Peter Collingbourne wrote: > Thanks for the information. We encountered a similar issue internally > with the Android 5.15 common kernel. We tracked it down to an issue > with page migration, where the source page was a userspace page with > MTE tags, and the target page was allocated using KASAN (i.e. having > a non-zero KASAN tag). This caused tag check faults when the page was > subsequently accessed by the kernel as a result of the mismatching tags > from userspace. Given the number of different ways that page migration > target pages can be allocated, the simplest fix that we could think of > was to synchronize the KASAN tag in copy_highpage(). > > Can you try the patch below and let us know whether it fixes the issue? > > diff --git a/arch/arm64/mm/copypage.c b/arch/arm64/mm/copypage.c > index 24913271e898c..87ed38e9747bd 100644 > --- a/arch/arm64/mm/copypage.c > +++ b/arch/arm64/mm/copypage.c > @@ -23,6 +23,8 @@ void copy_highpage(struct page *to, struct page *from) > > if (system_supports_mte() && test_bit(PG_mte_tagged, &from->flags)) { > set_bit(PG_mte_tagged, &to->flags); > + if (kasan_hw_tags_enabled()) > + page_kasan_tag_set(to, page_kasan_tag(from)); > mte_copy_page_tags(kto, kfrom); Why not just page_kasan_tag_reset(to)? If PG_mte_tagged is set on the 'from' page, the tags are random anyway and page_kasan_tag(from) should already be 0xff. It makes more sense to do the same for the 'to' page rather than copying the tag from the 'from' page. IOW, we are copying user-controlled tags into a page, the kernel should have a match-all tag in page->flags. > Catalin, please let us know what you think of the patch above. It > effectively partially undoes commit 20794545c146 ("arm64: kasan: Revert > "arm64: mte: reset the page tag in page->flags""), but this seems okay > to me because the mentioned race condition shouldn't affect "new" pages > such as those being used as migration targets. The smp_wmb() that was > there before doesn't seem necessary for the same reason. > > If the patch is okay, we should apply it to the 6.1 stable kernel. The > problem appears to be "fixed" in the mainline kernel because of > a bad merge conflict resolution on my part; when I rebased commit > e059853d14ca ("arm64: mte: Fix/clarify the PG_mte_tagged semantics") > past commit 20794545c146, it looks like I accidentally brought back the > page_kasan_tag_reset() line removed in the latter. But we should align > the mainline kernel with whatever we decide to do on 6.1. Happy accident ;). When I reverted such calls in commit 20794545c146, my assumption was that we always get a page that went through post_alloc_hook() and the tags were reset. But it seems that's not always the case (and probably wasteful anyway if we have to zero the tags and data on a page we know we are going to override via copy_highpage() anyway). The barrier doesn't help, so we shouldn't add it back. So, I'm fine with a stable fix but I wonder whether we should backport the whole "Fix/clarify the PG_mte_tagged semantics" series instead. -- Catalin