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 0/3] kasan: Fix ordering between MTE tag colouring and page->flags Date: Tue, 17 May 2022 19:09:42 +0100 [thread overview] Message-ID: <20220517180945.756303-1-catalin.marinas@arm.com> (raw) Hi, 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 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 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? Thanks. Catalin Marinas (3): mm: kasan: Ensure the tags are visible before the tag in page->flags mm: kasan: Reset the tag on pages intended for user 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 | 10 +++++++--- mm/kasan/common.c | 3 ++- mm/page_alloc.c | 9 ++++++--- 8 files changed, 15 insertions(+), 40 deletions(-)
WARNING: multiple messages have this Message-ID (diff)
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 0/3] kasan: Fix ordering between MTE tag colouring and page->flags Date: Tue, 17 May 2022 19:09:42 +0100 [thread overview] Message-ID: <20220517180945.756303-1-catalin.marinas@arm.com> (raw) Hi, 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 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 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? Thanks. Catalin Marinas (3): mm: kasan: Ensure the tags are visible before the tag in page->flags mm: kasan: Reset the tag on pages intended for user 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 | 10 +++++++--- mm/kasan/common.c | 3 ++- mm/page_alloc.c | 9 ++++++--- 8 files changed, 15 insertions(+), 40 deletions(-) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2022-05-17 18:09 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-17 18:09 Catalin Marinas [this message] 2022-05-17 18:09 ` [PATCH 0/3] kasan: Fix ordering between MTE tag colouring and page->flags Catalin Marinas 2022-05-17 18:09 ` [PATCH 1/3] mm: kasan: Ensure the tags are visible before the tag in page->flags Catalin Marinas 2022-05-17 18:09 ` Catalin Marinas 2022-05-21 22:14 ` Andrey Konovalov 2022-05-21 22:14 ` Andrey Konovalov 2022-05-17 18:09 ` [PATCH 2/3] mm: kasan: Reset the tag on pages intended for user Catalin Marinas 2022-05-17 18:09 ` Catalin Marinas 2022-05-21 22:15 ` Andrey Konovalov 2022-05-21 22:15 ` Andrey Konovalov 2022-05-17 18:09 ` [PATCH 3/3] arm64: kasan: Revert "arm64: mte: reset the page tag in page->flags" Catalin Marinas 2022-05-17 18:09 ` Catalin Marinas 2022-05-21 22:16 ` Andrey Konovalov 2022-05-21 22:16 ` Andrey Konovalov 2022-05-19 21:45 ` [PATCH 0/3] kasan: Fix ordering between MTE tag colouring and page->flags Andrey Konovalov 2022-05-19 21:45 ` Andrey Konovalov 2022-05-20 13:01 ` Catalin Marinas 2022-05-20 13:01 ` Catalin Marinas 2022-05-21 22:20 ` Andrey Konovalov 2022-05-21 22:20 ` Andrey Konovalov 2022-05-25 15:45 ` Catalin Marinas 2022-05-25 15:45 ` Catalin Marinas 2022-05-25 17:41 ` Andrey Konovalov 2022-05-25 17:41 ` Andrey Konovalov 2022-05-26 12:24 ` Catalin Marinas 2022-05-26 12:24 ` Catalin Marinas 2022-05-31 17:16 ` Andrey Konovalov 2022-05-31 17:16 ` Andrey Konovalov 2022-06-09 18:32 ` Catalin Marinas 2022-06-09 18:32 ` Catalin Marinas 2022-06-09 18:40 ` Andrey Konovalov 2022-06-09 18:40 ` Andrey Konovalov
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=20220517180945.756303-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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.