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]

Date:   Sun, 9 Jun 2019 21:51:32 +0200
From:   Pavel Machek <pavel@...x.de>
To:     Arseny Maslennikov <ar@...msu.ru>
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

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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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