All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: ptrace: fix syscall modification under PTRACE_O_TRACESECCOMP
Date: Thu, 3 Jul 2014 11:24:50 +0100	[thread overview]
Message-ID: <20140703102450.GD12958@arm.com> (raw)
In-Reply-To: <53B5098B.9050801@linaro.org>

On Thu, Jul 03, 2014 at 08:43:07AM +0100, AKASHI Takahiro wrote:
> Hi Will,

Hi Akashi,

> On 06/24/2014 05:54 PM, Will Deacon wrote:
> > On Mon, Jun 23, 2014 at 08:46:52PM +0100, Kees Cook wrote:
> >> What's the state of seccomp on arm64? I saw a series back in March,
> >> but nothing since then? It looked complete, but I haven't set up a
> >> test environment yet to verify.
> >
> > I think Akashi was going to repost `real soon now' so we can include them
> > for 3.17. He missed the merge window last time around.
> 
> I took a quick look at the current implementation of ptrace.
> ptrace(PTRACE_GETREGSET/SETREGSET), eventually gpr_get/set(), handles only
> 'struct user_pt_regs', and we have no way to modify orig_x0 nor syscallno
> in 'struct pt_regs' directly.
> So it seems to me that we can't change a system call by ptrace().
> Do I misunderstand anything?

No, it looks like you have a point here. I don't think userspace has any
business with orig_x0, but changing syscallno is certainly useful. I can
think of two ways to fix this:

  (1) Updating syscallno based on w8, but this ties us to the current ABI
      and could get messy if this register changes in the future.

  (2) Adding a PTRACE_SET_SYSCALL request, like we have for arch/arm/,
      but that means adding arch-specific stuff to arch_ptrace (which
      currently goes straight to ptrace_request on arm64).

It looks like x86 uses orig_ax, which I *think* means we would go with
(1) above if we followed their lead.

Anybody else have an opinion about this?

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: "Kees Cook" <keescook@chromium.org>,
	"André Hentschel" <nerv@dawncrow.de>,
	"Russell King" <linux@arm.linux.org.uk>,
	"Jonathan Austin" <Jonathan.Austin@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Andy Lutomirski" <luto@amacapital.net>,
	"Oleg Nesterov" <oleg@redhat.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Ricky Zhou" <rickyz@google.com>
Subject: Re: [PATCH] arm: ptrace: fix syscall modification under PTRACE_O_TRACESECCOMP
Date: Thu, 3 Jul 2014 11:24:50 +0100	[thread overview]
Message-ID: <20140703102450.GD12958@arm.com> (raw)
In-Reply-To: <53B5098B.9050801@linaro.org>

On Thu, Jul 03, 2014 at 08:43:07AM +0100, AKASHI Takahiro wrote:
> Hi Will,

Hi Akashi,

> On 06/24/2014 05:54 PM, Will Deacon wrote:
> > On Mon, Jun 23, 2014 at 08:46:52PM +0100, Kees Cook wrote:
> >> What's the state of seccomp on arm64? I saw a series back in March,
> >> but nothing since then? It looked complete, but I haven't set up a
> >> test environment yet to verify.
> >
> > I think Akashi was going to repost `real soon now' so we can include them
> > for 3.17. He missed the merge window last time around.
> 
> I took a quick look at the current implementation of ptrace.
> ptrace(PTRACE_GETREGSET/SETREGSET), eventually gpr_get/set(), handles only
> 'struct user_pt_regs', and we have no way to modify orig_x0 nor syscallno
> in 'struct pt_regs' directly.
> So it seems to me that we can't change a system call by ptrace().
> Do I misunderstand anything?

No, it looks like you have a point here. I don't think userspace has any
business with orig_x0, but changing syscallno is certainly useful. I can
think of two ways to fix this:

  (1) Updating syscallno based on w8, but this ties us to the current ABI
      and could get messy if this register changes in the future.

  (2) Adding a PTRACE_SET_SYSCALL request, like we have for arch/arm/,
      but that means adding arch-specific stuff to arch_ptrace (which
      currently goes straight to ptrace_request on arm64).

It looks like x86 uses orig_ax, which I *think* means we would go with
(1) above if we followed their lead.

Anybody else have an opinion about this?

Will

  reply	other threads:[~2014-07-03 10:24 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-18 20:27 [PATCH] arm: ptrace: fix syscall modification under PTRACE_O_TRACESECCOMP Kees Cook
2014-06-18 20:27 ` Kees Cook
2014-06-18 20:51 ` Andy Lutomirski
2014-06-18 20:51   ` Andy Lutomirski
2014-06-20 10:22 ` Will Deacon
2014-06-20 10:22   ` Will Deacon
2014-06-20 16:44   ` Kees Cook
2014-06-20 16:44     ` Kees Cook
2014-06-20 17:23     ` Will Deacon
2014-06-20 17:23       ` Will Deacon
2014-06-20 17:36       ` Kees Cook
2014-06-20 17:36         ` Kees Cook
2014-06-20 18:10         ` Kees Cook
2014-06-20 18:10           ` Kees Cook
2014-06-23  8:46           ` Will Deacon
2014-06-23  8:46             ` Will Deacon
2014-06-23 19:46             ` Kees Cook
2014-06-23 19:46               ` Kees Cook
2014-06-24  8:54               ` Will Deacon
2014-06-24  8:54                 ` Will Deacon
2014-06-24  9:20                 ` AKASHI Takahiro
2014-06-24  9:20                   ` AKASHI Takahiro
2014-07-03  7:43                 ` AKASHI Takahiro
2014-07-03  7:43                   ` AKASHI Takahiro
2014-07-03 10:24                   ` Will Deacon [this message]
2014-07-03 10:24                     ` Will Deacon
2014-07-03 15:39                     ` Andy Lutomirski
2014-07-03 15:39                       ` Andy Lutomirski
2014-07-03 16:11                       ` Will Deacon
2014-07-03 16:11                         ` Will Deacon
2014-07-03 16:13                         ` Andy Lutomirski
2014-07-03 16:13                           ` Andy Lutomirski
2014-07-03 16:32                           ` Will Deacon
2014-07-03 16:32                             ` Will Deacon
2014-07-04 23:05                             ` Andy Lutomirski
2014-07-04 23:05                               ` Andy Lutomirski

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=20140703102450.GD12958@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.