linux-kernel - Re: [PATCH 0/4] of: bootargs handling improvement

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-prev] [day] [month] [year] [list]

Date: Mon, 20 May 2024 10:12:07 -0500
From: Rob Herring <robh@...nel.org>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
	Saravana Kannan <saravanak@...gle.com>,
	Arnd Bergmann <arnd@...db.de>, Helge Deller <deller@....de>,
	Javier Martinez Canillas <javierm@...hat.com>,
	Baoquan He <bhe@...hat.com>, Thomas Gleixner <tglx@...utronix.de>,
	Jiaxun Yang <jiaxun.yang@...goat.com>,
	David Bauer <mail@...id-bauer.net>, Liviu Dudau <liviu@...au.co.uk>,
	Serge Semin <fancer.lancer@...il.com>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mips@...r.kernel.org
Subject: Re: [PATCH 0/4] of: bootargs handling improvement

On Sun, May 12, 2024 at 03:25:07PM +0200, Christian Marangi wrote:
> This is a very simple series that try to solve a very simple problem.
> 
> Many emebedded devices have very hacked (by OEMS) bootloader that do all
> kind of modification and makes the kernel unbootable with the very first
> small modification. And also many times these broken bootloader have
> hardcoded values that can't be modified and would require risky
> procedure that can brick the device.
> 
> One of the common modification done is hardcoding bootargs in the
> appended kernel DT trashing the bootargs set in the /chosen.
> 
> The main usage of this is to have dynamic stuff to support dual
> partition scheme and make the kernel load a dedicated rootfs. But the
> other usage of this is to effectively lockup the device and cause kernel
> panic on modification like using squashfs instead of legacy jffs2.
> 
> The simple solution to this is to let the bootloader override the
> bootargs in /chosen and make the kernel parse a different property.

What happens when bootloaders start using these new "standard" bootarg 
properties and you need to override them? Perhaps name it something the 
OEM wouldn't use (maybe): 
"use-this-bootargs-instead-for-the-broken-bootloader"

> >From long time on OpenWRT we use bootargs-override as the alternative
> property for this task fixing the problem of overridden bootargs.
> 
> The second feature is bootargs-append. This is self-explanatory,
> sometimes bootargs from bootloader might be good but lack of some
> crucial things that needs to be appended, like rootfstype or rootfs
> path.

It is unfortunate that the kernel's handling of appending or prepending 
to bootargs is ambiguous. And MIPS is a further mess with handling 
cmdline from multiple sources.

I'm not really interested in adding any more complexity to the cmdline 
handling until it is made common. There's been at least 2 approaches to 
doing that.

Rob