linux-kernel - Re: [PATCH] ptrace.2: Improve clarity for multi-threaded tracers

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]

Date:   Sun, 21 Apr 2019 16:57:04 +0200
From:   Niklas Hambüchen <mail@....me>
To:     "Dmitry V. Levin" <ldv@...linux.org>
Cc:     mtk.manpages@...il.com, linux-kernel@...r.kernel.org,
        cleverca22@...il.com, linux-man@...r.kernel.org
Subject: Re: [PATCH] ptrace.2: Improve clarity for multi-threaded tracers

Hey Dmitry,

On 2019-02-17 23:15, Dmitry V. Levin wrote:
>>  A tracee first needs to be attached to the tracer.
>> -Attachment and subsequent commands are per thread:
>> -in a multithreaded process,
>> +Attachment and subsequent commands are per thread,
>> +on both the tracer and tracee side.
>> +Issuing a tracing command from a thread that is not the tracer of the given
>> +.I pid
>> +will result in an
>> +.B ESRCH
>> +error.
> 
> This is confusing.  What do you mean by a tracing command?
> Is PTRACE_TRACEME a tracing command?  PTRACE_ATTACH?  PTRACE_SEIZE?

I was referring to the same command as in other places in the man page, as in the existing sentences

    Most ptrace commands [...] require the tracee to be in a  ptrace-stop, otherwise they fail with ESRCH.

or

    (for commands which require a stopped tracee)

Would thus "ptrace command" be better than "tracing command" here?

>>  .B ESRCH
>>  The specified process does not exist, or is not currently being traced
>> -by the caller, or is not stopped
>> +by the calling thread, or is not stopped
>>  (for requests that require a stopped tracee).
>>  .SH CONFORMING TO
>>  SVr4, 4.3BSD.
> 
> I agree the current text can be made more clear on the subject,
> but, unfortunately, proposed change makes the description more confusing.

Do you mean "calling thread" is more confusing than "caller"?
If yes, what would you suggest instead?

My intent here was to, for anybody who encounters ESRCH and looks it up in an effort to see what's going on, make clear that threads are important here.

Or should I switch to `task_struct` terminology? That wouldn't be userspace terminology though, and the rest of the man page also talks about threads.


Niklas



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