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 27EDCD1D879 for ; Tue, 15 Oct 2024 15:29:18 +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=LyyJx2ahVRfAF3A/vlm1B3MiV4CCl3csT4qGTi+FsbQ=; b=T9b7i5Z0MimRn6x9XWcN9ss2zz LSXbXdzE4jqED9SL4KwdCIyopQEClMMuzyldxnz4M8+zHOzdlFtboFQHysDudmsUQTRWB1G7Zf/86 cyqJItsky4qb8PY3b0xc/F13tPjmyS/pc2eZ/J+EnfRhNWjIWCvMu65u6PWDafl3OgPNod13Yj4zX jGK3lKjC2nOhx5gs0scLlf6RDlYN58J9jzii5tKUp41tSO1VI7GA+MQAJZMsEi46pBJOSkcwhKPzX skNUAXhTc9w6Q+0NYzFRZQofqH+rPoPJI3dddT1qfzu6e89ZiGDMd0Bt5AfUOz1w20dhEyX3kFI58 f+BMB+fw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t0jTs-00000008hzw-2zdt; Tue, 15 Oct 2024 15:29:04 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t0jRH-00000008hWC-3Dzz for linux-arm-kernel@lists.infradead.org; Tue, 15 Oct 2024 15:26:25 +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 2E0FB1007; Tue, 15 Oct 2024 08:26:45 -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 BBA0B3F528; Tue, 15 Oct 2024 08:26:13 -0700 (PDT) Date: Tue, 15 Oct 2024 16:26:11 +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_082623_918671_C3B921C5 X-CRM114-Status: GOOD ( 39.93 ) 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:44:56PM +0200, Ard Biesheuvel wrote: > On Tue, 15 Oct 2024 at 16:35, Mark Rutland wrote: > > > > 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. > > Not sure I follow you here. The crash is in the kernel, no? Yep; I'm referring to the vmalloc space being lazily faulted-in and copied from init_mm into the active pgd under do_translation_fault(). Looking some more, I don't see how VMAP_STACK guarantees that the old/active stack is mapped in the new mm when switching from the old mm to the new mm (which happens before __switch_to()). Either I'm missing something, or we have a latent bug. Maybe we have some explicit copying/prefaulting elsewhere I'm missing? What happens when switching between two tasks whose stacks happen to be in distinct sub-trees of the vmalloc tables? > So there is only a single vmalloc space where all the mappings should > reside, but each process has its own copy of the top level page table, > which needs to be synced up when it goes stale. Yep -- the problem is when we can safely do that syncing up, since the lazy syncing in do_translation_fault() can't safely be used to sync anything that's used during do_translation_fault(), including the stack, etc. Mark.