linux-kernel - Re: [PATCH v7 1/6] arm64: ptrace: add PTRACE_SET

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 6 Nov 2014 10:17:40 -0800
From:	Kees Cook <keescook@...omium.org>
To:	AKASHI Takahiro <takahiro.akashi@...aro.org>
Cc:	Will Deacon <will.deacon@....com>,
	Catalin Marinas <Catalin.Marinas@....com>,
	"dsaxena@...aro.org" <dsaxena@...aro.org>,
	"arndb@...db.de" <arndb@...db.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 1/6] arm64: ptrace: add PTRACE_SET_SYSCALL

On Wed, Nov 5, 2014 at 6:40 PM, AKASHI Takahiro
<takahiro.akashi@...aro.org> wrote:
> Hi Will, Kees
>
> #Sorry for this late ping,
>
>
> On 10/09/2014 06:23 PM, Will Deacon wrote:
>>
>> On Wed, Oct 08, 2014 at 04:30:18PM +0100, Kees Cook wrote:
>>>
>>> On Wed, Oct 8, 2014 at 9:13 AM, Will Deacon <will.deacon@....com> wrote:
>>>>
>>>> On Thu, Oct 02, 2014 at 10:46:11AM +0100, AKASHI Takahiro wrote:
>>>>>
>>>>> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
>>>>> index fe63ac5..2842f9f 100644
>>>>> --- a/arch/arm64/kernel/ptrace.c
>>>>> +++ b/arch/arm64/kernel/ptrace.c
>>>>> @@ -1082,7 +1082,19 @@ const struct user_regset_view
>>>>> *task_user_regset_view(struct task_struct *task)
>>>>>   long arch_ptrace(struct task_struct *child, long request,
>>>>>                 unsigned long addr, unsigned long data)
>>>>>   {
>>>>> -     return ptrace_request(child, request, addr, data);
>>>>> +     int ret;
>>>>> +
>>>>> +     switch (request) {
>>>>> +             case PTRACE_SET_SYSCALL:
>>>>> +                     task_pt_regs(child)->syscallno = data;
>>>>> +                     ret = 0;
>>>>> +                     break;
>>>>> +             default:
>>>>> +                     ret = ptrace_request(child, request, addr, data);
>>>>> +                     break;
>>>>> +     }
>>>>> +
>>>>> +     return ret;
>>>>>   }
>>>>
>>>>
>>>> I still don't understand why this needs to be in arch-specific code.
>>>> Can't
>>>> we implement this in generic code and get architectures to implement
>>>> something like syscall_set_nr if they want the generic interface?
>>>
>>>
>>> Personally, I'd rather see this land as-is in the arm64 tree, and then
>>> later optimize PTRACE_SET_SYSCALL out of arm/ and arm64/, especially
>>> since only these architectures implement this at the moment.
>>
>>
>> Why? It should be really straightforward to do this in core code from the
>> get-go and experience shows that, if we don't do it now, it will never
>> happen.
>
>
> How should I deal with this issue? I would be able to go either way.

It sounds like Will would be happiest with PTRACE_SET_SYSCALL being
extracted from arm/ and arm64/ so I'd recommend doing that. It could
maybe be its own patch series, too.

> Other than that, I will submit v8 patch series with a few very minor
> updates:
> - use compat_uint_t in struct compat_siginfo
> - use a new call interface of secure_computing(void)
> - modify and clarify comments in syscall_trace_enter()

Sounds great, thank you!

-Kees

>
> Thanks,
> -Takahiro AKASHI
>
>
>>> This is my plan for the asm-generic seccomp.h too -- I'd rather avoid
>>> touching other architectures in this series, as it's easier to review
>>> this way. Then we can optimize the code in a separate series, which
>>> will have those changes isolated, etc.
>>
>>
>> But this doesn't need to touch any other architectures...
>>
>> Will
>>
>



-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/