linux-kernel - Re: ptrace and pseudoterminals

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: <563A3A32.2030102@hurleysoftware.com>
Date:	Wed, 4 Nov 2015 12:02:42 -0500
From:	Peter Hurley <peter@...leysoftware.com>
To:	Pavel Labath <labath@...gle.com>, Oleg Nesterov <oleg@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: ptrace and pseudoterminals

Hi Pavel,

On 11/03/2015 06:16 PM, Pavel Labath wrote:
> Hello Oleg, everyone,
> 
> I have noticed something, which may be considered a race in the
> interaction of ptrace and pseudoterminal interfaces. Basically, what
> happens is this:
> - we have two processes: A and B. B has the slave end of the pty open,
> A has the master. A is tracing B.
> - B writes some data through the slave end and then stops.
> - A waits for B to stop.
> - A does a select on the master pty endpoint. select returns there is
> no data available
> - later, A tries the select again, and this time the data appears.

This happens because a separate kworker processes the input from slave
and wakes the master. At the moment of select() on the master pty, the
kworker has not processed the latest input (in fact it may only be
scheduled and not running yet).

Essentially, you're measuring a asynchronous i/o path with a synchronous
method.

> We are encountering this (very rare) issue in our debugger test suite,
> where we check the stdout of the tracee to make sure it is behaving as
> expected. I have attached a small program reproducing this behavior
> (it fails after about 1000 iterations on a 3.13.0 kernel, I can retry
> it on a newer kernel next week if you believe it might work there).
> Interestingly, when I replace the pty with a regular pipe, it works as
> expected (the data is available as soon as the program stops).
> 
> My question is: Is this behavior something that you would consider a
> bug? If yes, do you have any pointers, as to where I should look to
> fix it?

I don't consider it a bug.

That said, I could see a couple of different ways to add this
functionality:
1. Implement f_op->fsync() for ttys, which would flush the workqueue
   (thus waiting for i/o completion). The debugger would fsync() before
   select() on the master.
2. Automagically for ptraced processes. The basic idea would be that
   writes to the slave end while a process was being ptraced would
   set state that would trigger workqueue flush by select/poll/read of
   the master end.

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/