Re: [PATCH 00/14] Prepare syscall_get_arch for PTRACE_GET_SYSCALL_INFO

[Paul Moore <paul@paul-moore.com>]

On Wed, Feb 27, 2019 at 9:13 AM Dmitry V. Levin <ldv@altlinux.org> wrote:
> On Sat, Feb 09, 2019 at 01:22:19AM +0300, Dmitry V. Levin wrote:
> > On Thu, Jan 17, 2019 at 03:34:44PM -0500, Richard Guy Briggs wrote:
> > > On 2019-01-09 15:40, Dmitry V. Levin wrote:
> > > > syscall_get_arch() is required to be implemented on all architectures in order
> > > > to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO request:
> > > > syscall_get_arch() is going to be called from ptrace_request() along with
> > > > syscall_get_nr(), syscall_get_arguments(), syscall_get_error(), and
> > > > syscall_get_return_value() functions with a tracee as their argument.
> > > >
> > > > The primary intent is that the triple (audit_arch, syscall_nr, arg1..arg6)
> > > > should describe what system call is being called and what its arguments are.
> > > >
> > > > This patchset began as a series called "Prepare for PTRACE_GET_SYSCALL_INFO",
> > > > then I merged it into a series called "ptrace: add PTRACE_GET_SYSCALL_INFO request"
> > > > that also contains ptrace-specific changes.
> > > >
> > > > The ptrace-specific part, however, needs more attention to workaround problems
> > > > on niche architectures like alpha, while the syscall_get_arch() part is
> > > > straightforward, so I decided to split it out into a separate patchset that
> > > > just prepares syscall_get_arch() for PTRACE_GET_SYSCALL_INFO: it adds
> > > > syscall_get_arch() to those architectures that haven't implemented it yet,
> > > > and then adds "struct task_struct *" argument to syscall_get_arch()
> > > > on all architectures.
> > >
> > > Glad to see syscall_get_arch() added to the remaining arches.  As Paul
> > > said, it gets us closer to auditing syscalls on those remaining
> > > unsupported arches and getting rid of the extra CONFIG_AUDITSYSCALL.
> > > A little ironic that Eric (Paris) and I purged task_struct from
> > > syscall_get_arch() 5 years ago since everything could use current.
> > >
> > > > All patches from this patchset have been already reviewed, so it's ready
> > > > to be merged without waiting for the ptrace-specific part.  As it's all
> > > > about syscall_get_arch(), it should probably go via audit tree.
> > >
> > > ACK.
> > >
> > > Thanks Dmitry.
> >
> > Thanks.
> > Please let me know if some action related to this patch series is expected from me.
> >
> > > > Dmitry V. Levin (14):
> > > >   Move EM_ARCOMPACT and EM_ARCV2 to uapi/linux/elf-em.h
> > > >   arc: define syscall_get_arch()
> > > >   c6x: define syscall_get_arch()
> > > >   h8300: define syscall_get_arch()
> > > >   Move EM_HEXAGON to uapi/linux/elf-em.h
> > > >   hexagon: define syscall_get_arch()
> > > >   m68k: define syscall_get_arch()
> > > >   Move EM_NDS32 to uapi/linux/elf-em.h
> > > >   nds32: define syscall_get_arch()
> > > >   nios2: define syscall_get_arch()
> > > >   riscv: define syscall_get_arch()
> > > >   Move EM_UNICORE to uapi/linux/elf-em.h
> > > >   unicore32: define syscall_get_arch()
> > > >   syscall_get_arch: add "struct task_struct *" argument
>
> This is just a gentle ping of the series which is still applicable
> to v5.0-rc8 with one exception: "riscv: define syscall_get_arch()"
> is no longer needed as riscv already has syscall_get_arch() now.

Hi Dmitry,

I obviously think this patchset is a step in the right direction (I've
ACK'd it previously), and I have no problem merging this via the audit
tree, but I'm far from an expert on all the various arches listed, so
having the associated arch maintainer ACKs is important.  Based on the
mail I've seen, here is the current status of the maintainer ACKs:

* arc: good (vgupta@synopsys.com)
* c6x: good (msalter@redhat.com)
* h8300: missing
* hexagon: missing
* m68k: good (geert@linux-m68k.org)
* nds32: missing
* nios2: missing
* riscv: no longer needed
* unicore32: missing

... as you can see, we are missing a number of ACKs/reviews from some
of the smaller arches.  Granted, it has been over a month, and these
patches are relatively trivial, but if you could try one more time to
get the missing ACKs I would appreciate it.

If you still can't get a response from the various maintainers by the
time the upcoming merge window closes and -next opens for business,
I'll go ahead and merge the pile into audit/next and we'll cross our
fingers that nothing explodes.

It shouldn't.

I think :)

-- 
paul moore
www.paul-moore.com