linux-kernel - Re: [PATCH 3.12] Broken terminal due to echo bufferring

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52A5E531.9010909@hurleysoftware.com>
Date:	Mon, 09 Dec 2013 10:43:45 -0500
From:	Peter Hurley <peter@...leysoftware.com>
To:	Mikulas Patocka <mpatocka@...hat.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3.12] Broken terminal due to echo bufferring

On 12/08/2013 09:55 PM, Mikulas Patocka wrote:
> Hi
>
> I discovered that kernel 3.12 has broken terminal handling.
>
> I created this program to show the problem:
> #include <stdio.h>
> #include <unistd.h>
>
> int main(void)
> {
>          int c;
>          while ((c = getchar()) != EOF) {
>                  if (c == '\n') write(1, "prompt>", 7);
>          }
>          return 0;
> }
>
> Each time the user presses enter, the program prints "prompt>". Normally,
> when you press enter, you should see:
>
> prompt>
> prompt>
> prompt>
> prompt>_
>
> However, with kernel 3.12.4, you occasionally see
>
> prompt>
> prompt>
> prompt>prompt>
> _
>
> This bug happens randomly, it is timing-dependent. I am using single-core
> 600MHz processor with preemptible kernel, the bug may or may not happen on
> other computers.
>
> This bug is caused by Peter Hurley's echo buffering patches
> (cbfd0340ae1993378fd47179db949e050e16e697). The patches change n_tty.c so
> that it accumulates echoed characters and sends them out in a batch.
> Something like this happens:
>
> * The user presses enter
> * n_tty.c adds '\n' to the echo buffer using echo_char_raw
> * n_tty.c adds '\n' to the input queue using put_tty_queue
> * A process is switched
> * Userspace reads '\n' from the terminal input queue
> * Userspace writes the string "prompt>" to the terminal
> * A process is switched back
> * The echo buffer is flushed
> * '\n' from the echo buffer is printed.
>
>
> Echo bufferring is fundamentally wrong idea - you must make sure that you
> flush the echo buffer BEFORE you add a character to input queue and BEFORE
> you send any signal on behalf of that character. If you delay echo, you
> are breaking behavior of various programs because the program output will
> be interleaved with the echoed characters.

There is nothing fundamentally broken with buffering echoes; it's just that
there is a bug wrt when to process the echoes (ie, when to force the output).

In the example you provided, the write() should cause the echoes to flush
but doesn't because the commit marker hasn't been advanced.

The commit marker wasn't advanced _yet_ because there is a race window between
the reader being woken as a result of the newline and the flush_echoes()
which happens with every received input.

Either closing the race window or advancing the commit marker prior to
write() output will fix the problem; right now, I'm looking at which is least
painful.

Regards,
Peter Hurley



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/