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 A4FD4C64EC7 for ; Fri, 10 Feb 2023 19:04:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2F114280014; Fri, 10 Feb 2023 14:04:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A57E280003; Fri, 10 Feb 2023 14:04:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 141FC280014; Fri, 10 Feb 2023 14:04:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id F29CF280003 for ; Fri, 10 Feb 2023 14:04:02 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C72F6120F6B for ; Fri, 10 Feb 2023 19:04:02 +0000 (UTC) X-FDA: 80452307124.07.B4808AA Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by imf21.hostedemail.com (Postfix) with ESMTP id 022D21C0012 for ; Fri, 10 Feb 2023 19:03:59 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=F0LPuzdB; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf21.hostedemail.com: domain of pcc@google.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=pcc@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676055840; 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:dkim-signature; bh=NTv3JGlLIZKXeoBIClnjALsg1EOVt48oB8d6Klv1b7A=; b=4G21nKcvJF97Dt0WuDV8KeuCm5HSK5WdMYStAK4OCxyZ4zAv9bnUMG8F31f93oM9DWknV2 qNcDP92ZbyDpdHgZ4VfYuYRTMVi8uNLKIIUg4RsinjOFWUT3nB35riuApZmOQpbbFO/+AZ 4VGc6MsmKzINloftl4SMJCVTqFDk7T8= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=F0LPuzdB; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf21.hostedemail.com: domain of pcc@google.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=pcc@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676055840; a=rsa-sha256; cv=none; b=0VPeqltO4+tjrRyR1YTuvNy+3BVeWk0znGSzPkptXa/8ENGodtOtN27xIK00dR+cyYInmJ bPwMoAhrSi32ee5wQSG85D15/+XPNsmTx+FgNElgqkZp7F7Zus7sB5QRTx4pA4b6yKXHYq wa2v6FR78+Ri5jVlSRoYjH+MkHt0EbE= Received: by mail-wm1-f47.google.com with SMTP id bg26so4556937wmb.0 for ; Fri, 10 Feb 2023 11:03:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NTv3JGlLIZKXeoBIClnjALsg1EOVt48oB8d6Klv1b7A=; b=F0LPuzdBfA9dywCViF8jcsoqw3v7VBytbkOTdTGMEqVQCOSHxAZqnB4qE44tfQB/SI FBLlhDMjBQJ0Te0d+tHd9QvzLlIOdRljZkWVrJBmxhR+TWYVtbNr6pLWD0jyY4HQnnEd UBhoIbt65O9aUxogSNrL3t0ubu3rGB55Ym9IvhaUJamn9aTuGRumwECkfzdHA34gjLHR JzcqtFDxeMUPbpUmeTzhtsDT4w5zEGp3g/EWqwi3kKchLSe9wli3KrFH9rKV2IrAFdwq vFRz8ewdj6SwCfvD3oBDh4xGd2lybY6lS8BGQKgqEBPjNqcoqGaT3XRj2/V0B5Amgn7E UdtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NTv3JGlLIZKXeoBIClnjALsg1EOVt48oB8d6Klv1b7A=; b=zClwQDzo/3CiZlLngi3dYasiEvgbbEUeaSLX2+0qcrTCCfcz3tl4LK1vuQ8KonHcq1 2kv4Ovi/WxbgZ08Shr+j5xbudLI/gzAxXrXDOJSK5QT5RKprQtsVfsimyYCJL/5nqOnp 2gCAx5GacEGkn/+cOFulzeFKei+V5YRqJ8a361QHGW9QTO+mFvezZWahwTC+7vKIv6uv yCJzPxBezaJxSYo50slM85sd3zd9aPAsvkWjGZAjqtWovLFs22pKOxTioqLA1XfE/r9S bfQSCTnPV8KL7jEU1M+UA7B3w29c9IHH/CtHMfDvc0o4HPg7GVo7UXaCoKB2hpiJmHkL VKrA== X-Gm-Message-State: AO0yUKWhrFC7AGOCU9E/Dco2kckY79bi5mw918eKdit7rz+zIAmPIkvt RYySs+DVIqI7Vm6Bn3M9TlyMH7KKkNCGtpZ/sdfVpg== X-Google-Smtp-Source: AK7set88sRdrr6A/npcR48n7DtSOijvTYfqd5a2EUgT342DgVGrfw6fKbV3M9T8icC5E67H4SAOvBoYU4HZnpH/MnB8= X-Received: by 2002:a05:600c:210c:b0:3e0:6c4:6a11 with SMTP id u12-20020a05600c210c00b003e006c46a11mr998294wml.114.1676055838478; Fri, 10 Feb 2023 11:03:58 -0800 (PST) MIME-Version: 1.0 References: <20220610152141.2148929-1-catalin.marinas@arm.com> <66cc7277b0e9778ba33e8b22a4a51c19a50fe6f0.camel@mediatek.com> In-Reply-To: From: Peter Collingbourne Date: Fri, 10 Feb 2023 11:03:45 -0800 Message-ID: Subject: Re: [PATCH v2 0/4] kasan: Fix ordering between MTE tag colouring and page->flags To: Catalin Marinas Cc: =?UTF-8?B?UXVuLXdlaSBMaW4gKOael+e+pOW0tCk=?= , "andreyknvl@gmail.com" , =?UTF-8?B?S3Vhbi1ZaW5nIExlZSAo5p2O5Yag56mOKQ==?= , =?UTF-8?B?R3Vhbmd5ZSBZYW5nICjmnajlhYnkuJop?= , "linux-mm@kvack.org" , =?UTF-8?B?Q2hpbndlbiBDaGFuZyAo5by16Yym5paHKQ==?= , "kasan-dev@googlegroups.com" , "ryabinin.a.a@gmail.com" , "linux-arm-kernel@lists.infradead.org" , "vincenzo.frascino@arm.com" , "will@kernel.org" Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 022D21C0012 X-Stat-Signature: bp3som1kcibcx4tbouw84rxut1c7farn X-HE-Tag: 1676055839-243448 X-HE-Meta: U2FsdGVkX19eJSId4ycq+qt8S2mdRIIZNjCbQWaQLOOKFRWZi6eGbUytW9ID8x1Eufq5qR2p1hH3Eduyz1c90oIxJfeXNF5GWYOVlBPSzOASy2yPqjWkOUddgSPgMPxITzqTNkqeZyKazOncvND9d4jTozi3xAqrhqCEX5ydiVvXA1CHZSWd7IXLWxADbP/9SuSMf7uj+j//KROK/mfPwpSA4nlINd/OGvU6WAfJc1GX553b3ZirEzRaaeE5Tnw1dNo9Zi2jgA4ZZvb1v08eoh55r3w0p26aLiWmjzfz1aSaG+BcvW6a/nRlfFN1IXf4RZrXV0PHpDcDjP8mSBs+WbkMQg0V3mDjau0TyGKIxx2nHLqQECvJw9vuvBoGnyp2yMdzG6zy+kvis075qTuvSxb7T/4D+ThiLsYE9xuMCOSvK4sA77SsIjm5bKYTag2nd0J2vpu+LJfiLxpDwfoXna38CZTB4PErnhyi5eAUkUR+3LK2FuzqP3G3Dvy1rA9fp4ZJ14MggXSXOfdj+fIiya/NKCPC5gFTv2etloK1QdqUFdv45YnBw28ixWdHpfy91YqFA628n90LmSjeDXwjXNN+WRHYCplIsaJWljl8UNmyqfDGCaX6/MEq0q7Q9FpEX1mnf88VjI9WaJ1JiZ36IAW+lSed5rAAAkBfcPeipqkufad+zXqrsOZdd1s4td3GinUkttkluQrMuiKv8ymhtR0hUSKTwCYLoMhQMRSpozFJSUO5zNqEEYHwh4VKqv7w4WyardG5ydUvIKvCi4IewbiK+7ScDldVgFgEO5C1qbc1dOhFSc/RUyo1z8vH5YyOoGe+eRHDfE9zu0RSwldaes8LKXFFyE/5jxrv4yCf5X3rWGKlvwHfSCgRyV3VH5mrLKOgqwAs/8O+FIT8L75n6oVu0DdwiKchWBKaIUDC4G6rjgMpQVMzu42y1VfWDHKPcPSHF0/a0MuKJpqGnV1 A6dF8I4n QOphTAlUCfVEolzKzl9hhok3KhVGyGx/iAYnEDqAUshySU2kIRW8WiXI6nFxWalJPg2a2e8ICTegEgLVB/ukOtKpFEbHjxbs7aeWbWjAzYCqdcpm9pugfYse2K+TuKz4Piq4TgczQf7LNiC6dkt4uzDFeW+iDuxMmFNj1jMq3jCIlEsA8nnWRKE753st2MvCCMokq2IzHONrxd6iwxCMrCgJCirIuSszH+hfdyB53StLOZDVGqOUiCoDqVJvBkq7/vtbAG+q7RTVxCzoDbMogFwQCip8LQiCceuB6uSoSZd3Ce3bffP07IP5n99NHdMUMQbH2ziaGLQb2zuHN90x8HdxosEmsvyI7KapI3otVkOb1IV9HXPhkVlA8oAQ5MFIN5WKbWXWokGyRdJP2n8sBFOCBCsN0bwBcReh5 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 Catalin, On Fri, Feb 10, 2023 at 10:28 AM Catalin Marinas wrote: > > 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. That would also work, but I was thinking that if copy_highpage() were being used to copy a KASAN page we should keep the original tag in order to maintain tag checks for page accesses. > > 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. That seems fine to me (or as well as the above patch if we decide to copy the tag). Peter