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: <20250114145521.GDZ4Z62dOwYffaUrsr@fat_crate.local>
Date: Tue, 14 Jan 2025 15:55:21 +0100
From: Borislav Petkov <bp@...en8.de>
To: Nir Lichtman <nir_lichtman@...mail.com>
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.

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

I'd say.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette