linux-kernel - Re: [PATCH] kaslr: x86: fixes log message nokaslr

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

Date: Tue, 9 Apr 2024 13:05:48 +0200
From: Borislav Petkov <bp@...en8.de>
To: Mahmoud Younes <m.younesbadr@...il.com>
Cc: dave.hansen@...ux.intel.com, linux-kernel@...r.kernel.org,
	luto@...nel.org
Subject: Re: [PATCH] kaslr: x86: fixes log message nokaslr

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