All of lore.kernel.org
 help / color / mirror / Atom feed
From: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: ptrace: fix syscall modification under PTRACE_O_TRACESECCOMP
Date: Thu, 03 Jul 2014 16:43:07 +0900	[thread overview]
Message-ID: <53B5098B.9050801@linaro.org> (raw)
In-Reply-To: <20140624085405.GA26013@arm.com>

Hi Will,

On 06/24/2014 05:54 PM, Will Deacon wrote:
> On Mon, Jun 23, 2014 at 08:46:52PM +0100, Kees Cook wrote:
>> On Mon, Jun 23, 2014 at 1:46 AM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Fri, Jun 20, 2014 at 07:10:46PM +0100, Kees Cook wrote:
>>>> On Fri, Jun 20, 2014 at 10:36 AM, Kees Cook <keescook@chromium.org> wrote:
>>>>> On Fri, Jun 20, 2014 at 10:23 AM, Will Deacon <will.deacon@arm.com> wrote:
>>>>>> Right, gotcha. Thanks for the explanation. I was confused, because
>>>>>> tracehook_report_syscall does the right thing (returns
>>>>>> current_thread_info()->syscall), but if we don't have TIF_SYSCALL_TRACE set,
>>>>>> then updates during the secure_computing callback will be ignored.re
>>>>>>
>>>>>> However, my fix to this is significantly smaller than your patch, so I fear
>>>>>> I'm still missing something.
>>>>>
>>>>> Oh, yes, that's much smaller. Nice! I will test this and report back.
>>>>
>>>> Yup, I can confirm this works. Thanks!
>>>>
>>>> Tested-by: Kees Cook <keescook@chromium.org>
>>>
>>> Thanks, Kees. I'll post a patch shortly. I'll try and remember to keep an
>>> eye out for this when seccomp lands for arm64 too.
>>
>> Great, thanks!
>>
>> 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?

-Takahiro AKASHI


> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

WARNING: multiple messages have this Message-ID (diff)
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Will Deacon <will.deacon@arm.com>, Kees Cook <keescook@chromium.org>
Cc: "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, 03 Jul 2014 16:43:07 +0900	[thread overview]
Message-ID: <53B5098B.9050801@linaro.org> (raw)
In-Reply-To: <20140624085405.GA26013@arm.com>

Hi Will,

On 06/24/2014 05:54 PM, Will Deacon wrote:
> On Mon, Jun 23, 2014 at 08:46:52PM +0100, Kees Cook wrote:
>> On Mon, Jun 23, 2014 at 1:46 AM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Fri, Jun 20, 2014 at 07:10:46PM +0100, Kees Cook wrote:
>>>> On Fri, Jun 20, 2014 at 10:36 AM, Kees Cook <keescook@chromium.org> wrote:
>>>>> On Fri, Jun 20, 2014 at 10:23 AM, Will Deacon <will.deacon@arm.com> wrote:
>>>>>> Right, gotcha. Thanks for the explanation. I was confused, because
>>>>>> tracehook_report_syscall does the right thing (returns
>>>>>> current_thread_info()->syscall), but if we don't have TIF_SYSCALL_TRACE set,
>>>>>> then updates during the secure_computing callback will be ignored.re
>>>>>>
>>>>>> However, my fix to this is significantly smaller than your patch, so I fear
>>>>>> I'm still missing something.
>>>>>
>>>>> Oh, yes, that's much smaller. Nice! I will test this and report back.
>>>>
>>>> Yup, I can confirm this works. Thanks!
>>>>
>>>> Tested-by: Kees Cook <keescook@chromium.org>
>>>
>>> Thanks, Kees. I'll post a patch shortly. I'll try and remember to keep an
>>> eye out for this when seccomp lands for arm64 too.
>>
>> Great, thanks!
>>
>> 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?

-Takahiro AKASHI


> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

  parent reply	other threads:[~2014-07-03  7:43 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 [this message]
2014-07-03  7:43                   ` AKASHI Takahiro
2014-07-03 10:24                   ` Will Deacon
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=53B5098B.9050801@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --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.