From: Catalin Marinas <catalin.marinas@arm.com>
To: Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Andrey Konovalov <andreyknvl@gmail.com>
Cc: Will Deacon <will@kernel.org>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Peter Collingbourne <pcc@google.com>,
kasan-dev@googlegroups.com, linux-mm@kvack.org,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/4] kasan: Fix ordering between MTE tag colouring and page->flags
Date: Fri, 10 Jun 2022 16:21:37 +0100 [thread overview]
Message-ID: <20220610152141.2148929-1-catalin.marinas@arm.com> (raw)
Hi,
That's a second attempt on fixing the race race between setting the
allocation (in-memory) tags in a page and the corresponding logical tag
in page->flags. Initial version here:
https://lore.kernel.org/r/20220517180945.756303-1-catalin.marinas@arm.com
This new series does not introduce any new GFP flags but instead always
skips unpoisoning of the user pages (we already skip the poisoning on
free). Any unpoisoned page will have the page->flags tag reset.
For the background:
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
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 a page is mapped in user-space with PROT_MTE, the architecture code
will set the allocation 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
Since clearing the flags in the arch code doesn't work, to do this at
page allocation time when __GFP_SKIP_KASAN_UNPOISON is passed.
Thanks.
Catalin Marinas (4):
mm: kasan: Ensure the tags are visible before the tag in page->flags
mm: kasan: Skip unpoisoning of user pages
mm: kasan: Skip page unpoisoning only if __GFP_SKIP_KASAN_UNPOISON
arm64: kasan: Revert "arm64: mte: reset the page tag in page->flags"
arch/arm64/kernel/hibernate.c | 5 -----
arch/arm64/kernel/mte.c | 9 ---------
arch/arm64/mm/copypage.c | 9 ---------
arch/arm64/mm/fault.c | 1 -
arch/arm64/mm/mteswap.c | 9 ---------
include/linux/gfp.h | 2 +-
mm/kasan/common.c | 3 ++-
mm/page_alloc.c | 19 ++++++++++---------
8 files changed, 13 insertions(+), 44 deletions(-)
next reply other threads:[~2022-06-10 15:21 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-10 15:21 Catalin Marinas [this message]
2022-06-10 15:21 ` [PATCH v2 1/4] mm: kasan: Ensure the tags are visible before the tag in page->flags Catalin Marinas
2022-06-16 8:31 ` Vincenzo Frascino
2022-07-07 9:22 ` Will Deacon
2022-07-07 11:44 ` Catalin Marinas
2022-06-10 15:21 ` [PATCH v2 2/4] mm: kasan: Skip unpoisoning of user pages Catalin Marinas
2022-06-11 19:40 ` Andrey Konovalov
2022-06-16 8:42 ` Vincenzo Frascino
2022-06-16 17:40 ` Catalin Marinas
2022-06-10 15:21 ` [PATCH v2 3/4] mm: kasan: Skip page unpoisoning only if __GFP_SKIP_KASAN_UNPOISON Catalin Marinas
2022-06-11 19:40 ` Andrey Konovalov
2022-06-16 8:43 ` Vincenzo Frascino
2022-06-10 15:21 ` [PATCH v2 4/4] arm64: kasan: Revert "arm64: mte: reset the page tag in page->flags" Catalin Marinas
2022-06-11 19:40 ` Andrey Konovalov
2022-06-16 8:44 ` Vincenzo Frascino
2022-07-07 10:33 ` [PATCH v2 0/4] kasan: Fix ordering between MTE tag colouring and page->flags Will Deacon
2022-07-08 13:31 ` Will Deacon
2023-02-02 5:25 ` Kuan-Ying Lee (李冠穎)
2023-02-02 12:59 ` Andrey Konovalov
2023-02-03 3:41 ` Kuan-Ying Lee (李冠穎)
2023-02-03 17:51 ` Andrey Konovalov
2023-02-08 5:41 ` Qun-wei Lin (林群崴)
2023-02-10 6:19 ` Peter Collingbourne
2023-02-10 18:28 ` Catalin Marinas
2023-02-10 19:03 ` Peter Collingbourne
2023-02-13 18:47 ` Catalin Marinas
2023-02-14 1:56 ` Peter Collingbourne
2023-02-13 1:56 ` Qun-wei Lin (林群崴)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220610152141.2148929-1-catalin.marinas@arm.com \
--to=catalin.marinas@arm.com \
--cc=andreyknvl@gmail.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=pcc@google.com \
--cc=ryabinin.a.a@gmail.com \
--cc=vincenzo.frascino@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox