[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <35B601B0-4D56-4706-B7A1-C9A522AB2D6F@amacapital.net>
Date: Wed, 7 Nov 2018 12:20:18 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Elvira Khabirova <lineprinter@...linux.org>, rostedt@...dmis.org,
mingo@...hat.com, linux-kernel@...r.kernel.org, ldv@...linux.org,
esyr@...hat.com, luto@...nel.org, strace-devel@...ts.strace.io
Subject: Re: [RFC PATCH] ptrace: add PTRACE_GET_SYSCALL_INFO request
> On Nov 7, 2018, at 8:44 AM, Oleg Nesterov <oleg@...hat.com> wrote:
>
>> On 11/07, Andy Lutomirski wrote:
>>
>>
>>>> On Nov 7, 2018, at 3:21 AM, Oleg Nesterov <oleg@...hat.com> wrote:
>>>>
>>>> On 11/07, Elvira Khabirova wrote:
>>>>
>>>> In short, if a 64-bit task performs a syscall through int 0x80, its tracer
>>>> has no reliable means to find out that the syscall was, in fact,
>>>> a compat syscall, and misidentifies it.
>>>> * Syscall-enter-stop and syscall-exit-stop look the same for the tracer.
>>>
>>> Yes, this was discussed many times...
>>>
>>> So perhaps it makes sense to encode compat/is_enter in ->ptrace_message,
>>> debugger can use PTRACE_GETEVENTMSG to get this info.
>>
>> As I said before, I strongly object to the use of “compat” here.
>
> Not sure I understand you... I do not like "compat" too, but this patch uses
> is_compat/etc and I agree with any naming.
My point is: returning a value to user code that is:
0 if the kernel and tracee are 32-bit
0 if the kernel and tracer are 64-but
1 if the kernel is 64-bit and the tracer is 32-bit
? If the tracer is arm64 ILP32
Is not a good design. And 32-bit builds of strace will not appreciate it.
The API should return a value that, at least on a given overall architecture and preferably globally, indicates the syscall arch. While oddly named, audit_arch fits the bill nicely, and we already require it to have the right semantics for seccomp support.
Powered by blists - more mailing lists