Files
erofs-linux/include/uapi/linux
Elvira Khabirova 201766a20e ptrace: add PTRACE_GET_SYSCALL_INFO request
PTRACE_GET_SYSCALL_INFO is a generic ptrace API that lets ptracer obtain
details of the syscall the tracee is blocked in.

There are two reasons for a special syscall-related ptrace request.

Firstly, with the current ptrace API there are cases when ptracer cannot
retrieve necessary information about syscalls.  Some examples include:

 * The notorious int-0x80-from-64-bit-task issue. See [1] for details.
   In short, if a 64-bit task performs a syscall through int 0x80, its
   tracer has no reliable means to find out that the syscall was, in
   fact, a compat syscall, and misidentifies it.

 * Syscall-enter-stop and syscall-exit-stop look the same for the
   tracer. Common practice is to keep track of the sequence of
   ptrace-stops in order not to mix the two syscall-stops up. But it is
   not as simple as it looks; for example, strace had a (just recently
   fixed) long-standing bug where attaching strace to a tracee that is
   performing the execve system call led to the tracer identifying the
   following syscall-exit-stop as syscall-enter-stop, which messed up
   all the state tracking.

 * Since the introduction of commit 84d77d3f06 ("ptrace: Don't allow
   accessing an undumpable mm"), both PTRACE_PEEKDATA and
   process_vm_readv become unavailable when the process dumpable flag is
   cleared. On such architectures as ia64 this results in all syscall
   arguments being unavailable for the tracer.

Secondly, ptracers also have to support a lot of arch-specific code for
obtaining information about the tracee.  For some architectures, this
requires a ptrace(PTRACE_PEEKUSER, ...) invocation for every syscall
argument and return value.

ptrace(2) man page:

long ptrace(enum __ptrace_request request, pid_t pid,
            void *addr, void *data);
...
PTRACE_GET_SYSCALL_INFO
       Retrieve information about the syscall that caused the stop.
       The information is placed into the buffer pointed by "data"
       argument, which should be a pointer to a buffer of type
       "struct ptrace_syscall_info".
       The "addr" argument contains the size of the buffer pointed to
       by "data" argument (i.e., sizeof(struct ptrace_syscall_info)).
       The return value contains the number of bytes available
       to be written by the kernel.
       If the size of data to be written by the kernel exceeds the size
       specified by "addr" argument, the output is truncated.

[[email protected]: selftests/seccomp/seccomp_bpf: update for PTRACE_GET_SYSCALL_INFO]
  Link: http://lkml.kernel.org/r/[email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Elvira Khabirova <[email protected]>
Co-developed-by: Dmitry V. Levin <[email protected]>
Signed-off-by: Dmitry V. Levin <[email protected]>
Reviewed-by: Oleg Nesterov <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Andy Lutomirski <[email protected]>
Cc: Eugene Syromyatnikov <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Greentime Hu <[email protected]>
Cc: Helge Deller <[email protected]>	[parisc]
Cc: James E.J. Bottomley <[email protected]>
Cc: James Hogan <[email protected]>
Cc: kbuild test robot <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Paul Burton <[email protected]>
Cc: Paul Mackerras <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: Richard Kuo <[email protected]>
Cc: Shuah Khan <[email protected]>
Cc: Vincent Chen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
2019-07-16 19:23:24 -07:00
..
…
…
…
…
…
…
…
…
2019-04-24 09:46:34 -04:00
…
2019-07-09 12:11:59 -07:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-05-23 21:07:30 -04:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-06-14 15:00:51 +05:30
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-03-27 13:30:07 -07:00
…
…
2019-05-27 11:42:36 +02:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-06-27 22:53:26 +02:00
…
…
…
…
…
…
…
…
2019-07-09 14:32:14 -06:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-07-11 15:08:28 +02:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-05-28 21:37:30 -07:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-06-13 16:49:45 -05:00
…
…
…
…
…
…
2019-07-09 14:47:45 -07:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-05-28 21:37:30 -07:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-06-19 16:56:14 +02:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…