linux-kernel - powerpc: several early boot regressions on MPC52xx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <46a002f7fe894c7c7ed8324e48e9cd226e428894.camel@ew.tq-group.com>
Date: Mon, 18 Dec 2023 14:48:59 +0100
From: Matthias Schiffer <matthias.schiffer@...tq-group.com>
To: Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin
 <npiggin@...il.com>,  Christophe Leroy <christophe.leroy@...roup.eu>,
 "Aneesh Kumar K.V" <aneesh.kumar@...nel.org>, "Naveen N. Rao"
 <naveen.n.rao@...ux.ibm.com>, Anatolij Gustschin <agust@...x.de>
Cc: linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org, 
	linux@...tq-group.com
Subject: powerpc: several early boot regressions on MPC52xx

Hi all,

I'm currently in the process of porting our ancient TQM5200 SoM to a modern kernel, and I've
identified a number of regressions that cause early boot failures (before the UART console has been
initialized) with arch/powerpc/configs/52xx/tqm5200_defconfig.

Issue 1) Boot fails with CONFIG_PPC_KUAP enabled (enabled by default since 9f5bd8f1471d7
"powerpc/32s: Activate KUAP and KUEP by default"). The reason is a number of of_iomap() calls in
arch/powerpc/platforms/52xx that should be early_ioremap().

I can fix this up easy enough for mpc5200_simple by changing mpc5200_setup_xlb_arbiter() to use
early_ioremap() and moving mpc52xx_map_common_devices() from the setup_arch to the init hook (one
side effect is that mpc52xx_restart() only works a bit later, as it requires the mpc52xx_wdt mapping
from mpc52xx_map_common_devices(); I'm not sure if there is a better solution).

For the other 52xx platforms (efika, lite5200, media5200) things are a bit more chaotic, and they
create several more temporary mappings from setup_arch. Either they should all be moved to the init
hook as well, or be converted to early_ioremap(), but I can't tell which is more appropriate. As a
first step, I would propose a patch that fixes this for the simple platforms and leaves the other
ones unchanged.

(Side note: I also found that before 16132529cee58 ("powerpc/32s: Rework Kernel Userspace Access
Protection"), boot would succeed even with KUAP enabled without changing the incorrect of_iomap(); I
guess the old implementation was more lenient about the incorrect calls that the kernel warns
about?)

Issue 2) Boot fails with CONFIG_STRICT_KERNEL_RWX enabled, which is also the default nowadays.

I have not found the cause of this boot failure yet; is there any way to debug this if the failure
happens before the UART is available and I currently don't have JTAG for this hardware?

Best regards,
Matthias

-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/