From patchwork Fri Jun 10 15:21:37 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Catalin Marinas X-Patchwork-Id: 12877708 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 78B22C43334 for ; Fri, 10 Jun 2022 15:22:58 +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=ebQileozgY2bWercKcmYjEiC3c7IX+xtvu5WT+IVtNQ=; b=uxNt5Q/EGGKkpF KmUPFejPd5ZsNk/wQJeTaKcEw/x1ZPxpJkeB6K3fnGVIJ6Tirst7NlGdQpGl+vxvIL2O3ss4AT6Yi LAcOnXnum1oKaLcbPRHVkzjCcoT7A4uIumKWCN8iCFhm1LEvi2RiYEXsGXReqvSz9M0yIOTtYlwXh 2lGul1UTKocY2lceGavc0izDTfwO8daRMdQylGkwemeJQZr40tTmTQWI8FMFt/N5p9GN0IFh4y1Bi LrAUgySn5oa8d1KbTP0v5m5MhWO+3AHMREBWio8yD/lnpcIzH6Uaq+fLRJDC4p4zqSRj7dyjwDrmB blf3dDGUo9XsuGVHM99w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nzgSN-008jtn-Ay; Fri, 10 Jun 2022 15:21:51 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nzgSJ-008jsi-1z for linux-arm-kernel@lists.infradead.org; Fri, 10 Jun 2022 15:21:48 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 662DE61F18; Fri, 10 Jun 2022 15:21:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3BE8C34114; Fri, 10 Jun 2022 15:21:43 +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 v2 0/4] kasan: Fix ordering between MTE tag colouring and page->flags Date: Fri, 10 Jun 2022 16:21:37 +0100 Message-Id: <20220610152141.2148929-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-20220610_082147_173921_A397CFD4 X-CRM114-Status: GOOD ( 16.24 ) 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 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(-)