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] [day] [month] [year] [list]

Message-ID: <CAJt8pk-QLs9AtKhyENxuPxPpEh=w0fOT4Uo4nNsEXcskYHKmNA@mail.gmail.com>
Date:	Wed, 18 Nov 2015 10:10:40 +0000
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 20:29, Peter Hurley <peter@...leysoftware.com> wrote:
> On 11/05/2015 01:35 PM, Pavel Labath wrote:
>> 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.
>
> My comment suggesting re-select()ing was aimed at the test suite only.
>
> For the debugger, I would always mixin new output from the target
> regardless of when it arrived. But feel free to ignore my unsolicited
> design advice :)
;)

>
>
>> This is especially tricky for remote debugging, as
>> the current gdb-remote protocol does not allow sending stdio after the
>> stop notification.
>
> Hmm, I could swear I've seen gdb scrolling away with new output while
> stopped.
That's quite possible if this wasn't a remote session. Gdb shares the
terminal with the tracee, so the order the output comes out really
depends on the internal terminal implementation. In lldb, we create a
new pty for the tracee and control the output forwarding ourselves.

If it was a remote session than I would be very interested in it as I
don't think the remote protocol supports that.

>
>> So, I actually quite like the fsync() idea, but I
>> don't know if this is something that would be generally accepted (?).
>
> Let me think more on this; maybe I can come up with a way to trip it
> within an existing method.

Thanks. I have not seen this occurring since, I contacted you, so it's
not a big priority for me now, but I may revisit it later.

>> 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)?
>
> I would think the existing pipe behavior is more or less guaranteed, since
> pipes are commonly used for process synchronization.
That's good to know, thanks. :)

cheers,
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/