RE: [PATCH v2 RESEND] x86/kaslr: Ingest nokaslr to avoid passing it to init process
From: Nir Lichtman
Date: Tue Jan 14 2025 - 10:02:44 EST
>
> On Tue, Jan 14, 2025 at 02:37:52PM +0000, Nir Lichtman wrote:
> > I agree that the warning is not a big deal, thing is the kernel has a
> > fallback behavior in which unrecognized boot parameters are passed to
> > the init process, this causes the nokaslr to be passed to the init
> > process, you probably haven't stumbled upon this since it may be
> > swallowed in your system, but when I made an initramfs with bash as
> > the init process, bash got the nokaslr as an argument and crashed since it
> treated it as a file.
>
> Come again?! By that logic bash would be crashing left'n'right since the kernel
> has been doing this forever.
Yes indeed, when I made an initramfs with cpio and put a static bash build as ./init,
It got the nokaslr as the first argument and crashed, this causes a general panic since
the init process crashed.
This behavior of passing unrecognized params to the init process is documented
in the kernel docs, and also in the corresponding warning message.
>
> > Borslav, print_unknown_bootoptions is an interesting alternative idea,
> > I could amend this patch to swallow the early parameters over there,
> > Thing is this, from what I understand it would require the code to
> > keep a list of possible early parameters and check if one of them
> > arrived into the print_unknown_bootoptions function and if so swallow
> > in that function, what do you think about this idea, to implement this?
>
> That's exactly why I say it is "meh". Not convinced that adding a bunch of code
> just to prevent warnings...
>
> Looking at __setup_param, it does already stick those params into a separate
> section. Now, if print_unknown_bootoptions() would be smart enough to
> inspect that section, to compare strings and swallow a param on a match, that
> might be a relatively clever way of fixing this without doing any explicit hackery
Sounds interesting, I'll take a look at that.
> ...
>
> I'd say.
>
> --
> Regards/Gruss,
> Boris.
>