Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [RFC PATCH] ptrace: add PTRACE_GET_SYSCALL_INFO request
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <20181107112100.GA20419@redhat.com>
Date:   Wed, 7 Nov 2018 06:06:43 -0800
Cc:     Elvira Khabirova <lineprinter@altlinux.org>, rostedt@goodmis.org,
        mingo@redhat.com, linux-kernel@vger.kernel.org, ldv@altlinux.org,
        esyr@redhat.com, luto@kernel.org, strace-devel@lists.strace.io
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BDB914D-12F3-4703-A033-EBE02226EC45@amacapital.net>
References: <20181107042751.3b519062@akathisia> <20181107112100.GA20419@redhat.com>
To:     Oleg Nesterov <oleg@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Nov 7, 2018, at 3:21 AM, Oleg Nesterov <oleg@redhat.com> wrote:
>=20
>> On 11/07, Elvira Khabirova wrote:
>>=20
>> In short, if a 64-bit task performs a syscall through int 0x80, its trace=
r
>> 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.
>=20
> Yes, this was discussed many times...
>=20
> 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 =E2=80=9Ccompat=E2=80=9D h=
ere.  Compat meant =E2=80=9Cnot the kernel=E2=80=99s native syscall API =E2=80=
=94 uses the 32-bit structure format instead=E2=80=9D.  This does not have a=
 sensible meaning to user code, especially in the case where the tracer is 3=
2-bit.

>=20
>> Secondly, ptracers also have to support a lot of arch-specific code for
>> obtaining information about the tracee. For some architectures, this
>> requires a ptrace(PTRACE_PEEKUSER, ...) invocation for every syscall
>> argument and return value.
>=20
> I am not sure about this change... I won't really argue, but imo this
> needs a separate patch.

Why?  Having a single struct that the tracer can read to get the full state i=
s extremely helpful.

Also, we really want it to work for seccomp events as well as PTRACE_SYSCALL=
, and the event info trick doesn=E2=80=99t make sense for seccomp events.

>=20
>> +#define PT_IN_SYSCALL_STOP    0x00000004    /* task is in a syscall-stop=
 */
> ...
>> -static inline int ptrace_report_syscall(struct pt_regs *regs)
>> +static inline int ptrace_report_syscall(struct pt_regs *regs,
>> +                    unsigned long message)
>> {
>>    int ptrace =3D current->ptrace;
>>=20
>>    if (!(ptrace & PT_PTRACED))
>>        return 0;
>> +    current->ptrace |=3D PT_IN_SYSCALL_STOP;
>>=20
>> +    current->ptrace_message =3D message;
>>    ptrace_notify(SIGTRAP | ((ptrace & PT_TRACESYSGOOD) ? 0x80 : 0));
>>=20
>>    /*
>> @@ -76,6 +79,7 @@ static inline int ptrace_report_syscall(struct pt_regs *=
regs)
>>        current->exit_code =3D 0;
>>    }
>>=20
>> +    current->ptrace &=3D ~PT_IN_SYSCALL_STOP;
>>    return fatal_signal_pending(current);
> ...
>=20
>> +    case PTRACE_GET_SYSCALL_INFO:
>> +        if (child->ptrace & PT_IN_SYSCALL_STOP)
>> +            ret =3D ptrace_get_syscall(child, datavp);
>> +        break;
>=20
> Why? If debugger uses PTRACE_O_TRACESYSGOOD it can know if the tracee repo=
rted
> syscall entry/exit or not. PTRACE_GET_SYSCALL_INFO is pointless if not, bu=
t
> nothing bad can happen.
>=20
>=20

I think it=E2=80=99s considerably nicer to the user to avoid reporting garba=
ge if the user misused the API.  (And Elvira got this right in the patch =E2=
=80=94 I just missed it.)

>=20