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 529F1C77B7F for ; Fri, 28 Apr 2023 14:18:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 925116B0072; Fri, 28 Apr 2023 10:18:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D5676B0074; Fri, 28 Apr 2023 10:18:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79D0C6B0075; Fri, 28 Apr 2023 10:18:49 -0400 (EDT) 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 6C40E6B0072 for ; Fri, 28 Apr 2023 10:18:49 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0F2621601CC for ; Fri, 28 Apr 2023 14:18:48 +0000 (UTC) X-FDA: 80731005978.24.D0A67BD Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf23.hostedemail.com (Postfix) with ESMTP id 2B84D14002B for ; Fri, 28 Apr 2023 14:18:45 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=P5QH0dNv; spf=pass (imf23.hostedemail.com: domain of pcc@google.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=pcc@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682691526; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Pu6CluFUTtRnaBZwnaoLdbpyoIqPOJ+pqKyFgwstymY=; b=1IWTRXYV5Buk5cUbYmJ2K+3Z5y0TsiZAqrxjaEwRQ6VMzTM/y5qL4ZbHTD7hqPzqa2N2bG Iplb8k7CM6X881xZNjnoiBQZ2q9WxR3GE7mqIuhRbky0yRZsmUkiKkJzcNBfCSrlDC6f+F RXF7KaorhSkUvzrnCkRyTSCNOlqqMfY= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=P5QH0dNv; spf=pass (imf23.hostedemail.com: domain of pcc@google.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=pcc@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682691526; a=rsa-sha256; cv=none; b=w1JM1hKUQwZVxW7O4RC/Zp55myw9HF7GOh8CWOrewOVZ7K0UFV08i6+sYuswGD72LFveIJ +zx6ZtMiSmkQ1bbcT4IXi+Hy6DMvPgbsENWmKUChkAo1CL53GvZEDUOjiSvycQx6yW7fRg EydwPaJ5WZGQXdrqEWQ3DcpdtH6Ou1w= Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-3f0a2f8216fso1011421cf.0 for ; Fri, 28 Apr 2023 07:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1682691525; x=1685283525; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Pu6CluFUTtRnaBZwnaoLdbpyoIqPOJ+pqKyFgwstymY=; b=P5QH0dNvCLo3EWV8aUGUFmksU1VOrkjgdd/VV//mkR1PthZgpTwmF7r0UOPuzXPHLk 07Mv1pwUM+I58m5AjocItsDof3SeHKLr4xc/Wy+rfZoZLIlRYOBU870dG1csLLeZGh6X NgtBs2iCV/UKJNu5ugqe1x6M5xjXwwVcsAGorYcAcXOzVgMuVufs7gquSYn6HnbMCinW WR4mHkW/UluGimOpSn3CuINIsWYQrlqd5YTITYLqd5w7lyQAXwkMMRNjXP0p8Q3+psHy E4GAHeYv18kcf4kcChPurQYJgWO5DNfSv1zNyifFf3WoMFh7ZS2Cl6ejU20AZwUJLagI tnzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682691525; x=1685283525; h=content-transfer-encoding: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=Pu6CluFUTtRnaBZwnaoLdbpyoIqPOJ+pqKyFgwstymY=; b=lUB1d9TUv6nAf8kWHZch3ZKrug/yHJZWrKcb3TGGs6Ji8NqWWxCHmcCj6BQ23xZsHI yTGHs4uYwBPGrs9osDitSCWn9UKSRaiGmtUQYgw6DO6z8Qs0otAejPkwFJoSegXlwMQf 0FF44PbNMnwDjVqrVTCQds3lPlvJopBxv3Fj948To9SVFG/zr6Kz+gT44Q0CnOnMfHGB BpKju3CUcah0IkA50Q/X8e6VlcF/IJvcDq5EZdcwBgWRV5JaEIUtquVPTVhKQBkvI3tP NBlrWeS3zcalnnT2/jNv0Bx4z3XTTbzHk4heH+tACfWK5KLqAexEyXAxis0tkQAdfq3x y4DQ== X-Gm-Message-State: AC+VfDzWeOrofoUsOM+u6u2N16uKGMP9QPpcBPozAvgxyL3q8JmUj8Ot /jMdpgvG1J57/ioWLXhYmPhDbqnKoo6Qrk19h7s42r8oG2zklOgJe9St4w== X-Google-Smtp-Source: ACHHUZ49wHROlihc67ea87HWUY2lpy74jY8EBGyNtVyCuBdDYGtAo6EokbOa0lcx0p1UDycSrkffEhHajNhJgHckI10= X-Received: by 2002:a05:622a:1ba3:b0:3ef:330c:8f9e with SMTP id bp35-20020a05622a1ba300b003ef330c8f9emr396343qtb.10.1682691525255; Fri, 28 Apr 2023 07:18:45 -0700 (PDT) MIME-Version: 1.0 References: <20230420210945.2313627-1-pcc@google.com> In-Reply-To: From: Peter Collingbourne Date: Fri, 28 Apr 2023 07:18:34 -0700 Message-ID: Subject: Re: [PATCH] arm64: Also reset KASAN tag if page is not PG_mte_tagged To: Catalin Marinas Cc: andreyknvl@gmail.com, =?UTF-8?B?UXVuLXdlaSBMaW4gKOael+e+pOW0tCk=?= , =?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, eugenis@google.com, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 2B84D14002B X-Stat-Signature: odxbpqc6ijgsururkqgbh6f6tn1mdn7p X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1682691525-91125 X-HE-Meta: U2FsdGVkX1/Env5NJ5gCYAANepMF3T1JJAxBB+gcXqbMEszojxgg7XTlXS01HzH4ruGtSqX5LnqVVXMrOitm4f5GIWbEFkxbKT73gqxYgrPW4twnOKGz83TFb9v4kiEOEE7WWy06N8VEjX2MhvgsZ0gp/7C5xnw4WtG0G2XmNeX0s8WpnB9Y6wyy3akPvGlKZvT35zsgWoTHZiIIrLE5Fr4Ar5P4/77jAJiFfju3FEPqtJXweA28FaQ1bjCipbvMW2C+v5Fl5rWmTyGjp5MJh+v6sJiORLYfY0iEdLWnC3uLUuYkwDuK6H3SXTvOivxstuaCkaUwlDZIzluoGIlowgvlmwo9GKqHlJtJtT69/MaQtZt1c9z30SxoIwzMAkh8lH2zS2Kl3kTiznUPRwD8VTgnbg0w4GzeNq6sMzK5u1UREdE/MIXL4S/ArxizGhJZlL/b2QjjyTgQm2D+eBeRCGGL8R8MPhZImuXd7qNAO5t8lxGF57N1tOBGwZyE/cUEhAxlrc8Qk3+AiiWBoK4CAu6AwOghFwzdQoeRGFF1XE/jahvdwd/K4CNM8EmZiUxuOs1nETzCGeHgNliZxUB/49/mU0MFPmjMWISX6g0aAhpie0bTyiWtJZpSoa0T7FSbSb9b6IAqWZG8y1S/MEfKgX6LbYSGoMRZH363DOq3tiFXuN7j5Md0oHu5gtB+mTK00iFA3b59NoAi+NnbMs4hEIm5AifKsD8xOqSEwVRFl5tk8/6MGGs2vBuXbEUzcKSlBSClyxBsiEBy6bhIbbvYG9YsAFKHbHuo8iL0ZBXTK73ffK/lSWGVP6HxY5NoINkWui4Waw03sV3+QqmzV8N9UQNGE3+sFgh8SvdSMGLeq+jKuKesobnAP4lrcLfDLaui+VyUUh/f0pl/+ycXutlpiQBHc+LwZNkV3mqUCrO8/hQ9blhIO1XQyTQTLLq8b6yQaBP484V59vw4y8aGxYP TjgdXoLW VtBWKo7XngoLWtcVDYn4+rrGIJ07cD/Fb5IPrHqrhFqBKHinv8xAIf1mlt+f7mIvXqo5llhCAPV7+7DOZH5ZMvylAdXCGJ/d8hJ/96Iwi2DlYjQfg6bsa4hJyeIFtKFMby1Bg5ia58YpHpTbi9gqgDQVmDVWWQSP6pYkYAB7fQyj/fWRPtvyq9n5wIs65qL32R6Iv8EWizo8IpBcniCIYmbxYKdreA+DeJDF1EclbdMbTHU9ORPrc5bDnXnPsb5Eah+uJ28Vhgd5Af32VtznMHAwd3piovG5SSjsAUJ93LvcUYU3C7k6ywsndX6/pKSvya4q3GDtsaxKtMCqRhmUZ027XX1y4nDmfcoRHwm9X05WCvGzn3aIjAKM0cU+KM1MMFIC5Ztrnres41SOm0fzTXH8KeYXoMriVqmC8f3aGKnckGmO4hjMcekxkSA== 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 Fri, Apr 21, 2023 at 10:20=E2=80=AFAM Peter Collingbourne wrote: > > On Fri, Apr 21, 2023 at 5:24=E2=80=AFAM Catalin Marinas wrote: > > > > On Thu, Apr 20, 2023 at 02:09:45PM -0700, Peter Collingbourne wrote: > > > Consider the following sequence of events: > > > > > > 1) A page in a PROT_READ|PROT_WRITE VMA is faulted. > > > 2) Page migration allocates a page with the KASAN allocator, > > > causing it to receive a non-match-all tag, and uses it > > > to replace the page faulted in 1. > > > 3) The program uses mprotect() to enable PROT_MTE on the page faulted= in 1. > > > > Ah, so there is no race here, it's simply because the page allocation > > for migration has a non-match-all kasan tag in page->flags. > > > > How do we handle the non-migration case with mprotect()? IIRC > > post_alloc_hook() always resets the page->flags since > > GFP_HIGHUSER_MOVABLE has the __GFP_SKIP_KASAN_UNPOISON flag. > > Yes, that's how it normally works. > > > > As a result of step 3, we are left with a non-match-all tag for a pag= e > > > with tags accessible to userspace, which can lead to the same kind of > > > tag check faults that commit e74a68468062 ("arm64: Reset KASAN tag in > > > copy_highpage with HW tags only") intended to fix. > > > > > > The general invariant that we have for pages in a VMA with VM_MTE_ALL= OWED > > > is that they cannot have a non-match-all tag. As a result of step 2, = the > > > invariant is broken. This means that the fix in the referenced commit > > > was incomplete and we also need to reset the tag for pages without > > > PG_mte_tagged. > > > > > > Fixes: e5b8d9218951 ("arm64: mte: reset the page tag in page->flags") > > > > This commit was reverted in 20794545c146 (arm64: kasan: Revert "arm64: > > mte: reset the page tag in page->flags"). It looks a bit strange to fix > > it up. > > It does seem strange but I think it is correct because that is when > the bug (resetting tag only if PG_mte_tagged) was introduced. The > revert preserved the bug because it did not account for the migration > case, which means that it didn't account for migration+mprotect > either. > > > > diff --git a/arch/arm64/mm/copypage.c b/arch/arm64/mm/copypage.c > > > index 4aadcfb01754..a7bb20055ce0 100644 > > > --- a/arch/arm64/mm/copypage.c > > > +++ b/arch/arm64/mm/copypage.c > > > @@ -21,9 +21,10 @@ void copy_highpage(struct page *to, struct page *f= rom) > > > > > > copy_page(kto, kfrom); > > > > > > + if (kasan_hw_tags_enabled()) > > > + page_kasan_tag_reset(to); > > > + > > > if (system_supports_mte() && page_mte_tagged(from)) { > > > - if (kasan_hw_tags_enabled()) > > > - page_kasan_tag_reset(to); > > > > This should work but can we not do this at allocation time like we do > > for the source page and remove any page_kasan_tag_reset() here > > altogether? > > That would be difficult because of the number of different ways that > the page can be allocated. That's why we also decided to reset it here > in commit e74a68468062. Ping. Peter