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: <20190609194013.GA3736@cello>
Date:   Sun, 9 Jun 2019 22:40:14 +0300
From:   Arseny Maslennikov <ar@...msu.ru>
To:     Pavel Machek <pavel@....cz>
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 07:41:39PM +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?
> 									Pavel

If any of isig, icanon and iexten is disabled on the tty, the signal is
not sent.

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.

The commit messages of individual patches try to explain this in detail.

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