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 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 701EED21274 for ; Thu, 17 Oct 2024 11:01:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=OhvSV9XfNgNHO4JNgX3Up10+vPdoF8A3cntbXO3ghFI=; b=YPa+23M1pvuqkI6Jbeb9ifji9Y fsU+GYq4EjTEgKjLj8aEkRtnsJRfRgwRNJFAoqar5kiu/ixxADPf3N66ARrWaJ4xCVBFYes0p8Q5y FjsrKGO86tGxZ3ZGLCrmD/Rd83ZdwwnDzzd0duASRvOvT1mjZ/oj61aW/CqUZP/9Sp/yUqE12xYhs z8JQyuryQr4vXJf4oVC2DIUJtKopuArX4YObLa7eq2R5KtheXdtV/qNVDS6djXLLKgZRUSH50xU28 z6fJvzSPy3H56TRGJguzuvMO05WwXGuQbnHCY7h4t6MMpZ5Mj97ysdDEt7L5CCV/2AmsTwwFSdTG+ SdM2AoTg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t1OFN-0000000EZ58-1Wlv; Thu, 17 Oct 2024 11:00:49 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t1Nm1-0000000EWVH-1PBt for linux-arm-kernel@lists.infradead.org; Thu, 17 Oct 2024 10:30:31 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B00F7FEC; Thu, 17 Oct 2024 03:30:57 -0700 (PDT) Received: from J2N7QTR9R3 (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D4DD43F71E; Thu, 17 Oct 2024 03:30:25 -0700 (PDT) Date: Thu, 17 Oct 2024 11:30:23 +0100 From: Mark Rutland To: Linus Walleij , Ard Biesheuvel Cc: Clement LE GOFFIC , Russell King , Kees Cook , AngeloGioacchino Del Regno , Mark Brown , Antonio Borneo , linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org Subject: Re: [PATCH v2 1/2] ARM: ioremap: Sync PGDs for VMALLOC shadow Message-ID: References: <20241016-arm-kasan-vmalloc-crash-v2-0-0a52fd086eef@linaro.org> <20241016-arm-kasan-vmalloc-crash-v2-1-0a52fd086eef@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241016-arm-kasan-vmalloc-crash-v2-1-0a52fd086eef@linaro.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241017_033029_533552_7E235311 X-CRM114-Status: GOOD ( 22.85 ) 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 On Wed, Oct 16, 2024 at 09:15:21PM +0200, Linus Walleij wrote: > When sync:ing the VMALLOC area to other CPUs, make sure to also > sync the KASAN shadow memory for the VMALLOC area, so that we > don't get stale entries for the shadow memory in the top level PGD. > > Since we are now copying PGDs in two instances, create a helper > function named memcpy_pgd() to do the actual copying, and > create a helper to map the addresses of VMALLOC_START and > VMALLOC_END into the corresponding shadow memory. > > Cc: stable@vger.kernel.org > Fixes: 565cbaad83d8 ("ARM: 9202/1: kasan: support CONFIG_KASAN_VMALLOC") > Link: https://lore.kernel.org/linux-arm-kernel/a1a1d062-f3a2-4d05-9836-3b098de9db6d@foss.st.com/ > Reported-by: Clement LE GOFFIC > Suggested-by: Mark Rutland > Suggested-by: Russell King (Oracle) > Signed-off-by: Linus Walleij > --- > arch/arm/mm/ioremap.c | 25 +++++++++++++++++++++---- > 1 file changed, 21 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c > index 794cfea9f9d4..94586015feed 100644 > --- a/arch/arm/mm/ioremap.c > +++ b/arch/arm/mm/ioremap.c > @@ -23,6 +23,7 @@ > */ > #include > #include > +#include > #include > #include > #include > @@ -115,16 +116,32 @@ int ioremap_page(unsigned long virt, unsigned long phys, > } > EXPORT_SYMBOL(ioremap_page); > > +static unsigned long arm_kasan_mem_to_shadow(unsigned long addr) > +{ > + return (unsigned long)kasan_mem_to_shadow((void *)addr); > +} > + > +static void memcpy_pgd(struct mm_struct *mm, unsigned long start, > + unsigned long end) > +{ > + memcpy(pgd_offset(mm, start), pgd_offset_k(start), > + sizeof(pgd_t) * (pgd_index(end) - pgd_index(start))); > +} > + > void __check_vmalloc_seq(struct mm_struct *mm) > { > int seq; > > do { > seq = atomic_read(&init_mm.context.vmalloc_seq); > - memcpy(pgd_offset(mm, VMALLOC_START), > - pgd_offset_k(VMALLOC_START), > - sizeof(pgd_t) * (pgd_index(VMALLOC_END) - > - pgd_index(VMALLOC_START))); > + memcpy_pgd(mm, VMALLOC_START, VMALLOC_END); > + if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) { > + unsigned long start = > + arm_kasan_mem_to_shadow(VMALLOC_START); > + unsigned long end = > + arm_kasan_mem_to_shadow(VMALLOC_END); > + memcpy_pgd(mm, start, end); > + } This looks good; FWIW: Acked-by: Mark Rutland As a separate thing, I believe we also need to use atomic_read_acquire() for the reads of vmalloc_seq to pair with the atomic_*_release() on each update. Otherwise, this can be reordered, e.g. do { memcpy_pgd(...); seq = atomic_read(&init_mm.context.vmalloc_seq); atomic_set_release(&mm->context.vmalloc_seq, seq); } while (seq != atomic_read(&init_mm.context.vmalloc_seq) ... and we might fail to copy the relevant table entries from init_mm, but still think we're up-to-date and update mm's vmalloc_seq. Ard, does that sound right to you, or am I missing something? Mark.