linux-kernel - Re: VT-less kernels, and /dev/console on x86

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: <4925457.GXAFRqVoOG@nerdopolis2>
Date: Thu, 12 Sep 2024 12:48:01 -0400
From: nerdopolis <bluescreen_avenger@...izon.net>
To: linux-kernel@...r.kernel.org
Cc: Petr Mladek <pmladek@...e.com>, Steven Rostedt <rostedt@...dmis.org>,
 Greg KH <gregkh@...uxfoundation.org>, john.ogness@...utronix.de,
 senozhatsky@...omium.org, tglx@...utronix.de, tony@...mide.com
Subject: Re: VT-less kernels, and /dev/console on x86

On Tuesday, August 27, 2024 9:46:49 AM EDT Willy Tarreau wrote:
> On Tue, Aug 27, 2024 at 08:53:49AM -0400, nerdopolis wrote:
> > > > If I get it correctly, you suggest to do not register serial port
> > > > when it is not physically connected. It makes some sense.
> > > > 
> > > Hmm, now that might work, and is a good idea...
> > Although now that I think about it, could this cause unintended behavior on
> > some hardware? Or folks that might plug in the serial cable after booting for
> > whatever reason?
> 
> The *vast* majority of serial ports spend their time non-connected, and
> are only used to connect to the equipment at runtime, to recover a lost
> access, or to connect locally to it during operations. What is proposed
> above scares me a little bit:
>   - PC-like serial ports (DB-9) support hardware flow control using the
>     RTS/CTS lines and are expected to be instantly usable when connecting
>     something to them. The presence of a cable is detectable, though many
>     will just have a local loop (CTS-RTS, DCD-DTR-DSR) and will in fact
>     only detect that the connector is plugged in. Some don't even connect
>     them, and turn off HW flow control.
> 
>   - many boards don't even have hardware flow control and only provide
>     the usual 3-4 pins (GND, TX, RX and optional VCC). These ones will
>     never be detected as "connected" and will be permanently broken.
> 
> > I still kind of lean to CONFIG_NULL_TTY_CONSOLE, that way if enabled, and in
> > theory, only distributions that had CONFIG_VT_CONSOLE turned on would turn on
> > this option. That could allow /dev/console will still work the same way for
> > user space logging, while disabling vgacon and fbcon.
> > 
> > And it could still be overridden by console=ttyS0, which I think is needed
> > anyway if you have CONFIG_VT_CONSOLE enabled
> 
> That sounds safer. And even then, I still don't understand why the application
> logging to /dev/console needs to block on it instead of just dropping whatever
> doesn't fit there since that's the primary intent of an optional logging
> console, i.e. emit events but without preventing regular operations. Maybe
> *this* is the thing that would require a setting: wait or drop.
> 
Sorry about the late reply, the application that is logging and dropping is
kind of unintentional I think. From how I understand it, systemd wants to
verify that /dev/console is actually /dev/console, so it calls isatty() on it.

isatty() in turn calls the TCGETS ioctl on /dev/console, which when the console
device is actually /dev/ttyS0, and /dev/ttyS0 is unplugged, it the ioctl fails,
and isatty() returns false, and systemd assumes that it is not a serial device,
and in turn it doesn't log because of that.

Thanks
> Just my two cents,
> Willy
>