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: <Zs3YyYG0RwNcG2vL@1wt.eu>
Date: Tue, 27 Aug 2024 15:46:49 +0200
From: Willy Tarreau <w@....eu>
To: nerdopolis <bluescreen_avenger@...izon.net>
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,
        linux-kernel@...r.kernel.org
Subject: Re: VT-less kernels, and /dev/console on x86

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.

Just my two cents,
Willy