Received-SPF: pass (google.com: domain of linux-kernel+bounces-136725-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Tue, 9 Apr 2024 13:05:48 +0200
From: Borislav Petkov <bp@alien8.de>
To: Mahmoud Younes <m.younesbadr@gmail.com>
Cc: dave.hansen@linux.intel.com, linux-kernel@vger.kernel.org,
	luto@kernel.org
Subject: Re: [PATCH] kaslr: x86: fixes log message nokaslr
Message-ID: <20240409110548.GBZhUhDGv4qXHGeXUG@fat_crate.local>
References: <20240331200546.869343-1-m.younesbadr@gmail.com>
 <20240331202827.GAZgnHayn794X_Ubs4@fat_crate.local>
 <CAMpxDQmx45VrrdZq6couUg0gU200qYdDiYF3Q=S+Nck6g-50LQ@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAMpxDQmx45VrrdZq6couUg0gU200qYdDiYF3Q=S+Nck6g-50LQ@mail.gmail.com>

On Mon, Apr 01, 2024 at 07:38:17AM +0200, Mahmoud Younes wrote:
> I don't think this gets printed after executing dmesg. This gets
> printed to console if earlyprintks are captured to the console and the
> kernel is configured with printing low level debug info. that is not
> the default behavior and requires manipulating the kernel
> configuration and command line to get this message. Specifically,
> enabling DEBUG_LL and EARLY_PRINTK and adding "earlyprintk=ttyS0" or
> whatever console in use. the message is just not visible in dmesg even
> though it would exist in kernel log buffer, just the console wouldn't
> be initialized at that moment.

If it is in the log buffer, it should come out at some point.

> this is not visible when booting a real hardware.

I don't think so - otherwise earlyprintk is broken.

> Since I am new to the kernel code base, I would appreciate some
> guidance on how to move forward. Thank you!

Since those very early params are a handful and need special treatment,
I'd prefer if they're handled explicitly as every arch does its own
thing.

So print_unknown_bootoptions() is perhaps not the best place as it is
arch-agnostic.

For this particular one:

void choose_random_location(unsigned long input,
                            unsigned long input_size,
                            unsigned long *output,
                            unsigned long output_size,
                            unsigned long *virt_addr)
{
        unsigned long random_addr, min_addr;

        if (cmdline_find_option_bool("nokaslr")) {
                warn("KASLR disabled: 'nokaslr' on cmdline.");
                return;
        }

        boot_params_ptr->hdr.loadflags |= KASLR_FLAG;

So your dummy stub could look at the loader flags and at least warn when
there's a mismatch.

And it should have a big fat comment explaining why this stub is there.

I guess that would be a good compromise between overengineering this for
no good reason and not doing anything at all and confusing users.

Thx.

-- 
Regards/Gruss,
    Boris.

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