linux-kernel - Re: [PATCH] printk: handle blank console arguments passed in.

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: <20201022133228.GA160085@jagdpanzerIV.localdomain>
Date:   Thu, 22 Oct 2020 22:32:28 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Shreyas Joshi <shreyas.joshi@...mp.com>, rostedt@...dmis.org,
        shreyasjoshi15@...il.com, linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] printk: handle blank console arguments passed in.

On (20/10/22 13:38), Petr Mladek wrote:
> > Hmm. How about this. console= is undocumented and unspecified - it
> > may work sometimes or it may kill the system (and theoretically even
> > corrupt some files, depending on what fd 1 and fd 2 point to). So
> > maybe we can document console= and handle it in printk, rather than
> > somewhere deep in init/main.c
> 
> I have dig more into it. If I get it correctly, /dev/console is really
> used as stdin, stdout, and stderr for the init process. It has been
> like this from the very beginning.
> 
> In theory, it might be possible to fallback into /dev/null. But it
> would not solve the problem when anyone tries to use /dev/console
> later.
> 
> IMHO, creating /dev/console really _should not_ fail. It means
> that we should register some console.

Yes, I didn't find out exactly why the kernel panics yet. Got
interrupted. What I did notice (when we don't have stdin/out/err)
was init process installing "/" as fd 0, and then doing things
like fprintf(stderr, "running early hook"), perhaps some of those
fprintf()-s end up in the wrong place.

> > IOW add one more flag (yeah, I know) and set it when console_setup()
> > sees console= boot param. The idea is allow console registration,
> > but all consoles should be disabled (cleared CON_ENABLED bit). This
> > would be easier to document, at least.
> 
> It seems that introducing a new option/flag is the best solution
> after all. All other flags are manipulated on different situations
> and it would not be easy to define a sane behavior.
> 
> I like the proposed "mute_consoles". Well, I have it associated rather
> with CONSOLE_LOGLEVEL_SILENT than with disabled console.
> 
> I have played with it and am going to send two patches as RFC.

Cool, thanks. I'll reply to that RFC patch set; there are some
more ideas, that we can discuss.

	-ss