Re: [PATCH v4 1/2] ptrace: save the type of syscall-stop in ptrace_message

On Thu, Nov 29, 2018 at 03:47:43PM +0100, Oleg Nesterov wrote:

On 11/29, Dmitry V. Levin wrote:

quoted

2. Document these values

sure, they should be documented and live in include/uapi/,

quoted

chosen to avoid collisions with ptrace_message values
set by other ptrace events

this is what I can't understand. But to clarify, I don't really care and
won't argue.

If an application wants to use PTRACE_GETEVENTMSG to distinguish entry/exit
(without PTRACE_GET_SYSCALL_INFO) it needs to do wait(status) and check status
anyway, otherwise PTRACE_GETEVENTMSG is simply pointless (wrt syscall entry/
exit). So we do not care if PTRACE_EVENTMSG_SYSCALL_ENTRY conflicts with, say,
SECCOMP_RET_DATA.

Yes, once the application has verified that the kernel implements this
feature, there is no risk of collision.

quoted

so that PTRACE_GETEVENTMSG users can easily tell
whether this new semantics is supported by the kernel or not.

Yes. And how much this can help? Again, an application can trivially detect
if this feature implemented or not, and it should do this anyway if it wants
to (try to) use PTRACE_EVENTMSG_SYSCALL_ENTRY/EXIT ?

How an application can easily detect whether this feature is implemented?
By invoking PTRACE_GETEVENTMSG after the first syscall stop reported by
wait and checking whether the returned value is either
PTRACE_EVENTMSG_SYSCALL_ENTRY or PTRACE_EVENTMSG_SYSCALL_EXIT.

So the question is, how can this value be equal to one of these constants
when this feature is not implemented?  Can a value saved to ptrace_message
earlier by one of ptrace events be equal to one of these constants?

Imagine an application attaches to already existing process, enables
PTRACE_O_TRACESECCOMP, and a PTRACE_EVENT_SECCOMP arrives with
ptrace_message set to 1.  If this application then exits and a new invocation
of the same application attaches to the same process, it will very likely see
this 1 returned by PTRACE_GETEVENTMSG if the feature is not implemented
in the kernel.

To avoid that kind of collisions, kernel should use different ptrace_message
values for syscall stops.

Again, I won't reallly argue. But if you insist that these values must
be unique then you probably need to add

	BUILD_BUG_ON(PTRACE_EVENTMSG_SYSCALL_ENTRY <= PID_MAX_LIMIT);

Yes, it's a good idea.  What is the proper place for this check?


-- 
ldv