Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH] ptrace: Allow other threads to access tracee
To:     Oleg Nesterov <oleg@redhat.com>
Cc:     linux-kernel@vger.kernel.org
References: <20210310205908.23447-1-jnewsome@torproject.org>
 <20210311152123.GC15552@redhat.com>
From:   Jim Newsome <jnewsome@torproject.org>
Organization: The Tor Project
Message-ID: <f82d5f3a-63f7-2f3f-0e34-aa53ade15bfc@torproject.org>
Date:   Thu, 11 Mar 2021 10:49:19 -0600
MIME-Version: 1.0
In-Reply-To: <20210311152123.GC15552@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk

On 3/11/21 09:21, Oleg Nesterov wrote:
> Cough... it is not that simple.
Yes, I was afraid of that :)
> Just suppose that 2 threads call ptrace(tracee) at the same time. Say, the 1st
> thread does PTRACE_CONT while the 2nd thread tries to change the registers.

Is it acceptable for the new register-values to be lost, or even
corrupted, in this case? From my perspective it is, if the tracer failed
to synchronize itself, but maybe there's an overarching philosophy that
syscalls should be "atomic"?

I suppose even if the corruption of the register-values-themselves is
acceptable, some synchronization may be needed to avoid the possibility
of corrupting the kernel's data structures?

Is it "just" a matter of adding some locking? Would a relatively coarse
lock on the target task over the duration of the ptrace call (which I
believe is always non-blocking?) be acceptable, or would we need finer
grained locking in places where we actually touch the target task? And
do you have a feel for whether you'd be inclined to accept such a patch
once that (or whatever actually is needed) is added?

Thanks!

-Jim