linux-kernel - RE: [PATCH v2 RESEND] x86/kaslr: Ingest nokaslr to avoid passing it to init process

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] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <IA2PR20MB7206F52A06B7AA95B732EDE3FD182@IA2PR20MB7206.namprd20.prod.outlook.com>
Date: Tue, 14 Jan 2025 15:02:34 +0000
From: Nir Lichtman <nir_lichtman@...mail.com>
To: Borislav Petkov <bp@...en8.de>
CC: Peter Zijlstra <peterz@...radead.org>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "luto@...nel.org" <luto@...nel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com"
	<mingo@...hat.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "m.younesbadr@...il.com"
	<m.younesbadr@...il.com>, Nir Lichtman <nir@...htman.org>
Subject: RE: [PATCH v2 RESEND] x86/kaslr: Ingest nokaslr to avoid passing it
 to init process

> 
> 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.
>