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-H60uwMpuwOi1Jb0sgQO5oE=5AioMONAt3MtGTWzgm6uyw@mail.gmail.com>
Date: Fri, 15 Aug 2025 16:50:34 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Huacai Chen <chenhuacai@...ngson.cn>, 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 Tue, Aug 12, 2025 at 9:56 AM Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> 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.
OK, I will send V4 with strstarts().

Huacai