From patchwork Tue May 17 18:09:42 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Catalin Marinas X-Patchwork-Id: 12852835 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BECC7C433EF for ; Tue, 17 May 2022 18:11:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=5nzWDJrpT0xASgR9mkIX8x2LWqUDEDS4DQ0qCI9TtxU=; b=KXT07KwfZONeYF GntmWDj2U+FcH0en2jYObGTD/BamrS+vGnJmj+XcooAa/hu5z11ao62RZu0sX7K5kD8XqgT1BLsY7 mVyW2GydttGxAFsnAoeZFAkvNN/lWIvlcN47KIMG/UsshMDXdhtw5y4GmOAPfQl61xLN3SG2anIo1 91IvIqh2L+5TRLGJhfk48kxmRST1v1EoHNdaeJTKsTTPq5W2giynNXbYxbqoE/kwWRqdVaVmuNbjw /seN+6D8V0All+oMpJ++uF8ethy8ZDB5cIfDKU01s4xD98bMXdTVHHtWiBfanyOw9u6bQGrl6aR+t uYdRtR44mHvWiJNRMKoQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nr1e3-00FAOH-Hc; Tue, 17 May 2022 18:10:07 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nr1dq-00FAGz-1p for linux-arm-kernel@lists.infradead.org; Tue, 17 May 2022 18:09:55 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 8451FCE1BD4; Tue, 17 May 2022 18:09:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04ADBC34100; Tue, 17 May 2022 18:09:47 +0000 (UTC) From: Catalin Marinas To: Andrey Ryabinin , Andrey Konovalov Cc: Will Deacon , Vincenzo Frascino , Peter Collingbourne , 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 Message-Id: <20220517180945.756303-1-catalin.marinas@arm.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220517_110954_315966_3FA77718 X-CRM114-Status: GOOD ( 15.56 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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(-)