From: Greg KH <gregkh@linuxfoundation.org>
To: Huacai Chen <chenhuacai@kernel.org>
Cc: Huacai Chen <chenhuacai@loongson.cn>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] init: Handle bootloader head in kernel parameters
Date: Fri, 11 Jul 2025 14:40:54 +0200 [thread overview]
Message-ID: <2025071116-pushchair-happening-a4cf@gregkh> (raw)
In-Reply-To: <CAAhV-H7oEv5jPufY+J-0wOax=m1pszck1__Ptapz5pmzYU5KHg@mail.gmail.com>
On Fri, Jul 11, 2025 at 08:34:25PM +0800, Huacai Chen wrote:
> Hi, Greg,
>
> On Fri, Jul 11, 2025 at 7:06 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Jul 11, 2025 at 06:24:55PM +0800, Huacai Chen wrote:
> > > BootLoader may pass a head such as "BOOT_IMAGE=/boot/vmlinuz-x.y.z" to
> > > kernel parameters. But this head is not recognized by the kernel so will
> > > be passed to user space. However, user space init program also doesn't
> > > recognized it.
> >
> > Then why is it on the kernel command line if it is not recognized?
> UEFI put it at the beginning of the command line, you can see it from
> /proc/cmdline, both on x86 and LoongArch.
Then fix UEFI :)
My boot command line doesn't have that on x86, perhaps you need to fix
your bootloader?
> > > KEXEC may also pass a head such as "kexec" on some architectures.
> >
> > That's fine, kexec needs this.
> >
> > > So the the best way is handle it by the kernel itself, which can avoid
> > > such boot warnings:
> > >
> > > 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.
> >
> > Why is this a problem? Don't put stuff that is not needed on the kernel
> > command line :)
> Both kernel and user space don't need it, and if it is passed to user
> space then may cause some problems. For example, if there is
> init=/bin/bash, then bash will crash with this parameter.
Again, fix the bootloader to not do this, why is the kernel responsible
for this?
What has suddenly changed to now require this when we never have needed
it before?
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > ---
> > > init/main.c | 7 +++++++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/init/main.c b/init/main.c
> > > index 225a58279acd..9e0a7e8913c0 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 };
> >
> > You need to document why these are ok to "swallow" and not warn for.
> Because they are bootloader heads, not really a wrong parameter. We
> only need a warning if there is a wrong parameter.
Again, fix the bootloader.
> > >
> > > /* Handle params aliased to sysctls */
> > > if (sysctl_is_alias(param))
> > > @@ -552,6 +553,12 @@ static int __init unknown_bootoption(char *param, char *val,
> > >
> > > repair_env_string(param, val);
> > >
> > > + /* Handle bootloader head */
> >
> > Handle it how?
> argv_init and envp_init arrays will be passed to userspace, so just
> return early (before argv_init and envp_init handling) can avoid it
> being passed.
You need to document this way better.
But again, please just fix your bootloader to not pass on lines to the
kernel that it can not parse.
thanks,
greg k-h
next prev parent reply other threads:[~2025-07-11 12:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-11 10:24 Huacai Chen
2025-07-11 11:06 ` Greg KH
2025-07-11 12:34 ` Huacai Chen
2025-07-11 12:40 ` Greg KH [this message]
2025-07-11 12:51 ` Huacai Chen
2025-07-11 13:04 ` Greg KH
2025-07-12 15:18 ` Huacai Chen
2025-07-13 8:30 ` Greg KH
2025-07-13 9:11 ` Huacai Chen
2025-07-13 9:35 ` Greg KH
2025-07-14 10:18 ` Huacai Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025071116-pushchair-happening-a4cf@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=chenhuacai@kernel.org \
--cc=chenhuacai@loongson.cn \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox