linux-kernel - Re: [PATCH V3] init: Handle bootloader identifier in kernel parameters

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]

Message-Id: <20250811185635.f51ddda72f36bc0c2ba20600@linux-foundation.org>
Date: Mon, 11 Aug 2025 18:56:35 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Huacai Chen <chenhuacai@...ngson.cn>
Cc: Huacai Chen <chenhuacai@...nel.org>, linux-mm@...ck.org, Alexander Viro
 <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, Jan Kara
 <jack@...e.cz>, linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH V3] init: Handle bootloader identifier in kernel
 parameters

On Mon, 21 Jul 2025 18:13:43 +0800 Huacai Chen <chenhuacai@...ngson.cn> wrote:

> BootLoader (Grub, LILO, etc) may pass an identifier such as "BOOT_IMAGE=
> /boot/vmlinuz-x.y.z" to kernel parameters. But these identifiers are not
> recognized by the kernel itself so will be passed to user space. However
> user space init program also doesn't recognized it.
> 
> KEXEC/KDUMP (kexec-tools) may also pass an identifier such as "kexec" on
> some architectures.
> 
> We cannot change BootLoader's behavior, because this behavior exists for
> many years, and there are already user space programs search BOOT_IMAGE=
> in /proc/cmdline to obtain the kernel image locations:
> 
> https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/util.go
> (search getBootOptions)
> https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/main.go
> (search getKernelReleaseWithBootOption)
> 
> So the the best way is handle (ignore) it by the kernel itself, which
> can avoid such boot warnings (if we use something like init=/bin/bash,
> bootloader identifier can even cause a crash):
> 
> Kernel command line: BOOT_IMAGE=(hd0,1)/vmlinuz-6.x root=/dev/sda3 ro console=tty
> Unknown kernel command line parameters "BOOT_IMAGE=(hd0,1)/vmlinuz-6.x", will be passed to user space.
> 
> Cc: stable@...r.kernel.org

I think I'll keep this in -next until 6.18-rc1 - I suspect any issues
here will take a while to discover.

> --- a/init/main.c
> +++ b/init/main.c
> @@ -545,6 +545,12 @@ static int __init unknown_bootoption(char *param, char *val,
>  				     const char *unused, void *arg)
>  {
>  	size_t len = strlen(param);
> +	/*
> +	 * Well-known bootloader identifiers:
> +	 * 1. LILO/Grub pass "BOOT_IMAGE=...";
> +	 * 2. kexec/kdump (kexec-tools) pass "kexec".
> +	 */
> +	const char *bootloader[] = { "BOOT_IMAGE=", "kexec", NULL };
>  
>  	/* Handle params aliased to sysctls */
>  	if (sysctl_is_alias(param))
> @@ -552,6 +558,12 @@ static int __init unknown_bootoption(char *param, char *val,
>  
>  	repair_env_string(param, val);
>  
> +	/* Handle bootloader identifier */
> +	for (int i = 0; bootloader[i]; i++) {
> +		if (!strncmp(param, bootloader[i], strlen(bootloader[i])))
> +			return 0;
> +	}

We have str_has_prefix().

And strstarts()!  Both of which are awfully similar and both of which
lamely do two passes across a string.