From: "Dmitry V. Levin" <ldv@altlinux.org> To: Oleg Nesterov <oleg@redhat.com> Cc: Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>, Michael Ellerman <mpe@ellerman.id.au>, Elvira Khabirova <lineprinter@altlinux.org>, Eugene Syromyatnikov <esyr@redhat.com>, Steven Rostedt <rostedt@goodmis.org>, linux-kernel@vger.kernel.org, Andy Lutomirski <luto@kernel.org>, linux-api@vger.kernel.org, Ingo Molnar <mingo@redhat.com>, strace-devel@lists.strace.io Subject: Re: [PATCH v4 1/2] ptrace: save the type of syscall-stop in ptrace_message Date: Fri, 30 Nov 2018 00:10:44 +0300 [thread overview] Message-ID: <20181129211044.GA20529@altlinux.org> (raw) In-Reply-To: <20181129144742.GB10645@redhat.com> [-- Attachment #1: Type: text/plain, Size: 2450 bytes --] On Thu, Nov 29, 2018 at 03:47:43PM +0100, Oleg Nesterov wrote: > On 11/29, Dmitry V. Levin wrote: > > > > 2. Document these values > > sure, they should be documented and live in include/uapi/, > > > 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. > > 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: "Dmitry V. Levin" <ldv-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> To: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Cc: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>, Jann Horn <jannh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>, Eugene Syromyatnikov <esyr-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, strace-devel-3+4lAyCyj6AWlMsSdNXQLw@public.gmane.org Subject: Re: [PATCH v4 1/2] ptrace: save the type of syscall-stop in ptrace_message Date: Fri, 30 Nov 2018 00:10:44 +0300 [thread overview] Message-ID: <20181129211044.GA20529@altlinux.org> (raw) In-Reply-To: <20181129144742.GB10645-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> [-- Attachment #1.1: Type: text/plain, Size: 2450 bytes --] On Thu, Nov 29, 2018 at 03:47:43PM +0100, Oleg Nesterov wrote: > On 11/29, Dmitry V. Levin wrote: > > > > 2. Document these values > > sure, they should be documented and live in include/uapi/, > > > 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. > > 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 [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] [-- Attachment #2: Type: text/plain, Size: 137 bytes --] -- Strace-devel mailing list Strace-devel-3+4lAyCyj6AWlMsSdNXQLw@public.gmane.org https://lists.strace.io/mailman/listinfo/strace-devel
next prev parent reply other threads:[~2018-11-29 21:10 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-28 13:04 [PATCH v4 0/2] ptrace: add PTRACE_GET_SYSCALL_INFO request Dmitry V. Levin 2018-11-28 13:04 ` Dmitry V. Levin 2018-11-28 13:06 ` [PATCH v4 1/2] ptrace: save the type of syscall-stop in ptrace_message Dmitry V. Levin 2018-11-28 13:06 ` Dmitry V. Levin 2018-11-28 13:49 ` Oleg Nesterov 2018-11-28 14:05 ` Dmitry V. Levin 2018-11-28 14:20 ` Oleg Nesterov 2018-11-28 15:23 ` Dmitry V. Levin 2018-11-28 15:23 ` Dmitry V. Levin 2018-11-28 22:11 ` Dmitry V. Levin 2018-11-28 22:11 ` Dmitry V. Levin 2018-11-28 23:17 ` Andy Lutomirski 2018-11-29 10:34 ` Dmitry V. Levin 2018-11-29 15:03 ` Oleg Nesterov 2018-11-29 14:47 ` Oleg Nesterov 2018-11-29 21:10 ` Dmitry V. Levin [this message] 2018-11-29 21:10 ` Dmitry V. Levin 2018-11-30 11:29 ` Oleg Nesterov 2018-11-30 22:53 ` Dmitry V. Levin 2018-11-30 22:53 ` Dmitry V. Levin 2018-11-28 13:07 ` [PATCH v4 2/2] ptrace: add PTRACE_GET_SYSCALL_INFO request Dmitry V. Levin 2018-11-28 14:10 ` Oleg Nesterov 2018-11-28 14:29 ` Oleg Nesterov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20181129211044.GA20529@altlinux.org \ --to=ldv@altlinux.org \ --cc=esyr@redhat.com \ --cc=jannh@google.com \ --cc=keescook@chromium.org \ --cc=lineprinter@altlinux.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@kernel.org \ --cc=mingo@redhat.com \ --cc=mpe@ellerman.id.au \ --cc=oleg@redhat.com \ --cc=rostedt@goodmis.org \ --cc=strace-devel@lists.strace.io \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.