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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3B2B2C433EF for ; Mon, 30 May 2022 13:38:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237788AbiE3Nit (ORCPT ); Mon, 30 May 2022 09:38:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237676AbiE3Ngz (ORCPT ); Mon, 30 May 2022 09:36:55 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D81B912AC9; Mon, 30 May 2022 06:30:42 -0700 (PDT) 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 7335560EE0; Mon, 30 May 2022 13:30:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5522C3411E; Mon, 30 May 2022 13:30:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1653917441; bh=goT196KiQfwpElqIN5celghRGMAp8wKph89erWgkuJs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Hj/4SE4A010FbUEQAls4F84IV/Xz8wrElP8AZy+mpbgWU9vus8n256RNyZBMZfYmT cA0qpOuPGW7aIYMGHa384k57m4HK4Jd4HXToHcF2YbF0i1cwkTH9Veh4m0XwEO5c2W EIAQGNBZnqN59qp3ORBrno70tkeXi3rF7wanvA9VQMS9LSd/4gOD4+hUwktfDMgq8O 8HD35PPJeajxVqx/2CdIFPmTN7hkEM6JLm0xW37vcMv3oVWPXxMPKNeO3r1WdUEwlZ YItqALvk4gWoqDFLlXvA2qbjBZ7pwJYAsrDeh39BbLEmzLpOBd9t8TzzCrRVsm1uKu 6xgzWmMaI9qnQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andre Przywara , Ross Burton , Rob Herring , Sasha Levin , robh+dt@kernel.org, frowand.list@gmail.com, devicetree@vger.kernel.org Subject: [PATCH AUTOSEL 5.18 138/159] of/fdt: Ignore disabled memory nodes Date: Mon, 30 May 2022 09:24:03 -0400 Message-Id: <20220530132425.1929512-138-sashal@kernel.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220530132425.1929512-1-sashal@kernel.org> References: <20220530132425.1929512-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org From: Andre Przywara [ Upstream commit df5cd369876114f91f9ae60658fea80acfb15890 ] When we boot a machine using a devicetree, the generic DT code goes through all nodes with a 'device_type = "memory"' property, and collects all memory banks mentioned there. However it does not check for the status property, so any nodes which are explicitly "disabled" will still be added as a memblock. This ends up badly for QEMU, when booting with secure firmware on arm/arm64 machines, because QEMU adds a node describing secure-only memory: =================== secram@e000000 { secure-status = "okay"; status = "disabled"; reg = <0x00 0xe000000 0x00 0x1000000>; device_type = "memory"; }; =================== The kernel will eventually use that memory block (which is located below the main DRAM bank), but accesses to that will be answered with an SError: =================== [ 0.000000] Internal error: synchronous external abort: 96000050 [#1] PREEMPT SMP [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc6-00014-g10c8acb8b679 #524 [ 0.000000] Hardware name: linux,dummy-virt (DT) [ 0.000000] pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.000000] pc : new_slab+0x190/0x340 [ 0.000000] lr : new_slab+0x184/0x340 [ 0.000000] sp : ffff80000a4b3d10 .... ================== The actual crash location and call stack will be somewhat random, and depend on the specific allocation of that physical memory range. As the DT spec[1] explicitly mentions standard properties, add a simple check to skip over disabled memory nodes, so that we only use memory that is meant for non-secure code to use. That fixes booting a QEMU arm64 VM with EL3 enabled ("secure=on"), when not using UEFI. In this case the QEMU generated DT will be handed on to the kernel, which will see the secram node. This issue is reproducible when using TF-A together with U-Boot as firmware, then booting with the "booti" command. When using U-Boot as an UEFI provider, the code there [2] explicitly filters for disabled nodes when generating the UEFI memory map, so we are safe. EDK/2 only reads the first bank of the first DT memory node [3] to learn about memory, so we got lucky there. [1] https://github.com/devicetree-org/devicetree-specification/blob/main/source/chapter3-devicenodes.rst#memory-node (after the table) [2] https://source.denx.de/u-boot/u-boot/-/blob/master/lib/fdtdec.c#L1061-1063 [3] https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/PrePi/FdtParser.c Reported-by: Ross Burton Signed-off-by: Andre Przywara Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220517101410.3493781-1-andre.przywara@arm.com Signed-off-by: Sasha Levin --- drivers/of/fdt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index ec315b060cd5..0f30496ce80b 100644 --- a/drivers/of/fdt.c +++ b/drivers/of/fdt.c @@ -1105,6 +1105,9 @@ int __init early_init_dt_scan_memory(void) if (type == NULL || strcmp(type, "memory") != 0) continue; + if (!of_fdt_device_is_available(fdt, node)) + continue; + reg = of_get_flat_dt_prop(node, "linux,usable-memory", &l); if (reg == NULL) reg = of_get_flat_dt_prop(node, "reg", &l); -- 2.35.1