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]
Message-ID: <ZAm/wMIYOOkjL/Mf@alley>
Date:   Thu, 9 Mar 2023 12:15:12 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Lukas Wunner <lukas@...ner.de>
Cc:     Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        John Ogness <john.ogness@...utronix.de>,
        Lino Sanfilippo <LinoSanfilippo@....de>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH for-6.4] printk: Unregister boot consoles on register of
 1st real console

On Thu 2022-02-24 05:40:33, Lukas Wunner wrote:
> The code comment preceding register_console() claims that:
> 
>    "There are two types of consoles - bootconsoles (early_printk) and
>     "real" consoles (everything which is not a bootconsole) which are
>     handled differently. [...]
>     As soon as a "real" console is registered, all bootconsoles
>     will be unregistered automatically."
> 
> But that's not what the code does:  The code unregisters bootconsoles
> only when the *preferred* console registers, i.e. the last one on the
> command line.

Yes

> If that console's driver never registers (e.g. because
> it is disabled in the kernel config), bootconsoles stay around
> indefinitely.

They are actually unregistered by a late_initcall, see
printk_late_init().

> Should the command line contain both a bootconsole as
> well as a real console on the same serial port, all messages are logged
> twice once the real console registers.
> 
> Moreover, the log buffer is replayed once the real console registers
> even though the messages were already emitted by the bootconsole.

Yes, the messages might get duplicated until the printk_late_init()
is called. And the log might get replayed even though it was already
printed on the boot console.

> Amend the code to be congruent with the above-quoted code comment and
> thereby avoid these issues.

I am afraid that we could not change the behavior. It would cause
the opposite problem. It might might remove the boot consoles too early
and some messages might be missing on the corresponding console.
Also the log might get replayed on the "preferred" console.
People would see this as regression.

The only acceptable solution would be to do the right thing.
I mean to match the corresponding boot and real consoles.
Then we could remove the boot console exactly when it is replaced
by the real one. It would prevent any duplicated or lost messages.

In the meantime, we could only fix the comment so that it describes
the current behavior.

Best Regards,
Petr

Best Regards,
Petr

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ