From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [RFC PATCH v2] ptrace: add PTRACE_GET_SYSCALL_INFO request Date: Thu, 22 Nov 2018 16:19:10 -0800 Message-ID: References: <20181121165806.07da7c98@akathisia> <20181121235634.GA14146@altlinux.org> <20181122191504.GB27204@altlinux.org> Reply-To: strace development discussions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20181122191504.GB27204-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: strace-devel-bounces-3+4lAyCyj6AWlMsSdNXQLw@public.gmane.org Sender: "Strace-devel" To: "Dmitry V. Levin" Cc: Eugene Syromiatnikov , Kees Cook , Jann Horn , Linux API , Oleg Nesterov , Steven Rostedt , LKML , Andrew Lutomirski , Ingo Molnar , strace-devel-3+4lAyCyj6AWlMsSdNXQLw@public.gmane.org List-Id: linux-api@vger.kernel.org On Thu, Nov 22, 2018 at 11:15 AM Dmitry V. Levin wrote: > > On Thu, Nov 22, 2018 at 06:55:29AM -0800, Andy Lutomirski wrote: > > On Wed, Nov 21, 2018 at 3:56 PM Dmitry V. Levin wrote: > > > On Wed, Nov 21, 2018 at 02:56:57PM -0800, Andy Lutomirski wrote: > > > > Please cc linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org for future versions. > > > > > > > > On Wed, Nov 21, 2018 at 7:58 AM Elvira Khabirova wrote: > > > > > > > > > > struct ptrace_syscall_info { > > > > > __u8 op; /* 0 for entry, 1 for exit */ > > > > > > > > Can you add proper defines, like: > > > > > > > > #define PTRACE_SYSCALL_ENTRY 0 > > > > #define PTRACE_SYSCALL_EXIT 1 > > > > #define PTRACE_SYSCALL_SECCOMP 2 > > > > > > > > and make seccomp work from the start? I'd rather we don't merge an > > > > implementation that doesn't work for seccomp and then have to rework > > > > it later. > > > > > > What's the difference between PTRACE_EVENT_SECCOMP and syscall-entry-stop > > > with regards to PTRACE_GET_SYSCALL_INFO request? At least they have the > > > same entry_info to return. > > > > I'm not sure there's any material difference. > > In that case we don't really need PTRACE_SYSCALL_SECCOMP: op field > describes the structure inside the union to use, not the ptrace stop. Unless we think the structures might diverge in the future. > > > > As long as implementation (ab)uses ptrace_message to tell one kind of stop > > > from another, it can distinguish syscall-entry-stop and syscall-exit-stop > > > from each other and from many other kinds of stops, but it cannot > > > distinguish PTRACE_EVENT_SECCOMP from e.g. PTRACE_EVENT_EXIT. > > > > Hmm. PTRACE_GET_SYSCALL_INFO should fail for PTRACE_EVENT_EXIT, I think. > > Unless we can change PTRACE_EVENT_SECCOMP to set some higher bits of > ptrace_message (beyond SECCOMP_RET_DATA) which is very unlikely because > it would qualify as an ABI change, this would require an additional field > in struct task_struct because ptrace_message wouldn't be enough > to distinguish PTRACE_EVENT_SECCOMP from PTRACE_EVENT_EXIT. At the risk of making the patch more complicated, there's room to massively clean up the ptrace state. We could add a struct ptrace_tracee and put a struct ptrace_tracee *ptrace_tracee into task_struct. The struct would contain a pointer to the task_struct as well as ptrace (the flag field, I think), ptrace_entry, ptracer_cred, ptrace_message, and last_siginfo. And then we could add a field for the ptrace stop state that would indicate the actual reason for the current stop. We'd only allocate ptrace_tracee when someone attaches with ptrace, thus saving quite a few bytes for each task. It's a bit unfortunate if we allow PTRACE_GET_SYSCALL_INFO to success if the event is PTRACE_EVENT_EXIT. I'd also be a bit nervous about info leaks if we start calling the syscall accessors for tasks that aren't in syscalls. --Andy -- Strace-devel mailing list Strace-devel-3+4lAyCyj6AWlMsSdNXQLw@public.gmane.org https://lists.strace.io/mailman/listinfo/strace-devel