linux-kernel - Re: [PATCH 1/2] printk: Unconditionally unregister boot consoles if in init section

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]

Date:   Wed, 12 Jul 2017 13:11:17 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Matt Redfearn <matt.redfearn@...tec.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>, linux-serial@...r.kernel.org,
        Steven Rostedt <rostedt@...dmis.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] printk: Unconditionally unregister boot consoles if
 in init section

On Tue 2017-07-11 15:41:50, Matt Redfearn wrote:
> On 11/07/17 13:43, Petr Mladek wrote:
> >IMHO, the reasonable solution is to move early console code and data
> >out of the init sections. We should do this for the early consoles
> >where the corresponding real console is registered using a deferred
> >probe. Others should be already replaced by the real console when
> >printk_late_init() is called. At least this is how I understand it.
> 
> This seems like the most reasonable way forward to me as well,
> though sadly will lead to some post-init kernel bloat.
> 
> I still think, however, that this patch is a reasonable change to
> make.

The thing is that this patch "silently" makes the keep_bootcon
option almost unusable.

The remaining use in register_console() does not make much sense.
It keeps the boot console after the preferred real one was registered.

> My other patch, placing serial earlycon in the init section is then
> the wrong way round and we need to remove __init from e.g. early8250
> and so on.

Yup.

> >Matt, is there any chance that you look into this possibility?
> 
> Sure, I can look at fixing up console drivers which we use on the
> MIPS architecture.

I have discussed this with my colleagues. It seems that implementation
of keep_bootcon option is pretty broken. It allows to debug broken
system using unreliable consoles (already freed). Therefore enabling
the option adds more problems on its own.

It would be nice to fix it. But it looks rather complicated. There
are several possibilities that are more or less hacky. It is hard
to guess the best solution if we do not know who is using it, how
it helps or sucks for them.

Before we spend a lot of time on this. Let me first try to send an RFC
to remove the feature and put more people into CC. It will either
be accepted or we will get arguments that would justify the needed
changes to fix it.

Best Regards,
Petr

PS: If you already stared migrating some consoles from the init
section, I would be interested into feedback about what problems
you did meet so far.