On Tue, Aug 26, 2014 at 10:32 PM, AKASHI Takahiro
[off-list ref] wrote:

Kees,


On 08/27/2014 02:46 AM, Will Deacon wrote:

quoted

On Fri, Aug 22, 2014 at 01:19:13AM +0100, AKASHI Takahiro wrote:

quoted

On 08/22/2014 01:47 AM, Kees Cook wrote:

quoted

On Thu, Aug 21, 2014 at 3:56 AM, AKASHI Takahiro
[off-list ref] wrote:

quoted

To allow tracer to be able to change/skip a system call by re-writing
a syscall number, there are several approaches:

(1) modify x8 register with ptrace(PTRACE_SETREGSET), and handle this
case
      later on in syscall_trace_enter(), or
(2) support ptrace(PTRACE_SET_SYSCALL) as on arm

Thinking of the fact that user_pt_regs doesn't expose 'syscallno' to
tracer as well as that secure_computing() expects a changed syscall
number
to be visible, especially case of -1, before this function returns in
syscall_trace_enter(), we'd better take (2).

Signed-off-by: AKASHI Takahiro <redacted>

Thanks, I like having this on both arm and arm64.

Yeah, having this simplified the code of syscall_trace_enter() a bit, but
also imposes some restriction on arm64, too.

  > I wonder if other archs should add this option too.

Do you think so? I assumed that SET_SYSCALL is to be avoided if possible.

I also think that SET_SYSCALL should take an extra argument for a return
value
just in case of -1 (or we have SKIP_SYSCALL?).

I think we should propose this as a new request in the generic ptrace
code.
We can have an architecture-hook for actually setting the syscall, and
allow
architectures to define their own implementation of the request so they
can
be moved over one by one.

What do you think about this request?

That sounds fine -- it doesn't need to be part of this series. I was
just noticing this was a common issue across multiple architectures.

-Kees

-- 
Kees Cook
Chrome OS Security