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: <CAAhV-H4TToP7AY8yMUjikTLChMpMQMB1=HRaMDS7Ern5nf92Fg@mail.gmail.com>
Date: Sun, 10 Aug 2025 22:34:10 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Huacai Chen <chenhuacai@...ngson.cn>
Cc: Andrew Morton <akpm@...ux-foundation.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

Hi, Andrew,

Can you take this patch to linux-mm (seems the best tree for it)?

Huacai

On Mon, Jul 21, 2025 at 6:14 PM 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
> Signed-off-by: Huacai Chen <chenhuacai@...ngson.cn>
> ---
> V2: Update comments and commit messages.
> V3: Document bootloader identifiers.
>
>  init/main.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/init/main.c b/init/main.c
> index 225a58279acd..b25e7da5347a 100644
> --- 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;
> +       }
> +
>         /* Handle obsolete-style parameters */
>         if (obsolete_checksetup(param))
>                 return 0;
> --
> 2.47.3
>