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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ