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

Message-ID: <20201022113805.GA32486@alley>
Date:   Thu, 22 Oct 2020 13:38:05 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc:     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 Thu 2020-10-08 14:52:38, Sergey Senozhatsky wrote:
> On (20/10/08 01:29), Sergey Senozhatsky wrote:
> > On (20/10/07 08:57), Guenter Roeck wrote:
> > > On 10/7/20 5:30 AM, Sergey Senozhatsky wrote:
> > 
> > [..]
> > 
> > > I can see to options: Link /dev/console to /dev/null if there is no console,
> > > or do something like
> > > 
> > > 	if (IS_ERR(file)) {
> > >                 pr_warn("Warning: unable to open an initial console.\n");
> > >                 file = filp_open("/dev/null", O_RDWR, 0);
> > > 		if (IS_ERR(file))
> > >                 	return;
> > >         }
> > 
> > As far as I can tell, /dev/null does not exist yet on this stage
> > (at least not in my system). But generally the idea looks interesting.
> 
> 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.


> 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.

Best Regards,
Petr