public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Markos Chandras <Markos.Chandras@imgtec.com>
To: Kees Cook <keescook@chromium.org>
Cc: James Hogan <james.hogan@imgtec.com>,
	Paul Burton <paul.burton@imgtec.com>,
	Linux MIPS Mailing List <linux-mips@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: MIPS seccomp and changing syscalls
Date: Fri, 18 Jul 2014 11:22:36 +0100	[thread overview]
Message-ID: <53C8F56C.5070706@imgtec.com> (raw)
In-Reply-To: <CAGXu5jJJ7dqC-or=ZhKKj8=eA5itKX4aLRsnxmFZvwnyRcrUrw@mail.gmail.com>

Hi Kees,

On 07/17/2014 11:29 PM, Kees Cook wrote:
> Hi,
> 
> I recently fixed a bug in seccomp on ARM that I think may be present
> in the MIPS implementation too. In arch/mips/kernel/ptrace.c
> syscall_trace_enter, the syscall variable is used (and returned), but
> the syscall may be changed by either secure_computing or
> tracehook_report_syscall_entry (via ptracers which can block and
> change the registers). (I would note that "ret" is also set but never
> used, so tracehook_report_syscall_entry failures actually won't get
> noticed.)
> 
> The discussion about this bug on ARM is here:
> https://lkml.org/lkml/2014/6/20/439

Thanks for letting us know.
Right, I believe MIPS will have the same problem and a similar patch to
Will Deacon's one will fix it properly. Would you like to submit one for
MIPS too? Otherwise I can do it myself.

> 
> I don't yet have a working MIPS environment to test this on, but it
> feels like the same bug. (Though, for testing, what's the right way to
> change syscall during PTRACE_SYSCALL? On x86 it's the orig_ax
> register, on ARM it's a arch-specific ptrace function
> (PTRACE_SET_SYSCALL).

For MIPS, the syscall numbers is in the v0 register ($2). But the o32
ABI also has the syscall() system call. So in case of indirect system
calls, the real system call is the first argument of syscall(), which is
register a0 ($4). See syscall_get_nr in arch/mips/include/asm/syscall.h

-- 
markos

  reply	other threads:[~2014-07-18 10:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-17 22:29 MIPS seccomp and changing syscalls Kees Cook
2014-07-18 10:22 ` Markos Chandras [this message]
2014-07-18 14:18   ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53C8F56C.5070706@imgtec.com \
    --to=markos.chandras@imgtec.com \
    --cc=james.hogan@imgtec.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=paul.burton@imgtec.com \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox