New ARM asm/syscall.h incompatible? (commit bf2c9f9866928df60157bc4f1ab39f93a32c754e)

[Will Drewry]

Hi Wade and Steven,

I don't believe the syscall_get_arguments/syscall_set_arguments
implementation that landed in 3.4 is correct or safe.  I didn't see it
get pulled in - sorry for not mailing sooner! :(

The current implementation allows for _7_ arguments and allows the 0th
index to be the ARM_ORIG_r0 instead of starting with ARM_r0 == 0.  In
the global description of syscall_*_arguments it says:

 * It's only valid to call this when @task is stopped for tracing on
 * entry to a system call, due to %TIF_SYSCALL_TRACE or %TIF_SYSCALL_AUDIT.
 * It's invalid to call this with @i + @n > 6; we only support system calls
 * taking up to 6 arguments.

This means that the current implementation is broken when matching
system call arguments for ftrace (unless there is an arch specific
hack in there) and it breaks internal kernel API for any other
consumers without arch knowledge (like seccomp mode=2).  Is there a
reason to expose ARM_ORIG_r0 this way?  Am I misreading?

My understanding of the arch register usage at syscall time is something like:
- ORIG_r0 gets the syscall number
- r0 becomes the first system call argument
- system call proceeds
- on return, r0 is the return value

Right now, anyone who asks for the first argument will get the system
call number (syscall_get_nr) instead of the first argument.  The
attached patch fixes this, but I'm curious why this is and how it
didn't break ftrace!  Am I missing something?

Even audit_syscall_entry() uses ARM_r0 for the first argument which
means that any future consumers doing syscall_get_arguments(..., 0, 6)
would get the wrong first argument.

I'm also curious why the system call argument getter/setters allow for
invalid requests instead of BUG_ON()ing?  All code that exposes
syscall arguments to userspace should be limiting the number to a
maximum of 6, and any other badness is a definite kernel bug.  Am I
just really confused?

Any insights will be appreciated - thanks!
will

-----