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 240EBD216B7 for ; Tue, 15 Oct 2024 14:37:41 +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-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=tudYp6uyI8xbQVIuWW1lZBRBYnt4vjNVX5OiiFXxeBk=; b=12c56reHFZqIKcfWHalq2ML92T FqLBpbWoHkK0yh7vdJS1HCWWVpFAYzXalmN4U+GUtqdOBwadMpkO8UzsGzZI99nsInfuJg3pd5G7y yj++hFaB0TAzxVNRS1eQgYCi+4LsIHWhV6i5m0c6SQM9TSozGofjHkag3fPL81HRim8AAVKvZDT9Q nF/pb5szx3Dyw9/z5EbmemrGBSVLhlykAO2SwFltHcYTs7MoCOMmBgJOv+5qSnazSv8/06LlGvvhf nmHQLNdUYYwz70F/Tl81CwtZYrrOhGJytW8jhSqreDYS1sCS8dx4N+mO1WjmvXi5naKyVXZhmHQC/ hsf4Mdyw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t0ifw-00000008XOF-33je; Tue, 15 Oct 2024 14:37:28 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t0ieW-00000008XGM-2Yk6 for linux-arm-kernel@lists.infradead.org; Tue, 15 Oct 2024 14:36:01 +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 53B29FEC; Tue, 15 Oct 2024 07:36:25 -0700 (PDT) Received: from J2N7QTR9R3.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D6F993F71E; Tue, 15 Oct 2024 07:35:53 -0700 (PDT) Date: Tue, 15 Oct 2024 15:35:51 +0100 From: Mark Rutland To: Ard Biesheuvel Cc: Linus Walleij , Clement LE GOFFIC , Russell King , "Russell King (Oracle)" , Kees Cook , AngeloGioacchino Del Regno , Mark Brown , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, Antonio Borneo Subject: Re: Crash on armv7-a using KASAN Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241015_073600_712070_35627A63 X-CRM114-Status: GOOD ( 30.17 ) 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 Tue, Oct 15, 2024 at 04:22:20PM +0200, Ard Biesheuvel wrote: > On Tue, 15 Oct 2024 at 16:00, Mark Rutland wrote: > > > > On Tue, Oct 15, 2024 at 03:51:02PM +0200, Linus Walleij wrote: > > > On Tue, Oct 15, 2024 at 12:28 PM Mark Rutland wrote: > > > > On Mon, Oct 14, 2024 at 03:19:49PM +0200, Clement LE GOFFIC wrote: > > > > > > > I think what's happening here is that when switching from prev to next > > > > in the scheduler, we switch to next's mm before we actually switch to > > > > next's register state, and there's a transient window where prev is > > > > executed using next's mm. AFAICT we don't map prev's KASAN stack shadow > > > > into next's mm anywhere, and so inlined KASAN_STACK checks recursively > > > > fault on this until we switch to the overflow stack. [...] > > > Yeah it looks like a spot-on identification of the problem, I can try to > > > think about how we could fix this if I can reproduce it, I keep trying > > > to provoke the crash :/ > > > > It's a bit grotty -- AFAICT you'd either need to prefault in the > > specific part of the vmalloc space when switching tasks, or we'd need to > > preallocate all the shared vmalloc tables at the start of time so that > > they're always up-to-date. > > > > While we could disable KASAN_STACK, that's only going to mask the > > problem until this happens for any other vmalloc shadow... > > Is the other vmalloc shadow not covered by the ordinary on-demand faulting? It depends on what the vmalloc memory is used for; if it's anything else used in the fault handling path, that'll fault recursively, and it's possible that'll happen indirectly via other instrumentation. > When I implemented VMAP_STACK for ARM, I added an explicit load from > the new stack while still running from the old one (in __switch_to) so > that the ordinary faulting code can deal with it. Couldn't we do the > same for the vmalloc shadow of the new stack? We could do something similar, but note that it's backwards: we need to ensure that the old/current stack shadow will be mapped in the new mm. So the usual fault handling can't handle that as-is, because you need to fault-in pages for an mm which isn't yet in use. That logic could be factored out and shared, though. Mark.