Re: [PATCH] kaslr: x86: fixes log message nokaslr

From: Borislav Petkov
Date: Tue Apr 09 2024 - 07:06:14 EST


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