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: <2284924.iZASKD2KPV@nerdopolis2>
Date: Thu, 12 Sep 2024 22:22:29 -0400
From: nerdopolis <bluescreen_avenger@...izon.net>
To: Willy Tarreau <w@....eu>
Cc: linux-kernel@...r.kernel.org, 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 Thursday, September 12, 2024 2:46:04 PM EDT nerdopolis wrote:
> On Thursday, September 12, 2024 1:25:22 PM EDT Willy Tarreau wrote:
> > On Thu, Sep 12, 2024 at 12:48:01PM -0400, nerdopolis wrote:
> > > > > 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.
> > 
> > OK.
> > 
> > > 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.
> > 
> > I'm no tty expert at all, but on this machine I'm having this:
> > 
> >   # dmesg|grep console
> >   [    0.000000] Kernel command line: boot_image=l0 console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait
> >   [    1.638242] printk: console [ttyS0] disabled
> >   [    2.848759] printk: console [ttyS0] enabled
> >   [   12.950334] systemd[1]: Starting Set the console keyboard layout...
> > 
> >   # cat /proc/consoles 
> >   ttyS0                -W- (EC p a)    4:64
> > 
> >   # strace -e trace=ioctl stty -a < /dev/console 
> >   ioctl(0, TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
> >   ioctl(1, TIOCGWINSZ, {ws_row=30, ws_col=152, ws_xpixel=1534, ws_ypixel=604}) = 0
> >   ioctl(0, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
> >   speed 115200 baud; rows 24; columns 80; line = 0;
> >   intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
> >   werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
> >   -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
> >   -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel iutf8
> >   opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
> >   -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho -extproc
> >   +++ exited with 0 +++
> > 
> > So TCGETS succeeded above, and the console is unplugged. Even if I enable
> > HW flow control (crtscts) the result is the same BTW (I preferred to check).
> > Same if I enable carrier detection (-clocal).
> > 
> I think you bypassed the issue by specifying a baudrate (which must be forcing
> it on?) instead of letting it select an automatic one. try with just
> console=ttyS0 ? 
> > So I'm unsure what would cause TCGETS to fail in your case.
> > 
Looks line I am wrong about the baud rate turning it on, I did more testing.
That is odd, I tested on my laptop and on qemu with "-serial none" and booting 
with console=ttyS0 and stty results in an input output error.
> > Willy
> > 
> 
>