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: <CAJt8pk8RREqfiop_4_iz263CjpOPfVTKqG4b3uOEr+ixHdW+EA@mail.gmail.com>
Date:	Thu, 5 Nov 2015 10:35:15 -0800
From:	Pavel Labath <labath@...gle.com>
To:	Peter Hurley <peter@...leysoftware.com>
Cc:	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: ptrace and pseudoterminals

On 5 November 2015 at 05:25, Peter Hurley <peter@...leysoftware.com> wrote:
> On 11/04/2015 02:43 PM, Oleg Nesterov wrote:
>> Oh, I don't think "Automagically if ptrace" makes any sense... What makes
>> ptrace special? Afaics nothing.
>>
>> We can modify this test-case to use signals/futexes/whatever to let the
>> the parent know that the child has already done write(writefd), and it can
>> "fail" the same way.
>
> True.
>
> Also, new patches in mainline head make this _much_ less likely
> by scheduling the input processing kworker on the unbound wq (which means
> the kworker can start immediately on another cpu rather than pinned to
> the cpu performing the slave write).
>
> After thinking more about this, this use-case seems trivially solvable
> by re-select()ing with a timeout prior to reporting mismatch output
> failure.
>
> Regards,
> Peter Hurley
>

Thank you for the replies.

I agree that this can be worked around on our side, but I wanted to
confirm whether this is expected behavior or a bug. Judging from your
answers, it seems this is working as intended.

That said, it seems to me that this could be a generally useful
feature. For the test suite, I can insert a sleep (even a large one,
to be sure), but this seems like a sub-optimal solution for general
debugger operation. E.g., when we want to display all tracee output(*)
before we print out the debugger prompt, we don't know if the tracee
has written anything, and we would need to sleep always, just in case
it has done that. This is especially tricky for remote debugging, as
the current gdb-remote protocol does not allow sending stdio after the
stop notification. So, I actually quite like the fsync() idea, but I
don't know if this is something that would be generally accepted (?).

(*) To avoid mixing output we don't have the tracee share the same
terminal with the debugger, but we create a new one, and do the
forwarding ourselves. Aside from avoiding output mixing, this
facilitates IDE integration, remote debugging, etc.

A side question: When I replace the pty with a pipe, the data seems to
be delivered immediately. Is this something that is guaranteed, or
this happens to work only accidentally and could change in the future
(e.g. by moving the pipe processing to a kworker process or whatever)?

regards,
pl
--
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/