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 F0D80C433F5 for ; Thu, 19 May 2022 21:45:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 80B436B0071; Thu, 19 May 2022 17:45:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BB2C6B0072; Thu, 19 May 2022 17:45:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65C636B0073; Thu, 19 May 2022 17:45:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 570326B0071 for ; Thu, 19 May 2022 17:45:16 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 217F461049 for ; Thu, 19 May 2022 21:45:16 +0000 (UTC) X-FDA: 79483823832.13.71727CF Received: from mail-il1-f173.google.com (mail-il1-f173.google.com [209.85.166.173]) by imf23.hostedemail.com (Postfix) with ESMTP id 65AA21400CB for ; Thu, 19 May 2022 21:44:57 +0000 (UTC) Received: by mail-il1-f173.google.com with SMTP id o16so4523573ilq.8 for ; Thu, 19 May 2022 14:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=my9je9EYZl7JVeMs/i+hH21WjUx7K+0NW3mXQ84nNhM=; b=QbGfoRXMJp9P0ifiuHlzRZMq8TO5mjsyuMfm5oUL8zKS1n7LWFD1KBNBQtVAndW8o8 eNdntiO5Ypoz32qCSADQessrpEw6+EBg5WI6MpxaPj47k9hfRvp4nMdMu7CMHjjri042 ZDswvM/5VqHF5nDc5MrzdpePrZG8Mb2F7yZNJNOVE9dsrcmzwgoYdOAPBm9L1bKgoUAO vlorzDvXW1AnXZ4quMEVVm/SfIVigrD6jPrhlsQHqmYv8cGBFT+8t1cKrMX5CF4yBllo o0scD5Stl6tNQOkQNcpLgBzq++JBpXFZnJsrq+MUt+43baSxraOTHnl8794ZrqbZdYrW EN9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=my9je9EYZl7JVeMs/i+hH21WjUx7K+0NW3mXQ84nNhM=; b=I+M+/GhifORq2yJsJb5/AoyI/57+l+etaROnrha486GI8+GhgtJGBZmpBJLjI2rLeb 9AMy1RM0ZRD4swHZjLeiG4rnaPEHjyuhZkr4IGIsJN7sgO6qn3df8nXJ9AJkva9bOIjE gcPyfLFPBAuypsWmmv+0jxirCl6lwhf5OO2n3xoLu2P93SSm5fvk53znWE8UmMzyD/Zk cAmjI1m2n/FDdgNDt9geT53n9UvJTDtM4Zll111BDcIoTnXyaMpchbsZwZoXsobmiir+ zbwsv5s1zhOvHYwJIT8ZbfuTaZ0/RJhWMCiTtTG6neWRJpXs+sK5z7v5KeogqZ89Y5JY 3cEQ== X-Gm-Message-State: AOAM530vjQsdLLrSpIPVgesz2jSDu/8coGvOVlmIc9ZNcbWUEkrj+hFJ Ph0jxu5FrqnuC1XlZ2ckAZirOCJTvFrDO+K4MVc= X-Google-Smtp-Source: ABdhPJwGlIAiN5rCNp2rNg3tQ7FiMskH7jqMgoioc/rsSRNEg8ziGYz/7Y7GuolZ+xc0HbM0tu/WmhhRVC7Fiqnk48Q= X-Received: by 2002:a05:6e02:1c2c:b0:2cf:ef3:f4df with SMTP id m12-20020a056e021c2c00b002cf0ef3f4dfmr3705269ilh.235.1652996714967; Thu, 19 May 2022 14:45:14 -0700 (PDT) MIME-Version: 1.0 References: <20220517180945.756303-1-catalin.marinas@arm.com> In-Reply-To: <20220517180945.756303-1-catalin.marinas@arm.com> From: Andrey Konovalov Date: Thu, 19 May 2022 23:45:04 +0200 Message-ID: Subject: Re: [PATCH 0/3] kasan: Fix ordering between MTE tag colouring and page->flags To: Catalin Marinas Cc: Andrey Ryabinin , Will Deacon , Vincenzo Frascino , Peter Collingbourne , kasan-dev , Linux Memory Management List , Linux ARM Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QbGfoRXM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf23.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.166.173 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 65AA21400CB X-Rspam-User: X-Stat-Signature: 1gyiqrs8kzxza4rsx4fp3f8tjgkkkem7 X-HE-Tag: 1652996697-114595 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 Tue, May 17, 2022 at 8:09 PM Catalin Marinas wrote: > > Hi, Hi Catalin, > That's more of an RFC to get a discussion started. I plan to eventually > apply the third patch reverting the page_kasan_tag_reset() calls under > arch/arm64 since they don't cover all cases (the race is rare and we > haven't hit anything yet but it's possible). > > On a system with MTE and KASAN_HW_TAGS enabled, when a page is allocated > kasan_unpoison_pages() sets a random tag and saves it in page->flags so > that page_to_virt() re-creates the correct tagged pointer. We need to > ensure that the in-memory tags are visible before setting the > page->flags: > > P0 (__kasan_unpoison_range): P1 (access via virt_to_page): > Wtags=x Rflags=x > | | > | DMB | address dependency > V V > Wflags=x Rtags=x This is confusing: the paragraph mentions page_to_virt() and the diagram - virt_to_page(). I assume it should be page_to_virt(). alloc_pages(), which calls kasan_unpoison_pages(), has to return before page_to_virt() can be called. So they only can race if the tags don't get propagated to memory before alloc_pages() returns, right? This is why you say that the race is rare? > The first patch changes the order of page unpoisoning with the tag > storing in page->flags. page_kasan_tag_set() has the right barriers > through try_cmpxchg(). [...] > If such page is mapped in user-space with PROT_MTE, the architecture > code will set the tag to 0 and a subsequent page_to_virt() dereference > will fault. We currently try to fix this by resetting the tag in > page->flags so that it is 0xff (match-all, not faulting). However, > setting the tags and flags can race with another CPU reading the flags > (page_to_virt()) and barriers can't help, e.g.: > > P0 (mte_sync_page_tags): P1 (memcpy from virt_to_page): > Rflags!=0xff > Wflags=0xff > DMB (doesn't help) > Wtags=0 > Rtags=0 // fault So this change, effectively, makes the tag in page->flags for GFP_USER pages to be reset at allocation time. And the current approach of resetting the tag when the kernel is about to access these pages is not good because: 1. it's inconvenient to track all places where this should be done and 2. the tag reset can race with page_to_virt() even with patch #1 applied. Is my understanding correct? This will reset the tags for all kinds of GFP_USER allocations, not only for the ones intended for MAP_ANONYMOUS and RAM-based file mappings, for which userspace can set tags, right? This will thus weaken in-kernel MTE for pages whose tags can't even be set by userspace. Is there a way to deal with this? > Since clearing the flags in the arch code doesn't work, try to do this > at page allocation time by a new flag added to GFP_USER. Could we > instead add __GFP_SKIP_KASAN_UNPOISON rather than a new flag? Why do we need a new flag? Can we just check & GFP_USER instead? Thanks!