linux-kernel - Re: [PATCH 0/7] TTY Keyboard Status Request

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: <20190609205610.GB3736@cello>
Date:   Sun, 9 Jun 2019 23:56:10 +0300
From:   Arseny Maslennikov <ar@...msu.ru>
To:     Pavel Machek <pavel@...x.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>, Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org,
        "Vladimir D . Seleznev" <vseleznv@...linux.org>
Subject: Re: [PATCH 0/7] TTY Keyboard Status Request

On Sun, Jun 09, 2019 at 09:51:32PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > This patch series introduces TTY keyboard status request, a feature of
> > > > the n_tty line discipline that reserves a character in struct termios
> > > > (^T by default) and reacts to it by printing a short informational line
> > > > to the terminal and sending a Unix signal to the tty's foreground
> > > > process group. The processes may, in response to the signal, output a
> > > > textual description of what they're doing.
> > > > 
> > > > The feature has been present in a similar form at least in
> > > > Free/Open/NetBSD; it would be nice to have something like this in Linux
> > > > as well. There is an LKML thread[1] where users have previously
> > > > expressed the rationale for this.
> > > > 
> > > > The current implementation does not break existing kernel API in any
> > > > way, since, fortunately, all the architectures supported by the kernel
> > > > happen to have at least 1 free byte in the termios control character
> > > > array.
> > > 
> > > I like the idea... I was often wondering "how long will this dd take". (And in
> > > case of dd, SIGUSR1 does the job).
> > > 
> > > I assume this will off by default, so that applications using ^T today will not
> > > get surprise signals?
> > 
> > If any of isig, icanon and iexten is disabled on the tty, the signal is
> > not sent.
> 
> As expected.
> 
> > Any application that wants to handle raw terminal input events itself,
> > e.g. vim, mutt, libreadline, anything ncurses-based, etc., has to turn
> > off the tty's cooked mode, i.e. at least icanon. This means those
> > applications are unaffected.
> 
> Agreed, those are unaffected.
> 
> But if I have an application doing read() from console (without
> manipulating tty), am I going to get surprise signal when user types
> ^T?
> 
> 	     	      	      	     	      	     	       	     Pavel

As of now, that application will indeed receive a signal that is
guaranteed to be ignored by default.

This is similar to SIGWINCH, which is default-ignored as well: if the
terminal width/height changes (like when a terminal emulator window is
resized), its foreground pgrp gets a surprise signal as well, and the
processes that don't care about WINCH (and thus have default
disposition) do not get confused.
E.g. 'strace cat' demonstrates this quite clearly.


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)