linux-kernel - Re: [PATCH V2] 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-H5nHBuXao1NGgSyD5CJzFHg6Vf0s+Fr3TadH01KjsMDSw@mail.gmail.com>
Date: Mon, 21 Jul 2025 18:10:55 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Huacai Chen <chenhuacai@...ngson.cn>, 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 V2] init: Handle bootloader identifier in kernel parameters

On Sun, Jul 20, 2025 at 7:10 PM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Sun, Jul 20, 2025 at 06:55:09PM +0800, Huacai Chen 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 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.
> >
> >  init/main.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/init/main.c b/init/main.c
> > index 225a58279acd..c53863e5ad82 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -545,6 +545,7 @@ static int __init unknown_bootoption(char *param, char *val,
> >                                    const char *unused, void *arg)
> >  {
> >       size_t len = strlen(param);
> > +     const char *bootloader[] = { "BOOT_IMAGE=", "kexec", NULL };
>
> Where is this magic set of values now documented?  Each of these need to
> be strongly documented as to why we are ignoring them and who is adding
> them and why they can't be fixed for whatever reason.
OK, will do.

Huacai
>
> thanks,
>
> greg k-h