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