linux-kernel - Re: [PATCH] x86/setup: Deal with "quiet" commandline option earlier

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: <71db02a8-2732-85ee-bb66-14ac26f24eaf@redhat.com>
Date:   Tue, 4 Sep 2018 17:25:04 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        Steven Rostedt <rostedt@...dmis.org>,
        Petr Mladek <pmladek@...e.com>,
        Maninder Singh <maninder1.s@...sung.com>
Subject: Re: [PATCH] x86/setup: Deal with "quiet" commandline option earlier

Hi,

On 04-09-18 16:42, Hans de Goede wrote:
> X86's setup_arch() calls parse_early_param() somewhat late, to make
> sure that everything is setup correcty to deal with earlyprintk over
> the EHCI debug port.
> 
> This means that a number of pr_info-s get done before
> "early_param("quiet", quiet_kernel)" from init/main.c gets processed.
> 
> Until commit 375899cddcbb ("printk: make sure to print log on console.")
> this was not a problem because the printk code would evaluate the
> console_loglevel vs the message-loglevel when flushing the buffer.
> 
> After this commit the check is done at the time that pr_info is actually
> called and the console_loglevel at calling time.
> 
> This causes the following messages to get printed with the "quiet" option:
> 
> [    0.000000] BIOS-provided physical RAM map:
> [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usable
> ...
> [    0.000000] BIOS-e820: [mem 0x0000000100000000-0x0000000874ffffff] usable
> 
> This commit fixes this by making x86's setup_arch() explicitly check for
> quiet early on.
> 
> Cc: Petr Mladek <pmladek@...e.com>
> Cc: Maninder Singh <maninder1.s@...sung.com>
> Fixes: 375899cddcbb ("printk: make sure to print log on console.")
> Signed-off-by: Hans de Goede <hdegoede@...hat.com>

Self-nack, I accidentally still had the revert of commit
375899cddcbb ("printk: make sure to print log on console.") in
my tree while testing…

In order for my approach to work, we need to deal with the quiet
option even earlier, before the first pr_notice in init/main.c,
which requires access to the commandline before setup_arch()
which is the function which fills the boot_command_line on
several architectures.

So I think we need to look at a different approach.

I have one more idea, if that does not work out I think we
just need to revert 375899cddcbb ("printk: make sure to print log on console.")

Regards,

Hans




> ---
>   arch/x86/kernel/setup.c | 11 +++++++++++
>   1 file changed, 11 insertions(+)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index b4866badb235..38f66b14cf3d 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -93,6 +93,7 @@
>   #include <asm/processor.h>
>   #include <asm/bugs.h>
>   #include <asm/kasan.h>
> +#include <asm/cmdline.h>
>   
>   #include <asm/vsyscall.h>
>   #include <asm/cpu.h>
> @@ -864,6 +865,16 @@ void __init setup_arch(char **cmdline_p)
>   	boot_cpu_data.x86_phys_bits = MAX_PHYSMEM_BITS;
>   #endif
>   
> +#if !defined CONFIG_CMDLINE_BOOL || !defined CONFIG_CMDLINE_OVERRIDE
> +	/*
> +	 * We call parse_early_param() somewhat late, see x86_configure_nx()
> +	 * comment. Deal with "quiet" here to suppress printing of early
> +	 * boot messages when quiet has been requested.
> +	 */
> +	if (cmdline_find_option_bool(boot_command_line, "quiet"))
> +		console_loglevel = CONSOLE_LOGLEVEL_QUIET;
> +#endif
> +
>   	/*
>   	 * If we have OLPC OFW, we might end up relocating the fixmap due to
>   	 * reserve_top(), so do this before touching the ioremap area.
>